发布

对于大型生产环境和复杂的业务系统来说，发布应用或者变更并不是简单的在服务器上运行二进制包或者脚本就可以了，这样很不便于服务的管理，且服务的稳定性也无法保障，所以就会有发布工程这一说法。

发布工程要素

对于每个研发团队来说，都需要有一个相对应的发布工程师，发布工程师指定发布策略，编写发布工具，指定发布流程。

当发布频繁时，每个版本之间的变更将减少。这样能减小新版本上线侯的测试和调试成本。对于项目可以高频次构建，然后在多次构建中选择一个构建版本进行发布（条件：需要是所有测试都通过的版本）。

每一次构建的产物，都不能因为构建环境差异导致构建差异。所有依赖在构建过程要自包含。

当构建在生产环境中出现bug时，按照之前的源码版本，加入新的改动之后生成新的构建（即向repo推送fix的commit）。构建的编译环境会被包含到repo中（显然有些不可能，所以最佳做法应该时在repo中保存编译器版本等环境信息），这样能保证每次构建环境都是相同的。

对于变更发布，一般需要遵循一下流程：

构建目标应该被定义在配置文件中，如常用的configure文件。可以指定构建的参数及属性。

常用的分支管理与google有一些出入。项目变更通常会推送到开发分支，开发分支变更经review和审计之后被合并到发布分支上进行发布，由此可以清楚看出每次合并的变更信息。

开发分支提交变更后即执行单元测试。以分支的构建结果和测试结果作为指定发布版本的依据。通常可以使用最后一次成功构建和测试通过的版本进行发布。

发布过程中要进行全部的单元测试，防止开发分支不包含某些发布分支的代码出现未测到的问题。同样要保证最后一次测试通过。

对构建成果进行打包，可以使用构建得出的hash和构建标签进行打标签，加入签名以保证打包的完整性（可以使用MD5）。

一个发布时的组成时一个或者多个任务组成的逻辑工作单元（可以理解为微服务）。自动发布系统可以用构建时的build tag进行自动化部署（指定发布版本）。对于大型项目部署速度通常时指数型的，即灰度发布。

项目配置需要为一致的，所以可以将配置文件存放到项目的repo中，同样进行代码审计。在打包时可以将配置文件一起进行打包，降低部署的难度，但是同样会带来一些问题，比如配置的灵活性下降。可以将配置文件存放于外部存储上，每次发布从外部存储上读取配置文件，从而提高配置的灵活度。