Google 发布工程专注于构建管道和交付软件、CI/CD，需要保障服务可靠运行的发布流程，由产品研发部门工程师和SRE一起定义发布过程。
一、发布工程的四个原则
1、自服务模型：团队自给自足选择发布版本，实现规模团队的高效发布，发布过程有构建系统和部署工具；
2、追求速度：构建频繁，每小时一次。让用户可见的功能越快上线越好，版本间的变更减少，测试变得简单。采用测试通过即发布（push on green）；
3、强调策略和流程：多层安全和访问机制，几乎对源代码100%评审，自动化记录改动的报告；
4、密闭性 Hermetic：构建工具确保一致性、可重复性，构建过程是密闭的（hermetic），修复生产bug，采用摘樱桃方式（cherry picking），确保编译器版本与之前一致；
二、持续构建与部署
1、代码 piper
• 主分支全量代码；
• Bug修复后也提交主分支，摘樱桃方式创建发布分支；
2、构建 Blaze
• Blaze编译工具，自动编译依赖关系
3、测试
• 持续测试，每次分支改动都触发测试
• 发布过程有发布分支，有全量测试，有审核记录
• 独立的测试环境
4、打包MPM
• MPM系统将软件分发到生产，确保可靠性和唯一标识 ；
• 利用标签标记发布过程中的位置，（如canary还是production）；
5、Rapid系统
• 定义构建和测试目标，访问权限控制，工作流、日志、管理发布分支和cherry picking；
• Rapid配置文件，关联二进制文件与构建的过程；
6、部署 sisyphus
• 由Rapid驱动的部署流程，通过sisyphus发布自动化框架执行部署任务（多任务），有监控台；
• 目标是让部署流程与服务的风险能力相结合；
• 内部环境每小时构建一次，生产按集群发布；
三、配置管理
• 由发布工程师和SRE合作完成；
• 配置变更的发布管理系统都有所发展，有很多模型；
四、小结
• 简单化：采用合适的工具，合理的自动化方式，让发布过程像“开关按钮”那么简单 ；
• 自建/采购：第三方工具无法适应google的海量规模，过程中加入对发布规则的要求 ；
• 发布工程需要想清楚的几个关键问题：
1、如何管理包的版本？
2、应该采用持续构建或部署模型，还是定期构建？
3、发布频率？
4、配置文件管理策略？
5、发布过程的指标哪些有用？
自服务
模型
