Microsoft 如何使用 DevOps 交付软件

Microsoft 在向生产环境交付高度可缩放服务方面拥有数十年经验。 随着 Microsoft 服务和环境的扩展，其交付实践也在随着时间的推移而演变。 很多 Microsoft 客户也采用并受益于这些高效的交付做法。 以下核心 DevOps 原则和流程适用于所有现代软件交付工作。

为实施 DevOps 交付流程，Microsoft 采用以下计划：

• 专注于组织思维模式和交付节奏。
• 形成自主、负责的团队，而这些团队会负责、测试和交付功能。
• 右移到在生产环境中测试和监视系统。

专注于交付

更快交付是组织和团队可轻松度量和享受的明显好处。 典型的 DevOps 节奏涉及较短的冲刺周期，同时会定期部署到生产环境。

由于担心短冲刺缺乏产品稳定性，某些团队在冲刺周期结束时会用稳定期加以补偿。 工程师们希望在冲刺期间提供尽可能多的功能，因此他们在稳定期间不得不偿还之前的测试债务。 在冲刺期间管理债务的团队此时则须为积累债务的团队提供支持。 额外成本会通过交付管道以及进入生产环境后显现。

消除稳定期可迅速改善团队管理债务的方式。 积累债务的团队不得不在下一冲刺中赶上债务目标，而不是将关键维护工作推迟到稳定期。 团队在冲刺期间可迅速学会如何管理其测试债务。 功能会在经过验证且值得付出部署成本的情况下交付。

完全自动执行管道

团队可立即实现的大部分改进源自以下措施：从代码存储库到生产环节，完全自动执行管道。 自动化包括具备持续集成 (CI)、自动化测试和持续交付 (CD) 的发布管道。

团队可能会避免部署，因为它十分困难。但部署频率越低，就越难部署。 部署之间的间隔时间越长，累积的问题就越多。 如果代码并非最新，则存在部署债务。

通过频繁部署，可更轻松地在较小的区块中工作。 此想法在事后看起来可能显而易见，但当时看它却可能恰恰相反。 频繁的部署还可激励团队优先创建更高效、可靠的部署工具和管道。

使用内部工具

Microsoft 使用自己构建的发布管理系统，并将其交付给客户。 单个投资可同时提高团队工作效率和 Microsoft 产品。 使用辅助系统可加快开发和交付速度。

团队自主性和问责

没有特定的关键进度指标 (KPI) 可度量团队的工作效率或绩效，或是某个功能是否处于正轨。团队需具备管理自身计划和积压工作的能力，同时找到一种方法来确保不偏离组织目标。

与团队直接沟通以跟踪进度十分重要。 工具应促进沟通，但对话却是最透明的沟通方式。

确定功能的优先级

其中一个重要目标是专注于交付功能。 计划可评估给定时间段内团队和个人可以合理完成多少工作，但某些功能会提前交付，有些则会延后。 团队可确定工作的优先级，以便将最重要的功能发布到生产环境。

使用微服务

微服务提供了各种技术优势，它们可改进和简化交付。 微服务还提供团队所有权的自然边界。 当团队对微服务的投资具有自主性时，他们可确定如何实现功能和管理债务的优先级。 团队可专注于计划的版本控制等因素，而不考虑依赖于微服务的整体服务。

在主分支中工作

工程师过去常在单独的分支中工作。 每个分支上的合并债务会增长，直到工程师试图将其分支集成到主分支。 团队和工程师越多，集成的规模就越大。

为了更快、更连续地进行集成，工程师如今会在主分支中工作。 迁移到 Git 的一个重要原因是 Git 提供的轻型分支功能。 内部工程的好处在于能消除深层分支层次结构及其浪费。 用于集成的所有时间现在都可投入到交付中。

使用功能标志

对于冲刺部署，某些功能尚未完全完成，但仍可从生产环节的测试中受益。 团队可通过功能标志来合并和部署此代码，以便为特定用户启用该功能，例如开发团队或一小部分早期采用者。 功能标志可控制暴露，而不会给整体用户群带来风险，并且可帮助团队确定是否以及如何完成该功能。

在生产中测试

在生产环节右移到测试有助于确保预生产测试的有效性，且不断变化的生产环境已准备好处理部署。

检测测试和指标

无论应用在何处部署，检测所有内容都很重要。 检测不仅有助于识别和修复问题，还可提供有关使用情况和后续待添加内容的宝贵研究成果。

测试复原模式

复杂部署的风险在于存在级联故障，即，其中一个组件故障会导致依赖组件失败以及其他问题，直到整个系统崩溃。 请务必了解单一故障点 (SPoF) 的位置及其缓解方式，同时还应测试缓解流程，尤其是在生产环境中。

选择正确的指标

设计指标可能十分困难。 其中一个常见错误是包含过多指标以免错过所有内容。 但这可能会导致忽略或不信任不满足特定需求的指标的值。 相反，Microsoft 团队需要时间来确定度量成功所需的数据。 团队可能会添加或更改指标，但从一开始就了解此目的将有助于完成该流程。

除指标的基础知识之外，团队还需考虑他们需要度量的指标。 例如，用户增加的速度或加速率可能比用户总数更有用。 指标因项目而异，但最有帮助的指标是有可能推动业务决策的指标。

使用指标来指导工作

Microsoft 包括附带最高领导级别评审的指标。 每六周，组织就会展示他们在运行状况、业务、场景和客户遥测方面的工作情况。 组织会就指标与高管及其团队进行讨论。

整个组织的团队都会评审引入的用户指标，从而确定它们对功能的含义。 团队不仅交付功能，还希望了解用户是否以及如何使用这些功能。 团队使用这些指标来调整积压工作，并确定是否需对功能投入更多工作才能达到目标。

交付指南

• 从 A 到 B 从来就不是直线， B 也并非终点。
• 挫折和失误在所难免。
• 将挫折视为改变针对完成此流程给定部分的策略的学习机会。
• 随着时间的推移，每个团队均应通过基于经验和调整来满足不断变化的需求从而改进其 DevOps 实践。
• 其中的关键是专注于向最终用户和交付流程本身提供价值。