CI/CD自动化发版系统设计简介

转载自：https://www.cnblogs.com/wellful/archive/2004/01/13/10604151.html

版本迭代是每一个互联网公司必须经历的，尤其是中小型公司，相信不少人踩到过很多坑。

很多公司没有把配置独立出去，代码的构建、发版通过一个Jenkins job实现，这样很不好。弊端如下：

• 如果你有N个环境，你将会有N次编译、N次配置、产生N个包、发布N次......；
• 配置变更困难，可读性比较差；
• 版本发布总体时间长等等。

事实上我们需要：

• 一次构建多次发布；
• 具备包仓库，长期存储并备份成品包；
• 具备配置管理系统，实现集中管理配置且维护简单；
• 具备基本的回滚（备份）机制。

我的解决方案是：紧紧围绕Jenkins+Gitlab+Ansible建设发版系统，通过Jenkins框架集成Gitlab、Ansible、sonar等第三方重要服务，同时引入配置管理系统（百度开源的Disconf），引入成品包仓库（通过nginx+samba实现），再通过Ansible调度发布及回滚脚本。

大致流程如下图所示：

说明：

• Jenkins时刻监听Gitlab代码变化，当有研发人员向Gitlab提交代码时，Jenkins会自动触发构建、编译并打包；
• 再通过shell脚本自动将打好的包上传到成品包仓库；
• 发版人员从成品包仓库选取要发版的包上传到Jenkins发布job，执行一键发布；
• 业务代码在启动过程中会自动从Disconf系统中拉取配置完成配置并成功启动。
• 整个流程看起来通俗易懂，但要注意一些关键点要具备提高可用性，比如：构建及发布任务要做成集群、要具备回滚机制等等。 下面请看详细的工作流程图：

说明：

• 整个CICD最关键部分由Jenkins构成，Jenkins在这里主要充当平台作用，Jenkins由master/slave节点组成，master负责调度各个slave节点，真正干活的是各个slave节点。在这里，CI部分由2个jenkins slave节点组成，CD部分由2个Jenkins slave节点组成，CI与CD节点复用以高效利用资源；
• 当Gitlab有代码变动时，Jenkins CI节点会自动触发构建、编译并打包，然后将打好的包自动上传到成品包仓库；
• 成品包仓库主要由samba充当，发版人员可以添加samba磁盘映射到自己电脑上，发版的时候可以从samba仓库上选取要发版的包上传到Jenkins CD任务上；
• 通常测试环境与生产环境网络是物理隔开的。如果要发版测试环境，则Jenkins会调用内网Ansible服务，Ansible调用相关发布脚本实现发版，在发版过程中，代码服务会自动从测试环境Disconf下载并加载配置完成配置；同理，生产环境发版也是同样的流程。

值得一提的是，这套发版系统在投入使用之前需要做一些标准化操作，比如：代码包命名如何规范，CI/CD任务名称如何规范，成品包仓库中的包路径如何定义,代码配置如何独立等等，免不了一些沟通协调。

总体感觉：自动化不难，“难的”是标准化的规划及落地。