CICD自动化发版系统设计简介

 第一篇。

版本迭代是每个互联网公司必须经历的，尤为是中小型公司，相信很多人踩到过不少坑。接下来的一系列文章将介绍我设计的自动化发版系统！

不少公司没有把配置独立出去，代码的构建、发版经过一个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任务名称如何规范，成品包仓库中的包路径如何定义,代码配置如何独立等等，免不了一些沟通协调。整体感受：自动化不难，“难的”是标准化的规划及落地。

在稍后的几篇文章中我将持续更新，努力将每一步都3D式的呈如今你们面前。

 

敬请期待～