DevOps 文字培训
为什么要建立持续评审流程来保障质量？
你的组织在生产部署前非常依赖评审、审计、检查和审批。开展这些检查的人通常与工作关联很少，有时甚至完全没有参与。最糟的是，检查和审批人员有时会误解你的工作，于是你只得在准备将代码部署到生产环境时，临时向他们解释。
外部控制机制存在的问题
在大多数组织中，建立控制机制比建立相互信任容易。因此，在变更控制表中不断增加问题、在组织层级中增加审批环节，以及要求额外时间来理解和批准变更，都是外部控制机制常见的问题。
命令与控制文化下，信任程度较低的环境注定要面对大量反复发生的事件。由于实际工作和反复出现的问题都不透明，而且为尽量减少难以应付的部署次数，工作以大批次完成，这类组织会陷入恶性循环。交付前置时间越长，快速上市的竞争力就越弱。团队获得的反馈缓慢、滞后且无法采取行动，因此不能从错误中学习。
像你所在组织这样有能力的 DevOps 组织明白，最接近实际工作及相关问题的人，对它们最了解。因此，额外的外部控制和审批机制不会给价值流增加价值。这正是当今最大的管理和领导挑战：如何建立高度信任的文化，让工作透明，并让真诚的尊重和互信成为日常工作不可或缺的一部分。
减少对定期检查的依赖，把同行评审纳入日常工作。让 DevOps 团队中的开发人员、运维工程师、质量保证和信息安全专家持续协作并评审彼此的工作，使部署能够安全进行。
在没有外部控制机制时协调复杂工作
只有一支团队做项目时，工作就已经很复杂。多支团队分别负责同一个系统的不同组件时，工作可能更复杂。以下是一些帮助你和 DevOps 团队掌控局面的措施：
- 由领域专家而非仅由管理人员组成的变更委员会，可帮助你在变更发生前识别各团队的依赖关系。
- 基于 SOA 和微服务的松耦合架构可以减少依赖关系和沟通成本。
- DevOps 团队的技术代表应确定依赖关系及开发和部署顺序。
- 通过共用的聊天平台保持沟通，以同步变更、了解和检查他人的理解。
- 对于影响更大、风险更高的变更（如迁移或基础设施变更），需要在测试环境中演练，并采用故障转移和完整回滚机制等技术应对措施。
高绩效 DevOps 组织更依赖同行评审，较少依赖外部审批
Amazon、Netflix、Etsy 和 GitHub 等许多领先的 DevOps 组织，都采用“Pull Request”评审与部署流程。具体做法如下：
- 开发人员从主干创建独立的开发分支。该分支的存在时间不应超过几个工作日，并应有明确、能说明用途的名称，例如“login-screen-v2”。开发人员在自己的工作站上处理本地分支，并定期将该分支提交到版本控制系统。
- 开发人员认为开发分支已可以合并到主干时，会发起一个拉取请求，征求评审反馈。
- 开发人员收到 DevOps 团队其他成员的评审反馈和批准后，将代码合并到主干，然后将其部署到生产系统。
对于数据库模式等影响重大的变更，或可能影响应用信息安全的变更，开发人员还可以另外发送拉取请求，向组织中的其他领域专家（如数据库管理员或信息安全专家）征求反馈。
在评审代码时，同样应遵循小批量原则。否则，评审会耗时更久，给评审工程师带来很大负担。变更规模越大，风险就会呈指数级增加，评审也会变得不那么可靠。如果变更太大、难以理解，可以要求开发人员把变更拆成多个更小、更易理解的部分。
DevOps 团队的每个人，无论资历或经验如何，都必须让他人评审自己的变更。每个人都应关注持续提交的代码，以便在潜在冲突给部署流水线带来更大的问题，甚至影响生产部署之前，迅速发现并解决冲突。
单独使用结对编程，或将结对编程与测试驱动开发（TDD）结合（由一位开发人员编写应用代码，另一位编写自动化测试），都能让 DevOps 团队在编写代码时同步开展同行评审。在团队规模与项目需求相同的情况下，测量结果证明，结对编程多花 15% 的时间，却能减少 85% 的编码错误。因此，你和 DevOps 团队应评估是否采用这项重要实践。
此外，还可考虑实施面对面代码评审、提交动态的自动通知，以及使用帮助评审代码和提升代码质量的工具。
总结
让组织中的每支 DevOps 团队都对自己的交付成果质量负责。建立一种文化，对持续进行的高质量代码评审和编写高质量代码给予同等重视。
