转载自：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任务名称如何规范，成品包仓库中的包路径如何定义,代码配置如何独立等等，免不了一些沟通协调。
总体感觉：自动化不难，“难的”是标准化的规划及落地。