自动化测试优先于持续集成

然而，基于主干的开发方式需要创建更有效的自动化测试。Gary Gruver 说：“如果没有自动化测试，持续集成只能产生一大堆没有经过编译而且不能正确运行的垃圾。”在刚开始时，完整

地执行一套手动测试需要6周的时间。

Ward Cunningham 开发了世界上第一个维基系统，也创造了“技术债务”一词。他在描述技术债务时说，如果不能主动地重构代码库，它就会慢慢地变得难以修改和维护，新特性的增加速度也会因此而下降。

技术债务只能通过重构来解决的话，成本十分高昂，频繁的重构本身也不现实。

在第一版产品设计、实现、改进的过程中，将所有的特性需求都记录下来，重构时可以作为参考。对于每一条特性都需要思考 ：

*新的版本是否仍然需要满足该特性？

*新的版本是否已经从根本上提供该特性（老版本可能是通过加一层来解决的）？

*该特性是否是时效型需求，当前已经不再需要？

*该特性是否有重大价值，是否可以放弃？

持续集成案例

搞了半天的结果是每周发布一次。中国很多企业靠堆人工也能做到每周发布一次。所以持续集成有吸引力吗？这种案例拿出来没法说服领导给钱。

基于主干的开发方式可能是本书中最具争议的实践。许多工程师都认为它行不通，他们更喜欢在自己的分支上工作，不必与其他开发人员协作 然而， Puppet Labs 的《 2015年DevOps 现状报告》表明，基于主干的开发方式能带来更高的生产力、更好的稳定性 ，甚至更高的工作满意度和更低的职业倦怠率。

虽然在开始时很难说服开发人员，但是 旦他们认识到显著的优势，就会彻底改变，

中国的开发人员倒是非常喜欢在主干开发，无需说服。

自动化部署流程

将代码打包成便于部署的格式;

创建预配置的虚拟机镜像或容器；

将中间件的部署和配置自动化；

将安装包或者文件复制到生产服务器；

重启服务器、应用或者服务；

基于模板生成配置文件；

通过执行自动化冒烟测试，确保系统能正常运行，并且配置正确；

运行各种测试程序；

将数据库迁移工作脚本化和自动化。

数据库迁移工作是指为了搭建新环境而迁移数据库，还是数据库版本更新？私下揣测应该是指后者。

如果是数据库版本更新，那么数据库脚本化和自动化有若干问题：

1、脚本的环境差异。由于数据库内的数据在各环境有差异，导致的脚本语句也需要有差异，并非每次都有，但可能存在，需要和配置文件一样，做环境差异管理。而配置文件通过模板生成，数据库脚本却不可以，需要以其他方案实现；

2、容错和预检查。脚本需要预先检查问题，而且还要考虑出错时的处理机制。数据库许多操作一旦执行，无法逆向回退或者难以回退，出错时的处理机制需要提前考虑。

3、备份与回退。大型数据库备份时间和资源成本都很高，部署频繁的时候，每次都备份和回退不现实，可以考虑加设开关，在预审版本时，考虑是否打开开关。

应用自动化的自助式部署

为了更好地促进工作，需要一个可以由开发人员或运维人员来执行的代码发布流程，并且在理想情况下，应该不需要任何手动操作或工作交接。这个流程的步骤如下

    构建： 部署流水线必须基于版本控制系统构建可部署到任何环境（ 包括生产环境）的软件包。

    测试：任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化测试套件。

    部署：任何人都应该能够将这些软件包部署到具有访问权限的任何环境，通过执行（已提交到版本控制系统中的）脚本来完成部署。

以上实践有助于成功地执行部署，谁来执行并不重要。