为何咱们迫切须要持续集成？

【编者的话】持续集成（Continuous Integration），也就是咱们常常说的 CI，是现代软件开发技术的基础。本文论述了当前软件开发过程当中存在的问题，讲解了持续集成、持续集成服务器的概念，最终探讨了为何咱们须要持续集成来解决这些问题。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。

当前软件开发过程存在的问题

在没有应用持续集成以前，传统的开发模式是这样的：

• 项目一开始是先划分好模块，分配模块给相应的开发人员；
• 开发人员开发好一个模块就进行单元测试；
• 等全部的模块都开发完成以后，由项目经理对全部代码进行集成；
• 集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；
• 测试过程当中出现 Bug 就提把问题记录进行 Bug 列表中；
• 项目经理分配 Bug 给相应的责任人进行修改；
• 修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；
• 测试人员在下一次的集成测试中进行回归测试；
• 经过经过以后就部署到生产环境中；
• 若是测试不经过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测* 试服务器上 -> 集成测试”工做。

这个过程当中可能会出现以下问题：

1. Bug 老是在最后才发现
   随着软件技术的发展，软件规模也在扩大，软件需求愈来愈复杂，软件已经不能简单地经过划分模块的方式来开发，每每须要在项目内部互相合做，模块之间存在必定的依赖关系，那么早期就存在的 Bug 每每会在最后集成的时候才被发现。

2. 越到项目后期，问题越难解决
   不少开发者须要在集成阶段花费大量的时间来寻找 Bug 的根源，加上软件的复杂性，问题的根源很难定位。并且咱们都清楚，间隔的时间越久，Bug 修复的成本越高，由于连开发人员本身都忘了当初写得是什么鬼代码，从而不得不从头阅读代码、理解代码。

3. 软件交付时机没法保障
   正是由于咱们没法及时修复 Bug，或者是没能在早期就修复 Bug，从而令整个修复 Bug 的周期拉长了。无论怎么样，咱们不可能把明知存在 Bug 的软件交付给客户。

   并且，大量没有在前期预估到的工做量产生了——开发人员不得不花费大把时间在查找 Bug 上；测试人员不断的须要进行回归测试；项目经理不得不疲命于该死的代码的集成、部署这些重复性工做——最终致使整个项目的周期拉长，交付时间点日后拖。

4. 程序常常须要变动
   某些项目，程序会常常须要变动，特别是敏捷开发的实践者。因为产品经理在与客户交流过程当中，每每实际的软件就是最好的原型，因此软件会被看成原型做为跟客户交流的工具。固然，客户最但愿的固然是客户的想法可以立刻反映到原型上，这会致使程序会常常被修改的。那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工做无形又爆增了。

5. 无效的等待变多
   有可能开发在等集成其余人的模块；测试人员在等待开发人员修复 Bug；产品经理在等待新版本上线好给客户作演示；项目经理在等待其余人提交代码。无论怎么样，等待意味低效。

6. 用户的知足度低
   这里的用户是广义的，能够指最终的客户，也能够是产品经理、公司领导、测试人员，甚至多是开发人员本身。你想一想看，原本三个月作完的项目被拉长到了九个月甚至一年，用户能满意吗！产品经理、公司领导常常须要拿项目做为演示的原型，结果告诉我在演示前一刻发现还有不少 Bug 没有解决，项目启动不了没法访问，这叫人情何以堪。

持续集成、持续集成服务器的概念

那么好了，在上面论述的这些问题中，咱们发现有些工做是没法避免的，好比测试工做、修改程序、集成工做、部署工做。但其实在整个工做流程上，是存在能够优化的空间的，好比，集成测试的工做是否能够提早作？能否有自动化的手段来代替测试、集成、部署工做？围绕这些，软件行业的大师们提出“持续集成”口号。

1. 什么是持续集成、持续集成服务器
   在软件工程中，持续集成（CI）是指将全部开发者工做副本天天屡次合并到主干的作法。 Grady Booch 在1991年的 Booch method 中首次命名并提出了 CI 的概念，尽管在当时他并不主张天天屡次集成。而 XP（Extreme programming，极限编程）采用了 CI 的概念，并提倡天天不止一次集成。

   而持续集成服务器就是可以采用自动化的手段，来解放人的双手，实现项目持续集成的工具。与之配套的软件有 TeamCity、Jenkins、Go 等。

2. 怎么样才算是“持续”
   对于一天须要集成多少次数，并无一个明确的定义。通常就是按照本身项目的实际须要来设置必定的频率，少则可能几回，多则可能达几十次。能够设置按照代码的变动来触发集成，或者设置一个固定时间周期来集成，也能够手工点击集成的按钮来“一键集成”。

3. 持续集成的工做流程

   • 当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本。
   • 当其余开发人员将更改的代码提交到代码库时，此副本将逐渐中止反映代码库中的代码。代码分支保持检出的时间越长，当开发人员分支从新集成到主线时，多个集成冲突和故障的风险就越大。
   • 当开发人员向代码库提交代码时，他们必须首先更新他们的代码，以反映代码库中的最新更改。
   • 当存储库与开发人员的副本不一样，他们必需要花时间来先处理冲突。

持续集成的好处

1. 解放了重复性劳动
   自动化部署工做能够解放了集成、测试、部署等重复性劳动，并且机器集成的频率明显能够比手工的高不少。

2. 更快地修复问题
   因为持续集成更早的获取变动，更早的进入测试，也就能更早的发现问题，解决问题的成本显著降低。

3. 更快地交付成果
   及早集成、及早测试减小了缺陷遗留到部署环节的机会。在某些状况下，更早地查找错误还会减小解决错误所需的工做量。

   若是集成服务器对代码进行构建过程当中发现错误，能够及时发送邮件或者短信提供给开发人员进行修复。

   若是集成服务器在部署环节发现当前版本有问题不可用，集成服务器会将部署回退到上一个版本。这样服务器上始终都会有一个可用的版本。

4. 减小手工的错误
   人与机器的一个最大的区别是，在重复性动做上，人容易犯错，而机器犯错的概率几乎为零。因此，当咱们搭建完成集成服务器后，之后的事就交给集成服务器来打理吧。

5. 减小了等待时间
   持续集成缩短了从开发、集成、测试、部署各个环节的时间，从而也就缩短了中间能够出现的等待时间。持续集成，意味着开发、集成、测试、部署也得以持续。

6. 更高的产品质量
   集成服务器每每提供 Code review、代码质量检测等功能。对代码不规范或者有错误的地方会进行标识，也能够设置邮件、短信等进行告警。而开发人员经过 Code review 也能够持续提升编程的能力。

持续集成的最佳实践

1. 频繁检出代码
   为了让你本地的副本和代码库中的版本最小差别化，建议频繁检出代码。有时候代码冲突无可避免，但最小差别化最容易解决。并且，越早发现的问题，解决成本也最低。

2. 频繁提交代码
   这个与第1条的原理相似，频繁提交代码，可让其余人的检出副本和代码库中的版本最小差别化。

3. 减小分支，回归主干
   虽然代码管理工具都支持分支的概念，但应尽可能减小其使用。假设有多个分支并行，应及早将变动集成到主干中，而不是同时维护软件的多个版本。主干做为软件开发的工做版本。

4. 使用自动化构建
   可使用 Maven、Ant 等来实现自动化构建，这些工具能够帮助你在构建过程当中实现自动化测试。前提是你有写单元测试用例，好比 JUnit 等。

5. 提交自测
   在提交工做以前，每一个程序员必须本地集成全部的代码，作一个完整的构建和运行，并经过全部单元测试。这样就减小了集成测试在集成服务器上构建失败的风险。

6. 当前状态对于每一个人均可见
   集成服务器在持续集成过程当中发现问题，应能发送告警给相关的干系人。同时，也能够在墙上等醒目的位置设置一个大屏显示器，将集成服务器的状态实时展示在大屏上，方便提醒组员“赶忙回去解决问题”！

持续集成可能会面临的挑战

1. 团队人员思想上的抵触

   • 没法接受新事物：无论怎么样，求稳心态的人仍是多。老是有人认为老的技术表明稳定，新的事物每每会带来问题。
   • 认为手工集成也没有多少工做量：不是全部的人都参与到了整个持续集成的环节，因此没有办法认识到问题全貌。

   针对这个问题，能够经过设置必定的持续集成技术培训、宣讲获得改观。

2. 管理层的抵触

   • 培训持续集成须要投入资金啊，没钱。
   • 持续集成服务器要增长软硬件成本啊，没钱。
   • 开发人员领了那么高的工资，多干活多加班应该啊。

   针对这一点，能够从开发人员的成本和持续集成的投入（软硬件）的成本上二者作下估算。

3. 生产环境的复杂

   好比部署的生成环境是在政务外网，没法从互联网直接访问等。

   目前，这个是最麻烦的，还在研究中。初步设想是让政务外网开辟一个白名单，给持续集成服务器设置一个单独的通道。只是思路，未验证。

   固然，考虑到目前的工做的实际，能够先持续部署软件到本身公司的演示服务器上，这样，起码先解决了客户和产品经理沟通所使用的原型问题。 毕竟，客户真实使用的软件在更新的频率上能够适度的放宽。

参考资料

• Grady Booch. Object-Oriented Design with Applications.Benjamin Cummings，1991，3(5):209
• Paul M. Duvall，Steve Matyas，Andrew Glover.Continuous Integration：Improving Software Quality and Reducing Risk.Upper Saddle River：Addison-Wesley，2007
• martinfowler.com/articles/co…

原文连接：dockone.io/article/260…