什么是自动化部署系统？

我经历了从窝窝团到云纵，再到禧云的心路和技术历程，从优秀的团队里学到非常多先进或者独特的技术理念。
其中团队的领导者郑昀，毕业于中国科技大学，曾就职于北京移动、明天高软、神州泰岳、玩聚网（创始人）、窝窝团（研发总裁）。
得益于丰富的学识和经历，他将自己的理念形成工具，积沙成塔，为几百上千规模的研发团队提供有力的研发基础保障。
其中，CloudEngine（简称CE），可以视作自动化部署系统。

在从禧云离职后，我到了微云（江苏微云人工智能有限公司），负责后端架构，团队正处于创建阶段，一穷二白，团队内部连 GitFlow、Docker 都不知为何物😅，正在运行的项目出现问题，都是修改后 FTP 上传。
随着团队人员的扩增，需求的增多，不论是框架还是开发、测试流程，都亟需升级。
基于 CE 的使用经验，花一周时间，使用 PHP + Nginx + Docker + Git + Shell 搭建了一个非常简陋的【开发->测试】系统。

这个简陋的系统只有一个服务列表，和一个创建服务按钮。

创建一个服务：

第一个版本的实现功能只有服务创建和服务查看，目标是让多个业务工程，每个业务工程的不同需求都能并行开发，并行测试。 解决了研发和研发，研发和测试之间的社会矛盾。

同一个工程，可能存在多个需求同时进来，一个研发人员负责一个需求开发，这个系统可以满足他两个人把自己的 feature 分支创建成两个独立服务，他们自己提交代码，自己创建和重启这个服务，开发完成后，分别把服务的地址交给对接的测试人员。

1.0 版本的系统在后续的两周里，逐步增加了针对前端工程的支持。

1.0 版本的系统运行了三个月，反应良好，再也不用 ftp 上传了，只要点一下重启，即可搞定。

1.0 在测试环境运行期间，我重构了 Shell 和 PHP 脚本，在 PROD 环境也部署了一套，重构后的系统，支持一个服务，多个容器，实现了一个简单点的负载均衡。并且，后续上线，可以点一下就能发布了，由于是采用了 git 分支，可以随时回退。

简而言之，自动化部署系统是提升研发、测试、发布效率的一个工具，这个工具除了服务的部署、重启、删除，后续还能整合可视化分支创建、合并、Finish、一键创建测试服务、灰度发布等各种效率功能。让非研发部门的同学也能通过点一点完成研发和运维工作。

1.0 版本的技术细节

• 流程图

  

通过这张图，相信你自己也能在短时间内搭建好一个虽然简陋，但是能解决并行开发，并行测试问题的自动化部署系统。

2.0 版本的技术细节

本章不具体介绍 2.0 版本的实现逻辑，只是简单介绍下相比 1.0，它增加了哪些功能。

• 增加应用概念

  在项目实际的开发过程中，我们发现，一个 GitLab 工程，可能会包含多个应用。

  例如：你有一个 Yii 工程，它对应的业务是一个商城，这个商城系统有 PC 端和 App端，而 PC 和 App 的业务是不一致的，但他们又有很多重叠的功能：例如购物车模块。此时，你的工程中将会自然的存在两个目录，shoppc + shopapp，这两个目录可以理解为两个应用。

  这两个应用可以共同调用此工程中的 common 模块，common 模块包含两个应用共通的一些函数或类。

  此时我们在使用自动化部署系统 1.0 版本创建服务的时候，除了选择工程，还要选择应用。

  然后 2.0 版本增加了【应用列表】【新增应用】【编辑应用】，还有创建服务时的【选择应用】

• 增加 Gitlab 钩子

  在创建服务的时候，我们优化为不允许手动填写分支名（手残是常事），使用者直接选择即可。

  但是要实现这样的功能，我们需要知道所有工程的分支变化情况，我们发现 Gitlab 有强大的 WebHook 功能，我们利用这个功能，实现了分支的及时同步。

  Gitlab 将工程分支的变化通知给自动化部署系统，系统将分支记录下来，这样，使用者就可以自行选择了。

  由于业务系统占用了主要的开发时间，2.0 的功能迭代比较小，属于在挤时间挤出来的迭代。

3.0 版本的技术细节

3.0 版本将是一个重大的版本更新，包括：权限划分、分支管理、按单号一键生成提测服务、按单号一键重启测试服务、热修改配置文件等重要更新。

从研发开发、测试、发布上线这个流程上，3.0 版本通过权限划分了研发、测试、运维的职能。

研发人员只有 feature、hotfix 分支权限，具有 finish 权限；测试人员具有 feature/*-test、hotfix、support 分支权限；运维人员具有 release 打包和上线权限。

研发人员收到需求后，通过单号，创建一个 feature 分支，然后进入开发阶段，开发完成后，邮件告知测试人员提测。

测试人员收到提测通知，登录自动化部署系统，只需要输入一个单号，就能一键生成该需求对应的所有测试服务。测试完成后，邮件告知产品验收。

产品收到验收通知，按照邮件中的服务地址验收，验收通过后，回复邮件验收通过，抄送运维人员上线。

运维人员收到通知，登录自动化部署系统，输入同样的需求单号，选择要发布的工程，然后一键生成该需求对应的所有 release 分支。

3.0 版本主要规范了各部门之间的配合，规避了测试部门反映强烈的服务不稳定问题。同时也让工具代替了 git 分支的管理，降低了分支管理的成本。

3.0 版本的一些细节还在优化中，预计将于 2022年1月11号 对各部门进行使用培训。

4.0 版本的展望

由于 3.0 版本的某些功能还在优化中，4.0 版本将在未来推出。

4.0 版本将包含以下功能：

• 给运维人员增加【发布上线】列表，列表支持【灰度发布】【全量上线】【回滚】操作。
• 优化运维人员输入单号后，还要选择对应工程才能创建 release 分支的功能。支持一键创建。
• 编写 install.js 和 install.exe 文件，达到开源标准，支持一键部署安装。