我常常听到一些开发人员抱怨说，他们要忙于修改那么多文件，哪有精力每天签入代码。实际上，这正是我要说的要点 — 为了每天提交源代码修改，需要将任务划分得更小。实际上，需要将编程任务划分成小块，这样修改也会更小。
不要在一个大任务中实现一个业务对象上的所有特性，例如编写 read()、write()、update() 和 delete() 方法的原型；而是应该首先编写 read() 方法（以及对应的测试），然后签入这个类，从而与整个代码基集成。接下来，可以实现另一个方法，再次执行签入，直到完成整个任务。这样的话，就可以让 CI 的好处最大化，而且会让您确信自己的代码可以与别人的代码 相互配合。
请记住，即使您和您的团队正确地执行许多 CI 实践，如果团队成员不坚持至少每天签入一次源代码修改，那么 CI 的好处会大打折扣。这常常会让人误以为 CI 是无效的，这种想法实在大错特错。
破碎的构建减慢了开发的节奏
名称：破碎的构建
反模式：构建长时间破碎，导致开发人员无法签出可运行的代码。
解决方案：在构建破碎时立即通知开发人员，并以最高优先级尽快修复破碎的构建。
无论您信不信，构建破碎的时间越长，就越麻烦。这是因为文件、修改和依赖项越多，隔离缺陷就越困难。因此，当通知某人构建破碎时（通过电子邮件、RSS 或其他机制），他应该优先解决这个问题；否则，构建破碎的时间越长（尤其是对于频繁修改代码的团队），就越难纠正。
破碎的构建不总是坏事。实际上，破碎的构建会让您迅速地意识到软件出了问题。当构建频繁地 破碎或长时间破碎时，破碎的构建就会成为问题。在构建破碎的情况下，绝不应该置之不理。
用私有构建减少破碎的构建
防止破碎构建的有效技术之一是，在将代码提交到存储库之前，运行私有构建（private build）。执行私有构建的步骤如下：
从存储库签出代码。
在本地修改代码。
用存储库执行更新，从而集成其他开发人员所做的修改。
运行本地构建。
构建成功之后，将修改提交到存储库。
图 1 说明了这种做法。注意，这个工作流强调频繁地与存储库执行同步，从而保证定期签入并限制破碎的构建 — 这真是一举两得！
图 1. 运行私有构建减少破碎的集成构建
文章来源于领测软件测试网 https://www.ltesting.net/
