乔梁，十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力，推广最佳实践。曾为多个大型电信企业、互联网企业提供专业的软件交付咨询服务。现任百度项目管理部高级架构师，负责百度敏捷过程改进与持续交付推广实施。译有《持续交付》。曾任Thoughtworks资深咨询师，对敏捷项目管理及持续集成有深入的理解与丰富的实践经验。
下面是整理出来的乔梁分享的“持续集成”系列文章：
每当开发人员提交代码时，就是其与其他开发人员工作成果的一次集成。如果每个人都能够频繁提交代码，那么代码集成的频率就会提高，在持续集成的有力支持下，代码中潜在的问题就会更早地暴露出来，以便团队尽早解决之。当然，持续集成所鼓励的频繁提交并不是指那种仅将版本控制库当成备份工具，无约束的“随意”提交，还需要团队开发流程约束的。下面我们来一同探讨“持续集成环境中的团队开发流程是什么样的”。
随着软件产品新特性的不断增加，软件自动化测试用例的数量也会成倍增长。对于一些历史“悠久”的遗留系统来说，甚至会积累数以万计的自动化测试用例。如果对这样的系统进行持续集成，还要求每个开发人员都要进行本地验证的话，困难的确不小。让我们还是看看Joe的团队是如何解决类似问题的吧。
现代版本控制系统(SCM)的作用已不仅仅是保存历史版本，它还是各软件开发组织利用其分支功能实现多人并行开发，提高生产效率的一种工具。对于稍有历史的软件产品来说，一般都会有代码分支的出现，也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入“无尽维护”的泥潭。分支的目的是希望“分而治之”，而持续集成的目的是“频繁集成”，这二者之间又有哪些联系呢？
现在，Joe的团队中，开发人员快速增加，已接近30人了。由于首次发布后的市场压力，大家一直在赶进度，持续集成的失败频率越来越高，修复构建的时间也越来越长，排队等待提交的代码也越积越多。“这种状况不能再持续下去了，需要想个办法解决它。”
在前文《分支策略(续)》中，我们讨论了多组件应用程序的持续集成策略，即：为相对独立的组件创建自己专属的代码库，然后通过现代持续集成工具进行组件间的持续集成。Joe的团队在首次发布之后，开始使用这种方式。然而，没有多久，他们就遇到了一个问题：一次提交构建所花费的时间太长。
将部署操作脚本化，并进行部署验证测试；各类环境尽可能相似，并使部署脚本通用化；对环境管理进行版本控制，杜绝对生产环境的手工直接修改。
你是否遇到过这样的情形，即使手里拿着一个jar文件或dll文件，也无法知道它到底是哪个版本。也许你可能认为，这算不了什么，到某个管理平台上查一查部署记录就行了。可是，如果发现在生产环境的集群服务器上，不同机器上部署的同一个程序文件（比如.war文件）的大小却不相同，哪一个的大小是正确的呢？
随着互联网的飞速发展，以及基础设施的改进，越来越多的业务被放在了“云”端。管理数千台服务器和各种应用程序的不同版本已经是一种常规事务了。那么如果管理好这些机器和代码吗？本文将介绍一些最佳实践，来帮助大家更好的完成相关的事务。
