CI漫谈

持续集成（CI）在软件开发中是一个流行的技术，特别是伴随着微服务以及devops，这个名词被吵得更火了，在各种大会上人们都会谈到他们自己是怎么玩的，而且持续集成的工具也有很多。

三个问题验证CI

但是我们都知道，任何正规的技术最后都需要一个认证程序。幸运的是，现在已经存在了。

下面的一个有趣的问卷调查据说就算是一个认证程序。以下的场景是我们从Martin Fowler的文章中找到的。

说有个叫Jez Humble的总是喜欢通过如下几个问题来衡量团队们是不是在做持续集成，团队们做的持续集成到底算不算真正的持续集成。

Jez Humble一般会通过提问题然后让观众们举手的方式来进行这个认证程序。这听起来就感觉很有意思。他会让那些认为自己正在践行持续集成的观众举起手来。

一般情况下大多数观众都不假思索的举起了手。

然后他让那些在团队中至少每天都commit并push代码到一个共享的mainline（一般就是git 上master，主干），让这些继续举手，其他人把手放下来。

于是，超过一半的人放下了手。

然后他让那些每次commit都会触发自动build和test的人继续举手，其他人把手放下来。

于是，又有接近一半人把手放了下来。

最后，他让那些当build失败后十分钟内会解决问题并回到green状态的继续举起手来，其他人把手放下来。

最后一个问题下来，只有很少的人还举着手。这些人通过了认证测试。

这是一组非常简单的问题，但却一下子把持续集成的核心讲了明白。

那就是，持续集成意味着整个team随时知道，至少是最短时间内知道代码最近的状态和进展，避免大的有风险的merge，这样人们可以尽可能地去重构。

这就是为什么一开始人们都乐观的举起了手。就是我们一般认为持续集成就是运行一些持续集成的工具。

持续集成的由来

但是持续集成也许并不是这样。这个概念最初是被一个名叫Kent Beck的人所描述和命名的，最开始是作为极限编程里的一部分，那时候还没有什么工具。

最开始它只是一个人工来操作的流程，之后有个叫Jim Store的人制造了一起大讨论（或者你可以叫“血案”），最终理清了持续集成应该有的样子。

后来人们想到对源代码运行一个守护进程，这个就比较自动了，如果它运行在人们每天commit的主干之上的话。

当然了，据说如果你只是把守护进程运行在每个功能分支上的话，那么这是为了守护而守护，Daemonic Continuous Integration ！

你搞了这么一套工作流，并不会给你带来什么好处，搞得你这套流程看起来没有起到持续集成的作用。（该观点为个人观点，仅供参考）

持续集成细枝末节

也许通过上面的的一组问题，你已经知道了什么才算是持续集成。如果你想要了解更多的话，下面我们就来慢慢说说有关持续集成的细枝末节吧。

把多个开发者的代码合并到一块是一件麻烦事。

软件系统是比较复杂的，对一个明明很简单，独立的一个文件的改变就可能会危及系统正确性。

结果就是有很多team的程序员的工作成果被隔离在他们自己的分支上，从而来保证trunk或者master的稳定，这样避免人们之间相互干扰影响到对方。

然而，随着时间的推移，这些分支们走得越来越远。就像你把某开源实现拉下来自己做二次开发，结果渐行渐远，等开源出新版本，你发现你已经无法升级了。

将这些分支中的单个分支并入主干还并不是很困难，但是将多个分支集成到主干中所需的工作通常是痛苦的，需要大量的重新工作。

那些使用“长命”（long-lived）分支的团队通常需要代码冻结，甚至集成和稳定阶段，因此他们在发布之前才集成这些分支。

上面这样的合并，即使你使用工具，这个过程依然还是昂贵和不可预测的。对于一些比较大的团队来说，多个branch的集成需要多轮回归测试和错误修复，以验证系统将在这些合并之后能够按照预期工作。

而且随着团队规模的扩大，分支变得越来越独立和长寿，上面的问题也就变得越来越严重。

持续集成被发明出来就是为了解决上面的问题的。 持续集成遵循XP（极限编程）的原则，那就是如果某个事情比较痛苦，我们就应该更频繁地做，并把痛苦提前。

这样的话，开发人员定期会把他们的代码集成到主干上（trunk/master）,一般至少每天会集成一次。

另外的话，你还需要准备好一组自动化测试用例，在合并之前和合并之后都测试一次，来验证有没有引入回归问题。如果这些自动测试失败了，那么团队应该停掉当前他们在做的事情，然后让一些人把问题立即修复掉。

这样的话，我们就可以确保软件一直是处于可运行状态，而且开发人员的分支也不会与主干偏离太远。

持续集成也有争议

持续集成所带来的好处是非常明显的：有研究表明它可以带来更高的吞吐量，更稳定的系统，更高质量的软件。但还有人觉得持续集成并不是很好，他们觉得这种做法有争议，主要有以下两个原因。

第一个原因就是它需要开发人员去分解一个大的功能，并且其它任何改动都尽可能的小，通过更频繁而小的步伐集成到trunk/master。

对于不习惯这种方式工作的开发者来说，这是一个工作方式的转变。而且这种做法也会使得一些比较大的功能点完成起来需要更长时间。

其次一个原因就是持续集成需要一套快速运行的综合自动化单元测试。

这些测试应该是足够全面的，使得我们通过这个测试就可以相信该软件将按预期工作，同时还应该在几分钟内或更少时间内测试完毕。

如果自动化的单元测试需要花较长的时间才能跑完，那么开发人员们就不会频繁地跑这个测试了，他们嫌慢；而且这样的单元测试维护起来也比较难。

创建一套可维护的自动化单元测试套件是比较复杂的，最好的做法就是通过“测试驱动开发”（TDD）来完成，这样的话开发人员就会在写实现代码之前先去写自动化测试用例，从而来确保测试通过。

TDD有很多的好处，其中最重要的一个就是它可以确保开发人员写的代码更模块化，也更容易测试。

但是TDD现在仍然没有得到广泛的用于实践，很多时候人们都只是说说而已。

总结

尽管有这些羁绊，帮助软件开发团队实施持续集成依然是那些希望实现持续交付的公司的首要任务。通过创建快速的反馈循环，并让开发人员小批量地工作，CI可以让团队保证他们的软件质量，从而降低持续软件开发的成本，并提高团队的生产力和产出物的质量。

总之，看了上面那么多，你也许发现了。CI具有如下属性：

• 只有一个Repository
• 自动build
• 自动测试
• 每个人至少每天提交代码到主干
• 每次commit都应该在一个集成机器上build主干
• 短时间修复构建遇到的问题
• 保证短时间内可完成build和test
• 测试是在一个线上环境的模拟版上进行（预发布环境）
• 让所有人都可以容易的得到最新的可执行代码和文件
• 每个人都可以知道代码最新的状态
• 自动部署

其实早在10多年前持续集成就已经被实践了。 我们看到在世界各地都在使用它。 甚至也几乎听不到关于这种方法负面的东西。

如果你不使用持续集成，建议你试试。 相信你已经在用了，也许看了这篇文章后，可以帮助你更有效地去实践。 本文中的描述和观点难免疏漏甚至相左，仅供参考，如果你有更好的看法，欢迎留言讨论。