关注【极客学院】——获取更多内容
在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成，再集成到一起进行测试。
随着软件技术的发展，各种软件百花齐放，软件规模也在扩大，软件需求越来越复杂了。
软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式的弊端也越来越明显：
-
由于很多 bug 在项目的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找 bug 的根源。
-
软件具有复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况，在这个阶段的除虫会议特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。
因此，为了快速发现错误、解决问题、降低后期集成难度、节省人力，团队越来越倾向于持续集成的开发模式。但只有整个团队真正按照持续集成的纪律工作，这支团队才真正算是“拥有”持续集成。
那么今日极限拷问来了：
1、你认为，持续集成有哪些纪律？
2、你的团队遵守这些纪律的情况怎么样？
在日常工作中，持续集成的基础规则主要有以下几点：
-
不能积压代码，小步提交，频繁提交、频繁合并代码；
-
当CI构建或者部署失败时，立刻修复，若不能解决，即立刻回滚；
-
要有责任意识，谁编写，谁负责；
-
需要有单元测试，且代码需要通过自测和静态工具的分析。
当然，稍高阶的规则，还囊括了：
-
所有代码都包含在持续集成中，包括部署脚本、测试脚本；
-
若每个服务都有自己的 CI pipeline，当 CI 构建失败时，其他人可以随时提交新的代码。反之，则需要所有人停止提交代码直至修复完成；
-
更新设计思维，持续集成模式下对软件架构及设计有新的要求需要不断优化软件架构。
对于以上规则，群内成员的遵守情况怎样呢？
据群员反应，大部分群成员以及自身团队都能做到频繁提交与责任意识，对自己的代码直接负责，但在解决问题方面，所用的修复周期较长。
在单元测试上，存在只是为了达成覆盖率而作单元测试的现象，且对单元测试的要求是只要能通过就好，碰到紧急的任务也会破坏单元测试，导致项目的单元测试状态是红色，事后再补充进去。
可见虽然规则虽十分明确，但由于种种因素，团队在工作时都会灵活遵守纪律与规则，使得工作更加高效。
持续集成的好处是十分显而易见的：
-
快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易；
-
防止分支大幅偏离主干，如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成；
-
更快速的发布更新，持续集成可以帮助团队更快速、更积极的发布程序和更新程序。在发布时可自动完成大量重复的工作、节省人力。
既然好处这么多，那好用的 CI 工具有没有推荐呢？这里可以关注一下 gitlab，它是一个 DevOps 平台，runner 配置很灵活强大，且它支持上下游 pipeline。发展到现在，gitlab 已经是repository 、issue tracker 、kanban 、docker registry 的集合体了。
我们还发现了持续集成带来的影响：出现个人只负责个人模块的问题。
▲【极限编程中国 | 实践者】成员发言
因为持续集成每个人负责的部分都被明确划分 ，出现问题需要修复时，除了当事人，团队中的其他人一般都不会替他修复。
其实这从根本上来讲是制度导致的问题。直接和绩效挂钩，考核的是个人的工作。因此，解决此类问题的方法无非便是更改制度，或自身注重代码质量，重视测试了。
本期内容整合自【极限编程中国 | 实践者】
内容贡献者：
如果你也想加入讨论，迅速成长
欢迎加入我们
立即扫描下方二维码限时免费加入【极限编程中国 | 实践者】微信群
和前ThoughtWorks总监咨询师熊节实践敏捷开发
