CI/CD关键点
错误的累计性
错误越多，删除每个错误就越困难。部分原因是我们遇到了交错的错误，其中故障表现实际是多个故障叠加的结果，这使得更难找到每个故障。 这也是心理上的影响，当错误很多时，人们就没有精力去寻找和消除错误。
快速反馈
频繁部署很有价值，因为它使我们的用户能够更快地获得新功能，更快地对这些功能提供反馈，并且在开发周期中通常会变得更加协作。 这有助于打破客户和开发之间的障碍，这些障碍是成功软件开发的最大障碍。
立即修复
有些团队倾向于使用预测试、门禁提交来消除破坏主线的所有风险。以便推送到主线进行集成的提交不会立即进入主线。 它们可能会被放置在另一个分支上，直到构建完成，并且只有在绿色构建后才会迁移到主线。 虽然这种技术可以避免破坏主线的任何危险，但高效的团队应该很少看到红色主线，而且在少数情况下，它的可见性会鼓励人们学习如何避免它。
XaC
X是指的所有要素，也包含质量要素。流水线会检查所有合并到主线分支的提交内容经过代码检视，未经检视的提交内容禁止发布部署。
业内实践
AWS
流水线能力灵活能力强，可以通过pipeline action进行水平扩展，原子工具的手动执行和api能力配套，可以通过流水线进行关联和集成触发执行，但规范性偏弱，每个服务需要对本服务的SLA负责。
Pipeline聚焦于顶层的编排调度，Apollo负责服务部署，SWF聚焦于底层的复杂场景的分批运维操作。
所有写操作都需要可审计，不可审计的变更工具无法上线，所有写操作都需要关联变更单或者事件单，确保可审计及可追溯，读操作没有进行风险控制。
有些写的运维操作也会通过堡垒机进行执行，会对运维操作风险进行评估，高风险需要两人进行操作，低风险就一人进行操作。
参考文档
- 持续集成
- 自动实现无需干预的安全部署
- 采用持续交付，加速交付进度
- ThoughtWorks：持续交付洞察
- ThoughtWorks：持续交付架构
- ThoughtWorks：CD和行政部门
- ThoughtWorks：CI/CD 基础设施即服务
- AWS：通过CodePipeline控制OpsWorks
- AWS：通过CodePipeline创建自定义Job
- AWS：监控CodePipeline事件
- AWS：使用 AWS Systems Manager 进行软件修补
- AWS：使用 AWS CodePipeline 和自定义操作构建 Windows 容器
- AWS：SystemManager执行可以审批的自动化
- AWS：Systems Manager自动执行任务
- AWS：Simple Work Flow(SWF)简单工作流
- AWS：SWF常见问题
- AWS：自动化分析工作流
- AWS：re:Invent 2016: DevOps on AWS: Accelerating Software Delivery with AWS Developer Tools (DEV201)
