小结

虽然本章讨论的是Google的发布工程的特有方法，以及发布工程师与SRE共同合作的区域，但其实这些实践适用于更广阔的范围。

不仅仅只对Google有用

当采用合适的工具、合理的自动化方式，以及合理的政策时，开发团队和SRE都无须担心如何发布软件。发布过程可以像按一个按钮那么简单。

大部分公司，不论团队大小和使用何种工具，都面临着同样的发布工程问题：如何管理包的版本？应该采用持续构建和部署的模型，还是应该定期构建？发布的频率应该怎样？应该使用什么策略管理配置文件？哪些发布过程的指标比较有用？

Google 发布工程师开发自己工具的原因是因为第三方供应商提供的工具无法适应我们的海量规模。自定义过程使得我们可以在工具中加入对发布流程政策的支持（甚至是对这些政策的强制执行）。然而，这些政策必须先被正确定义，这样才能指导工具功能的创造。不管最终的政策是否需要自动化，或者是否需要强制执行，任何组织都应该先花一些时间定义自己的发布政策。

一开始就进行发布工程

发布工程经常是“事后诸葛亮”，随着平台和服务的规模与复杂度不断增加，这种理念一定需要改变。

团队应该在开发流程开始时就留出一定资源进行发布工程工作。尽早采用最佳实践和最佳流程可以降低成本，以免未来重新改动这些系统。

开发团队、SRE和发布工程师的紧密协作是很重要的。发布工程师需要明白代码开发时对构建与部署的预期。开发团队不应该只是编写代码，然后“将结果扔过墙”，两个团队必须互相了解。

每个具体的项目团队需要决定何时进行发布工程。因为发布工程是一个相对来说较新的学科，管理层不一定会在项目早期为此进行计划和提供资源。因此，当应用发布工程最佳实践时，一定要考虑到它在整个产品生命周期中的地位，尤其是在项目早期。

更多信息

关于其他发布工程的信息，请参考以下演讲，每个都有对应的视频。

● How Embracing Continuous Release Reduced Change Complexity（http://usenix.org/conference/ures14west/summit-program/presentation/dickson）,USENIX Release Engineering Summit West 2014,[Dic14]

● Maintaining Consistency in a Massively Parallel Environment（https://www.usenix.org/conference/ucms13/summit-program/presentation/mcnutt）,USENIX Configuration Management Summit 2013,[McN13]

● The 10 Commandments of Release Engineering（https://www.youtube.com/watch? v=RNMjYV_UsQ8）,2nd International Workshop on Release Engineering 2014,[McN14b]

● Distributing Software in a Massively Parallel Environment（https://www.usenix.org/conference/lisa14/conference-program/presentation/mcnutt）,LISA 2014,[McN14c]