持续集成、持续交付、持续部署

持续集成、持续交付、持续部署

三丰 soft张三丰
“最后一哩”问题
　　持续集成解决了软件开发中的部分问题，但还有更为重要的一部分有待解决，即“经过什么样的方法，可让软件尽快地在真正的生产环境下运行，从而实现软件的价值”。在软件开发过程当中，“从功能开发完成开始直到将其部署至生产环境中正式运行”这一阶段被称为“最后一哩”。若是从一开始就对产品发布足够重视的话，那么这“最后一哩”可能只须要几分钟，甚至几秒钟就完成了。然而，事实上大多数项目在这一阶段会花上几个星期，更有甚者可能会是几个月。
　　为何会这样呢？对于复杂软件来讲，不管什么环境中的部署（测试环境，试运行环境，仍是生产）都很困难。当软件第一次被部署到非开发环境去测试，或者当软件功能及其环境有较大变化时，一般都会暴露出不少问题。而在作用户验收测试时，经常会发现更多的问题，例如不能知足非功能需求，用户操做不方便，功能与用 户真正须要的东西相差太远等等。而开发团队只有修复这些缺陷后，才能再次部署测试。因而，这个过程会不断反复，直至该软件足够稳定，才能够部署到生产环境中。
　　即然部署到测试环境都这么困难，那么在生产环境中部署的风险岂不会更大吗？并且，更为严重的是：当生产环境部署出现问题时，摆在你面前的选择就所剩无几啦（一般是回滚到之前的状态，而“回滚”这段时间的停机成本是至关高的）。
上述缘由就会致使大多数组织对产品的发布采用“保守策略”，即下降软件的发布频率，这也致使两次发布之间的版本特性差别相对较大。这样一来，发布风险并未因发布间隔时间加长而下降，反而更高了。当各方面的因素结合在一块儿时，软件发布这一环节就变得昂贵而又缓慢啦。而一般“发布过程与频率”决定了产品在市场中的位置。
　　那么，如何更好地解决“最后一哩”这一问题呢？实现持续部署！即将持续集成实践扩展到整个软件生命周期频繁且规律性地自动构建代码并将其部署到测试环境中，而后经过一系列的测试，选择适当的版本部署到预演环境中试运行，最后选择稳定的版本部署到生产环境中，从而使开发团队尽早从最终客户那里获得反馈，而最终客户尽早获得软件的价值。

墨菲定律你们都不陌生，越是担忧什么就越会发生什么；在多团队协做时，好比系统对接时，咱们都会担忧对接是否顺利，每每也不枉咱们担忧，时常咱们会被集成折磨得焦头烂额。有不少团队只是担忧，并无拿出有效的措施去避免这种事情发生，以致于延长了交付时间。既然担忧，咱们何不及早集成，把问题先暴露出来？

目前多数公司都已经使用了版本管理工具来管理源码，好比GitLab、SVN 等版本管理工具。在版本管理这一块，公司会根据本身的实际状况来制订版本管理办法。对于持续集成来讲，业内建议只维护一个源码仓库，下降版本管理的复杂度。开发人员持续提交本身的修改，自动触发编译，自动集成，自动进行自动化的测试，及早反馈集成过程当中的问题，就能更好地防止出现平时不集成、集成就出问题的现象。

经过自动化的持续集成，把管理流程固化；保证集成的有序性、可靠性；减小版本发布的不合规性（开发或者测试手动打包，可能一天打多个包，更新屡次，测试不充分），保证版本可控，问题可追溯（至于哪一个版本出现的问题，能够回溯）。

一旦把这种持续集成的过程固定下来，造成一个自动化过程，就具有了持续集成的能力，软件交付的可靠性就大大加强，这无形也是一种竞争力。这种竞争力保证了集成的有序性、可靠性。过程的自动化抛弃了人工，下降了出错率，提升了速度，天然会节省成本。

对于大规模的CI&CD，一旦系统数量、实例数量上去后各类问题就都来了。下面列举几个主要的问题。

1）更新问题。更新一次要耗费大量精力，不少企业都是晚上更新，员工得通宵加班，还不能保证更新没问题，不具有快速大批量部署的能力。

2）部署包（jar 包、war 包、ear 包等）的管理问题。为了保证版本可追溯，出错后可以回滚，咱们须要保存各个历史版本，并且方便下载。

3）版本的安全性。传统上以Java 语言开发的系统多数以jar 包、war 包、ear 包的方式发布，容易被篡改（人为修改，传输过程不完整）；一般咱们用md5 来验证完整性，但包与md5 对应关系的管理并无系统化，每每在出问题后人工进行md5 验证。

4）主机管理问题。系统部署到哪些机器上须要进行主机管理？在部署时人工选择部署到哪台主机显然不是一种明智的方式，可否自动进行调度？同时，不会产生有些主机性能堪忧、有些主机空闲致使的负载不均状况。

5）端口管理问题，在部署Java 项目时咱们并不建议设置太多的JVM 内存，所以一台主机上每每可以部署多个应用实例，同一台机器上多个实例的开放端口就必须不一致，因而端口又成了须要管理的资源。有人会说能够选用虚拟机，一台虚拟机上只部署一个实例。固然，这也是能够的。实际上，多数企业也是这么作的。这种作法也有弊端，虚拟机虽然帮助作了隔离，但会损失一些主机性能；虚拟机要使用内网IP，这样IP 又成了稀有资源，当部署多个实例时IP 会不够用。

6）负载均衡管理问题。不论是在主机上部署多个实例，仍是利用虚拟机来部署多个实例，在作集群时，都会经过代理（Nginx、Apache、LVS……）软件来作负载均衡，所以咱们须要把各实例的访问地址配置到负载器的配置文件中。实例数少的时候手工配置还能够接受，多了就无法手工配置了。固然，方法也会有，好比用Etcd+Confd+Nginx（HAProxy）来作服务发现，咱们须要本身部署一套工具，并进行维护，复杂的框架提升了对运维人员的要求。

7）服务伸缩问题。当服务访问量上去后，要可以具有快速扩充的能力；当访问量下去后，要可以具有缩小服务规模的能力，收放自如。这种弹性的服务能力显然是经过工具来完成的，手动完成是不可能的。

8）IP 管理问题。当大规模部署后，IP 资源会成为稀有资源，如何用更少的IP 来部署更多的服务？IP 的分配及管理显然不能人工完成，那样效率太太低下，这就须要一个IP 管理工具。

DevOps静态架构

CI&CD 流程

持续集成 的含义为：频繁的（一天屡次的）将全部开发者的工做合并到主干上。
以图例说明持续集成的流程：

从图例上来看持续集成的流程就十分清晰了：

• 开发人员提交代码到 Source Repository （源代码仓库），并经过 git hook 等
• 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 的流程，
• 向开发人员反馈结果的 report
  能够看出，持续集成的 核心 在于 确保新增的代码可以与原先代码正确的集成。与后续要介绍的持续交付以及持续部署，其最主要的差异也就在于其目标不一样。

  持续集成的优点

和咱们一直在使用的 阶段集成（完成一个阶段的开发后执行代码的集成） 相比， 持续集成 的策略可以为咱们带来哪些好处呢？

• 易于定位错误：每一次的代码集成都须要执行相关的测试工做，持续集成频繁的集成次数自然的将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误可以更加容易的被定位；
• 易于控制开发流程：更为细致的工做提交也就意味着更容易判断当前的工做进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工做的时间；
• 易于CodeReview：对于大块工做的切分天然也有助于作 CodeReview；
• 易于减小没必要要的工做：build 以及 test 过程的自动化能够为你节约一大票的时间，从而投入到有价值的工做中去。
  在传统的团队组织方式中，开发人员与运维人员之间是割裂开的，软件开发流程被分割为多个独立环节，分别由不一样的人员执行。这使得软件开发过程当中须要付出高昂的沟通成本，层层手动的流程将大量的时间耗费在了重复的劳动中。在 DevOps 的指导下，不一样技能的人员处在同个团队中，为了一个共同的软件开发目标而工做，更好的协同工做与自动化的手段可以优化整个 Code -> Build -> Test -> Release -> Operate -> Code 的循环。这一理念看起来很美，用图画来讲明就构成了一个和谐友好的大圈，不过在实际应用中也许会遇到很多问题，例如不一样技能人员之间相互沟通的额外开销、团队组织形式改变后为管理所带来的困难等等。这些问题大概等到真正将 DevOps 在开发过程当中开展来才能作解答了。