这才是DevOps演进及CI/CD实践的正确打开方式！( 三 ) 本文根据张鹄干老师在〖deep

文章图片
容器发布&虚拟机发布构建打包示意图
2）多分支开发，主干上线
在测试阶段，可以用各种分支进行开发测试，测试通过后，就必须合并到主干，然后用主干进行发布上线。

文章图片
3）一次构建处处使用
考虑到设置的分支策略，于是我们规定，测试环境的制品只能用于测试环境使用，这样一来就需要在预发布再进行一次构建操作，而此次的制品因为是经过测试而合并到主干的代码生成的，所以认为是稳定可靠的，于是在后续的环境中，将不需要再次构建，而直接使用预发布生成的制品。

文章图片
4）使用Jenkins作为后台构建作业机器
采用多master ，多slave的Jenkins集群方案，其中master只做调度， slave执行确定任务，我们预先在jenkinsmaster上创建了流水线对应的job ，图中的左边是我们自研的流水线服务，用Java编写的，通过调用jenkinsAPI触发构建， jenkinsmaster调度slave节点执行job,然后左边的流水线服务定时调JenkinsAPI获取构建状态和结果，实时更新推送记录的状态和日志。

文章图片
现在，我们将需求发布流程和流水线结合起来，就能得到下图所示的标准生产过程。

文章图片
5、线网故障快速回滚机制
上面我们讲了流水线，现在来讲一下，如果上线出现了问题，如何进行回滚。不知道大家有没有注意到上图的一个细节，那就是在预发布的时候，有一个任务——打tag ，而这个操作就是我们实现回滚的关键。
这个打tag主要做了两件事情：在git上生成tag ，代表此次的代码是稳定的，可以上线的；保存了一条记录，代码版本和制品版本以及本次tag的记录。
现在我们看看这种情况：

文章图片

文章图片
比如现在我们发布了一次线上，发布的tag版本是v1.3.35 ，对应的代码版本是a ，镜像是A ，这次发布是成功的，没问题的。
然后我们又发布了一个版本到线上， v1.3.36,对应的版本是a ，镜像是A ，当发布到线上后，发现服务异常，于是需要进行回滚操作，选择上一次成功的版本v1.3.35,因为保存了这个版本对应的代码信息和镜像信息，所以当选择这个版本时就能找到这个正确的制品，然后触发一次流水线，就进行了回滚。整个过程可以控制到几十秒内，让线网故障导致的损失降到最低。
最后，我们看一下整个devops的生态链：

文章图片
至此，我们的devops第一阶段完成。
1）带来的意义与价值：研发过程标准化，责任制管理研发生产资料，交付过程更可靠；提供多种工程模板，无需从零搭建工程，降低开发成本的同时，统一技术栈，规范代码研发；CI/CD自动化，支持高频构建(支持500+研发人员日常构建) ，降低运维成本(运维同学从40人减少到10人)；线网故障快速回滚，提升全站可用率。
2）不足之处：流水线执行过程不够灵活，导致负载过高，耗费更多资源；工程全生命周期管理缺失关键路径，大量工程处于散养状态；基础服务和工具众多，需要多个平台间切换，增加开发人员负担；没有高效自助执行的研发类工作流，大量实际工作需要人工处理；缺乏成本管控手段，服务器成本居高不下。