sre8 发布工程
发布工程还是一个比较新的学科，在大厂通常会有专门的同事负责软件版本的发布。
简单来说，这个学科专注于构建和交付软件。发布工程师通常对源代码管理、编译器、构建配置语言、自动化构建工具、包管理器和安装器等非常了解（甚至是这方面的专家）。他们的技能横跨很多领域：开发、配置管理、测试集成、系统管理，甚至用户支持
为保障服务可靠运行需要可靠的发布流程。SRE需要保证二进制文件和配置文件是以一种可重现的、自动化的方式构建出来的。这样每一次发布才是可以重复的
发布工程哲学
自服务模型
每个团队必须能够自给自足。发布工程师只开发工具，制定最佳实践，以便让产品研发团队可以自己掌控和执行自己的发布流程。
不会所有的项目发布都要找发布工程师。
发布过程可以自动化到基本不需要工程师干预
追求速度
面向用户的软件组件重新构建非常频繁，因为我们的目标是让用户可见的功能越快上线越好。我们同时也认为频繁的发布可以使得每个版本之间的变更减少。这种方式使得测试和调试变得更简单
密闭性
构建过程使用指定版本的构建工具（编译器），同时使用指定版本的依赖库（第三方类库）。编译过程是自包含的，不依赖于编译环境之外的其他服务。
这是为了保障在任何情况下构建出的软件包是一样的
强调策略和流程
确保在发布过程中只有指定的人才能执行指定的操作。
几乎所有对源代码的修改都需要进行代码评审，这与我们日常开发工作流程是完美结合的。
持续构建与部署
分支管理
所有的代码都默认提交到主分支上（mainline）。然而，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug修复先提交到主分支，再cherry picking到发布分支上。这种方式可以避免在第一次构建之后，再引入主分支上的其他的无关改动。利用这种分支与cherry picking的方法，可以明确每个发布版本中包含的全部改动。
持续测试
在每个主分支改动提交之后运行单元测试。
使用最后一个测试全部通过的软件版本来进行最新的发布。
部署
我们的目标是让部署流程与服务的风险承受能力相结合。在开发环境或者预生产环境中，我们可能会每小时构建一次，同时在所有测试通过之后自动发布更新。对于大型面向用户的服务来说，我们可能会先更新一个集群，再以指数速度更新其他集群直到全部完成。对敏感的基础设施服务来说，我们可能会将发布扩展到几天内完成，根据这些实例所在的地理位置交替进行。
发布工程经常是“事后诸葛亮”，随着平台和服务的规模与复杂度不断增加，这种理念一定需要改变。
团队应该在开发流程开始时就留出一定资源进行发布工程工作。尽早采用最佳实践和最佳流程可以降低成本，以免未来重新改动这些系统。