Google软件工程工具之大规模变更

一次提交可以可靠地变更多少个文件?制约这个数字的因素是什么?有没有试过提交一个很大的变更?紧急情况下能在合理的时间内完成吗?最大的提交规模与代码库的实际规模相比如何?如何测试这种变更?有多少人需要在提交变更之前对其进行评审?如果真的提交了，能回退吗?

随着代码库和工程师数量的增加，最大的原子变更可能反而会减少，运行所受影响的预提交检查和测试变得困难，更不用说确保变更中的每个文件提交前都是最新的。

一些技术，包括社交性和技术性的，使我们能够保持大型代码库的灵活性和对底层基础设施变化的响应能力。这些原则能帮助开发组织规模的扩大，同时还能对代码库进行大规模的变更。

大规模变更是逻辑上相关但实际上不能作为单个原子单元提交的任何一组变更。这可能是因为它涉及太多的文件，以至于底层工具无法一次提交所有文件，也可可能呢是因为变更太大，总是会有合并冲突。在许多情况下，大规模变更是由你的代码存储库拓扑决定的。

大规模变更的基本类别:使用全代码库分析工具清理常见的反模式，替换已废弃的库功能，支持底层基础设施改进如编译器升级，将用户从旧系统迁移到新系统。

构建和管理系统的基础设施团队负责执行大规模变更的大部分工作。构建和管理底层系统的基础设施团队具备修复数十万个引用所需的领域知识。另外没人喜欢无资金支持的强制要求。负责团队有助于对齐目标和动机，以确保变更的完成。

讨论一下为什么许多类型的变更不能以原子方式提交。首先是技术限制，你的系统可能没有足够的内存或处理能力来处理一次以原子方式提交的数千个文件。其次是合并冲突，随着变更规模的增加，合并冲突的可能性也会增加。第三，闹鬼墓地是指一个非常古老、迟钝或复杂的系统，以至于没有人敢进去。第四是异构性，只有当大部分工作都可以由计算机而不是人完成时，大规模变更才能真正发挥作用。第五是测试，变更越大，依赖传递项越多，测试越困难。第六是代码评审，评审大型提交是乏味的、繁重的、容易出错的，特别是如果变更是手动生成的。

大规模变更的基础设施包括:一、政策和文化，例如单一代码仓库。二、代码库分析，例如语义索引工具。三、变更管理工具，将主变更分解成更小的部分，并独立地管理测试、邮件发送、评审和提交。四、测试，确认软件按照预期运行。五、语言支持，一些语言比另一些语言更容易支持。

大规模变更流程:一、授权，变更被委员会审批。二、变更创建，作者生成代码。三、切片和提交，将大变更分解成可以原子提交的变更。四、清理，防止倒退。