你真的在做持续集成吗？

在肖然的文章《ThoughtWorks的敏捷开发》里面，持续集成被认为是敏捷实践中最广泛共识的的技术实践（没有之一）。的确，相比于极限编程里面的其他技术实践，例如结对编程或者是测试驱动开发来说，持续集成比较容易上手，可视化效果比较好，团队能够比较容易看到带来的变化。所以很多团队在实施敏捷转型时，往往都把持续集成作为技术实践切入点。在我之前的咨询项目上， 在给团队规划敏捷转型技术实践路线时，也把持续集成放在第一阶段首先尝试的实践。但是，在经过了比较多的项目之后，我发现了一个问题，就是团队往往会把使用了CI服务器和实施了自动化编译、构建、测试等同于实现了持续集成。尤其是在Jenkins这款CI服务器流行起来后，团队甚至认为使用了Jenkins就是在做持续集成了。当我问起很多刚开始转型的团队你们有了解过CI吗，他们往往会回答“知道啊， 不就是Jenkins吗？”的确，Jenkins等CI工具的流行使大部分的开发者都或多或少听说过持续集成，但也造成了使用CI工具实现自动化等于持续集成这个不正确的认识流行起来。为了真正认识持续集成， 我们不妨就从字面解释开始，重新理解一下持续集成。

Jenkins（图片来自网络）

集成

首先， “持续集成”可以拆成两部分，持续与集成。我们先说集成。这里说的集成，与我们常说的系统集成或者集成测试里面的集成，概念上有点类似，但不尽相同。这里说的集成，首先指的是代码集成。简单来说，就是团队里面的所有开发者都往一个地方提交代码。如果整个团队就一个人在开发，只有他提交代码，那自然没有集成一说了。说起来简单，做起来很有讲究，讲究在“一个地方”。这里说的一个地方，不单指同一个代码仓库，而且是指同一个代码仓库的同一个分支。也就是我们一直倡导的主干。这种分支策略也就是主干开发策略。为什么需要同一个分支呢？这就要回到做持续集成的目的上来。持续集成，它一直想要解决的一个问题，就是被称为“集成地狱”的问题，也就是由于代码没有及时合并在一起，集成问题堆积导致在后面合并时出现大量代码冲突或者系统不能正常工作的问题。现代的软件开发工作大多是团队工作，团队开发者负责编写各自的代码，如果代码不能够做到及时合并，“集成地狱”问题必然不可避免。而如果做不到主干开发，证明代码其实不能及时的集成在一起，问题不能及时得到暴露并被解决，就不是真正意义上的集成。

客观来说，由于种种现实限制，很多团队并不能实现主干开发，或者是不能很快速的从多分支切换到单分支，但是团队应该在条件允许的情况下，尽可能早地把代码往主干上合并，尽量缩短其余分支的生命周期，并通过更好的规划，逐步过渡到主干开发策略。当我们做到了把代码统一合并到同一个代码仓库的同一个分支时，在自动化工具出现之前，就需要团队里面有专门的一个人，负责每天把合并完的代码拉到本地，进行手工编译、构建、测试，保证软件功能正常，然后打包并往目标环境部署。当软件功能不正常时，他还要负责排查解决。某种意义上来说，这个人充当了现在CI服务器的角色。

持续

说完集成，我们现在来说一下持续。字面解释就是延续，继续，无间隔，连续不断。要连续不断的把代码往仓库里提交。这里暗含了一个更深层次的要求，就是我们提交与拉取代码的频率要高。为什么提交与拉取代码的频率要高？我们举个简单的例子。假设团队有A、B、C三个人，他们都会往主干提交代码。第一天三人都修改了代码，但只有A提交了代码。第二天B在没有拉取最新代码的情况下继续修改代码，然后提交。这个时候就会出现三种结果：1. 两人的代码没有冲突，打包部署后功能正常；2. 两人的代码出现冲突，需要花时间合并与测试；3. 两人的代码没有冲突，但是打包部署后功能就是不正常，需要花时间调试与排查。三种情况中，情况1是皆大欢喜的，现实情况是，情况2和3才是经常出现的。但是更恶劣的情况还没出现。A和B花了好大力气好不容易把问题解决了，这个时候之前一直没有拉取和提交代码的C在第三天把本地的代码提交了，情况2和3很可能会再次出现。问题向扭麻花一样，解不开也一直得不到彻底解决。团队会一直陷入解决代码集成问题的漩涡之中。对团队来说，这是一件极为耗费精力又打击团队士气的事情。而造成这个问题的根源，是团队在拉取和提交代码的时候，频率太低了，导致代码的提交粒度太大，以至于出现代码冲突或造成软件功能不正常的可能性非常高。

解决这个问题的办法，就是要提高团队拉取与提交代码的频率，降低每次提交的代码量。我把它称作小批量高频提交。其实小批量是高频提交的结果，一旦做到了高频率的提交，每次提交的代码量自然不会太多。

小批量高频提交，也是说起来简单做起来难的事情。在我接触的的团队中，能够做到坚持一天提交一次的已经是不错了。团队往往把代码提交这件事情看的过于“重要”了。很多开发者都抱有一个观点，就是必须得把整个大功能做完了，才能提交代码；在大功能做完前，提交的代码都是不完整的，生怕自己提交不完整的代码有什么问题导致软件异常。 其实功能的完成度与代码提交是两回事。在提交代码的时候，我们只要保证提交的那部分代码得到验证，功能正常，并且不会与别人的代码冲突，就可以了，并不需要刻意追求整个大功能的完成度。我在平时写代码的时候，一般会写那么几行，本地测试验证通过了， 就会提交，然后继续写几行，本地测试功过，然后提交。因为都是我自己一个人维护的代码仓库，所以就不会那么频繁的拉取。一天下来提交的次数可多达20到30次。当然这个是我个人的习惯而已，并不适用于所有人。 但是团队在平时写代码的时候，一定要把提交代码这一步骤当作是写代码的其中一环，逐步养成拉取-编写-提交的习惯，并逐渐提高拉取与提交的频率。至于提交的频率要达到多高，这个其实并没有一个标准，而是因团队，因个人而异，在符合团队实际与降低代码集成问题之间寻找平衡。

编写代码三步曲（以Git为例）

一旦团队实现了小批量高频提交，上面提到的专门负责把代码拉取到本地测试然后往目标环境部署的人就会忙不过来，他会一直忙于这种重复性的构建工作。为了把他解放出来，于是就有了CI工具与自动化。

工具与自动化

网上已经有很多关于怎么使用工具配置持续集成流水线以及与自动化测试、部署串联起来的 教程与文章，这里不打算展开了。坦白来说，工具与自动化是解决效率问题。当团队真正实现了代码往一个地方提交，并且是小批量高频提交后，工具与自动化能把团队从繁重的构建、测试与部署的重复性工作中解放出来。仅此而已。所以在持续集成中，工具与自动化是很重要，但并不是最关键的。它们能充分发挥作用的前提条件是团队真正做到了主干开发与小批量高频提交。否则，即使用上了最先进的工具与自动化手段，持续集成的效果也会大打折扣。

总结

经过以上的分析发现，其实持续集成的字面解释就已经蕴含了其精髓。集成与持续，分别从空间和时间两个维度定义了CI的两个核心实践：主干开发与小批量高频提交。 良好的持续集成 =主干开发与小批量高频提交（人的因素） + 一定程度的自动化（工具的因素）。而其中，人是践行CI实践的核心一环，人才是核心因素，工具与自动化解决效率问题，以人的实践为前提并起重要作用。团队在实践持续集成的过程中，一定要注意以人为本，坚守CI纪律，持之以恒，而不是以工具与自动化为本，本末倒置。