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

公司计划推行持续交付，系统更新部署再也不经过人工操做，咱们打算使用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的持续交付系统（二） 中将会大概描述一下这个系统的实现