基于GitLab，Jenkins和RunDeck的持续交付系统（一）

2019独角兽企业重金招聘Python工程师标准>>>

公司计划推行持续交付，系统更新部署不再通过人工操作，我们打算使用GitLab来管理源代码，Jenkins打包项目，RunDeck将打包好的项目部署到生产环境。

在网上查了很多资料，流程大概是开发人员在GitLab中提交一个Merge Request将开发分支合并到master中，负责代码审核的人同意提交后，会触发Jenkins自动打包项目并部署到测试环境，在通过一系列自动化测试后，就会部署到生产环境。

不过这个流程不太符合我们的要求，原因如下

• 测试由专门的测试部门负责，只有通过测试部门的测试，项目才能部署到生产环境
• 我们并不希望在同意Merge Request后，项目就马上开始打包部署到生产环境，而是希望在未来的某一个时间点才开始，比如，开发人员今天提前提交了Merge Request，代码也在今天通过了审核，但是项目的上线时间却是明天早上七点，我们也总不能让负责代码审核的人每次都那么早回来审核Merge Request
• 在Merge Request通过后，负责部署审核的人需要收到部署通知邮件，并可以在部署执行前，根据实际情况直接在这封邮件中拒绝执行这次部署

于是我们修改了这个流程，修改后的流程中有三个阶段：开发测试阶段，预发布阶段，发布阶段

开发测试阶段

每次开发人员push开发分支到GitLab，都会触发Jenkins自动打包项目并部署到测试环境，测试部门可以在测试环境对项目进行测试

预发布阶段

与开发测试阶段类似，只是开发人员push的不是开发分支，而是预发布分支，部署的环境也不是测试环境，而是预发布环境

发布阶段

1. 在通过测试部门的测试后，开发人员提交Merge Request，同时也提交项目部署信息，如发布时间等
2. 代码审核人员同意这次提交后，部署审核人员会收到部署通知邮件
3. 如果在发布时间之前，部署审核人员都没有拒绝这次部署，则部署会如期执行

由于只靠GitLab，Jenkins和RunDeck无法实现上述的发布阶段，所以需要开发一个中间系统专门处理这些部署信息，我们把它命名为IT AutoDeploy Platform，加入了这个中间系统后，整个发布阶段的流程图如下

在 基于GitLab，Jenkins和RunDeck的持续交付系统（二） 中将会大概描述一下这个系统的实现

转载于:https://my.oschina.net/u/3707083/blog/1551010