Microsoft在向生产环境提供高度可缩放的服务方面拥有数十年的经验。 随着Microsoft服务和环境的发展，其交付实践也随着时间推移而演变。 许多Microsoft客户也采用了并受益于这些高效的交付做法。 以下核心 DevOps 原则和流程适用于任何新式软件交付工作。
若要实现 DevOps 交付过程，Microsoft采用以下计划：
- 专注于组织思维模式和交付节奏。
- 形成自主、负责的团队，他们拥有、测试和交付功能。
- 向右转移，在生产环境中测试和监视系统。
专注于交付
更快交付是组织和团队可以轻松衡量和欣赏的明显好处。 典型的 DevOps 节奏涉及短 冲刺 周期，定期部署到生产环境。
由于担心短跑缺乏产品稳定性，一些团队在短跑周期结束时用稳定期进行了补偿。 为了在冲刺期间提供尽可能多的功能，工程师们承担了需要在稳定期偿还的技术债务。 在冲刺期间管理他们债务的团队必须支持那些积累债务的团队。 额外成本贯穿在交付管道和生产过程中。
消除稳定期迅速改善了团队管理债务的方式。 建立债务的团队不得不在下一次冲刺中赶上债务目标，而不是将关键维护工作推迟到稳定期。 Teams 在冲刺期间迅速学会了管理其测试债务。 功能在经过验证且值得部署成本时提供。
完全自动化管道
许多改进措施能够让团队立即受益，即从代码存储库到生产环境的流水线进行完全自动化。 自动化包括具有 持续集成（CI）、自动化测试和 持续交付（CD）的发布管道。
团队可能会避免部署，因为它很困难，但部署频率越低，就越难部署。 部署之间的时间越多，问题就越多。 如果代码不新鲜，则存在部署债务。
通过频繁部署，可以更轻松地在较小的区块中工作。 这种想法在事后看起来可能很明显，但当时它看起来可能适得其反。 频繁的部署还激励团队优先创建更高效可靠的部署工具和管道。
使用内部工具
Microsoft使用生成的发布管理系统，并将其交付给客户。 单个投资可提高团队工作效率和Microsoft产品。 使用辅助系统会削弱开发和交付的速度。
团队自主性和责任
没有特定的关键进度指标（KPI）衡量团队的工作效率或性能，或者某个功能是否处于正轨状态。团队需要能够管理自己的计划和积压工作，同时找到一种方法来符合组织目标。
与团队直接沟通以跟踪进度非常重要。 工具应促进沟通，但对话是最透明的沟通方式。
确定功能的优先级
一个重要目标是专注于提供功能。 计划可以评估给定时间段内团队和个人可以合理完成多少，但某些功能将提前提供，一些功能稍后会提供。 团队可以排列工作的优先级，以确保最重要的功能能够进入生产环境。
使用微服务
微服务 提供了各种技术优势，可改进和简化交付。 微服务还提供团队所有权的自然边界。 当团队对微服务的投资具有自主性时，他们可以确定如何实现功能和管理债务的优先级。 团队可以专注于版本控制等因素的计划，而不受整体依赖于微服务的服务的影响。
在主功能中工作
工程师曾经在单独的部门工作。 在每个分支上的技术负债持续增加，直到工程师尝试把各自的分支合并到主分支。 那里的团队和工程师越多，集成就越大。
为了更快地、更连续地进行集成，工程师现在在主分支中工作。 迁移到 Git 的一个重要原因是 Git 提供的轻量级分支。 内部工程的好处是消除深层分支层次结构及其浪费。 用于集成的所有时间现在都倾注到交付中。
使用功能标志
对于冲刺部署，某些功能尚未完全完成，但仍可以从生产中的测试中受益。 Teams 可以将此代码与 功能标志 合并并部署，以便为特定用户启用该功能，例如开发团队或一小部分早期采用者。 功能标志可控制暴露，而不会给整体用户群带来风险，并且可以帮助团队确定是否以及如何完成该功能。
在生产环境中进行测试
在生产环境中向右转移 测试有助于确保预生产测试有效，并且不断变化的生产环境已准备好处理部署。
仪器测试和指标
无论应用在何处部署，进行全面监控都很重要。 仪器化不仅可以识别并修复问题，还能提供关于使用情况以及下一步添加内容的宝贵研究。
测试复原模式
复杂部署的风险是 级联故障，其中一个组件故障导致依赖组件失败，等等，直到整个系统崩溃。 请务必了解 单一故障点（SPOF） 的位置及其缓解方式，以及测试缓解过程，尤其是在生产环境中。
选择正确的指标
设计指标可能很困难。 一个常见的错误是包含过多的指标，以避免缺少任何内容。 但这可能会导致忽略或不信任不满足特定需求的指标的值。 相反，Microsoft团队花点时间确定衡量成功所需的数据。 从一开始了解目的有助于团队添加或更改指标的过程。
除了指标的基础之外，团队还考虑他们需要衡量的指标。 例如，用户增益的速度或加速率可能比用户总数更有用。 指标因项目而异，但最有帮助的指标是有可能推动业务决策。
使用指标指导工作
微软在最高领导层的评审中包含指标。 每六周，组织会展示他们在健康状况、业务、情景和客户遥测方面的表现。 组织将指标与高管及其团队讨论。
整个组织的团队都会检查参与的用户指标，以确定其功能的含义。 Teams 不仅提供功能，还希望了解用户是否以及如何使用这些功能。 团队使用这些指标来调整待办事项，以及确定功能是否需要进一步的工作才能达到目标。
交付指南
- 从 A 到 B 不是直线， 也不是 B 结束。
- 总会有挫折和错误。
- 将挫折视为改变完成过程给定部分的策略的学习机会。
- 随着时间的推移，每个团队都通过基于经验和调整来满足不断变化的需求来改进其 DevOps 实践。
- 关键是专注于向最终用户和交付过程本身交付价值。