只有在确定代码没有质量问题后，才会将其提交到主干进行合并，一旦代码合并，就进入了提交阶段。
在提交阶段，开发人员将代码合并到主干后会触发的相关活动，包括代码合并、服务器端编译构建、服务器端单元测试、静态代码扫描和动态覆盖率分析等。
提交阶段执行时长不超过 10分钟
提交阶段的活动完成并生成二进制包后，进入自动化验收阶段，此阶段包含自动部署、冒烟测试以及自动化测试等活动
与测试相关的持续集成实践
- 提交前在本地运行所有的提交测试
- 提交测试通过后再继续工作：保持部署流水线常绿是持续集成的基础
- 不要轻易将测试失败的用例注释掉
- 若测试运行变慢，则让构建失败
- 若存在编译警告或代码风格问题，则让测试失败
基于Jenkins和Docker的微服务持续集成案例
运行Jenkins最理想方式是使用独立的服务器
略
8.2 持续部署(Continuous Deployment，CD)
持续部署实践
持续部署是一种软件工程方法，通过自动化部署频繁地交付软件功能
- 自动化部署
- 各环境的部署脚本尽量一致
- 把部署流程集成在 CI/CD 中
基于环境的部署
- 蓝绿部署
- 金丝雀发布
基于应用的部署
- 特性开关
- 暗启动
8.3 持续反馈
1.A/B 测试
AB测试(A/B Testing)最早的应用应该是在2000年，Google 工程师用来测试搜索结果页面上每页应显示多少条搜索记录。
- 做测试时不局限于2个方案：可以是多个
- 不能使用新版本和上个时间段的老版本进行比较
- A/B 测试只能有1个变量
- 避免使用用户标识奇偶法分组
混沌工程
21世纪初，亚马逊的“灾难大师”(Disaster Master)杰西·罗宾斯(Jesse Robbins)以自身的消防员培训经历为灵感创建了一个名为“游戏日”(GameDay)的练习项目,旨在测试、培训和应对亚马逊可能发生的系统灾难。
Netflix从200年8月开始就将自己的数据转移到AWS云服务上,原因是当时一个主要的数据库出现崩溃，影响了3天的DVD发货。Netflix将Chaos Monkey(捣乱猴子)部署在AWS云服务上。
混沌工程的实施步骤
(1)稳定状态
(2)假设。一旦确定系统处于稳定状态，接下来就可以开始进行故障假设，例如:
- 如果这个推荐引擎停止运行了呢?
- 如果这个负载均衡器坏了怎么办?
- 如果缓存失败了怎么办?
- 如果延迟增加了300ms会如何?
- 如果主数据库停止运行了怎么办?
请牢记一点，不要进行已知会让系统失败的假设!只对系统中你认为有弹性的部分进行假设，这才是实验的重点。
（3）设计运行试验
- 有多少客户会受到影响?
- 哪些功能受损?
- 哪些地点受到影响?
(4)学习和验证。
包括:
- 检测时间
- 通知时间
- 升级时间
- 发布时间。
- 优雅降级时间
- 自我修复时间
- 恢复时间(部分和全部)
- 解除警报并恢复稳定时间
错误纠正(Correction-of-Eeeor)文档，简称 COE 文档。
COE 文档组成
- 发生了什么事(时间轴)?
- 对我们的客户有什么影响?
- 为什么会出现错误(5个Why原则)?
- 你学到了什么?
- 你将如何防止它在未来再次发生?
(5)改进和修正。
混沌工程的价值
(1)混沌工程能够帮助发现系统中的未知因素，并且能让我们在正常工作时间对其进行修复，避免牺牲休息时间。
(2)一个成功的混沌工程实践总会产生比预期多得多的变化,在这些变化中最重要的免责文化从“你为什么那样做”自然演变成“我们如何避免在未来这样做”，这会让团队快乐、更高效，也是其黄金价值所在。
