微软DevOps技术转型实践

1、 微软DevOps技术转型实践目 录 TOC o 1-3 h z u HYPERLINK l _Toc15834644 1.前言 PAGEREF _Toc15834644 h 3 HYPERLINK l _Toc15834645 2.DevOps at Microsoft PAGEREF _Toc15834645 h 5 HYPERLINK l _Toc15834646 3.微软的分支策略 PAGEREF _Toc15834646 h 5 HYPERLINK l _Toc15834647 3.1.转型之前 PAGEREF _Toc15834647 h 5 HYPERLINK l _Toc158

2、34648 3.2.转型思路 PAGEREF _Toc15834648 h 6 HYPERLINK l _Toc15834649 3.3.开发过程 PAGEREF _Toc15834649 h 7 HYPERLINK l _Toc15834650 3.4.在Sprint里程碑进行发布 PAGEREF _Toc15834650 h 9 HYPERLINK l _Toc15834651 3.5.发布Hotfix PAGEREF _Toc15834651 h 9 HYPERLINK l _Toc15834652 3.6.勇往直前 PAGEREF _Toc15834652 h 11 HYPERLINK

3、 l _Toc15834653 4.总结 PAGEREF _Toc15834653 h 12前言据说75%的企业转型会以失败告终，但在互联网软件领域，有一家世界级的公司堪称传奇，在经历了创新者的窘境、被业界唱衰多年之后，凭借“云为先、移动为先”的战略东山再起，这就是市值刚刚突破万亿美元、成为目前全世界市值最高公司的微软。这家PC时代的巨头在五年前遭遇着一系列的危机，在消费端硬件和移动互联网方面”全面溃败”：智能手机业务被苹果和Google绞杀；云计算业务亚马逊主导天下；Bing搜索持续烧钱，但份额不到6%；Win8是微软历史上被诟病最多的系统；微软市值处于低谷期，不足3000亿美元也许有些人对

4、微软的印象还停留在卖”套装软件”的时期，重型的系统软件、漫长的研发周期，2-3年才能有重大的软件更新版本面世。但是，也许你已经惊奇的发现，这家重回巅峰的公司现在已经完全不同了！尤其是软件研发效能方面指数级的快速提升：目前每天更新50万条工作项，每天运行5亿个测试，每月超过400万次构建，每天发布4.2万次是的，微软”刷新”了我们的认知，以至于近期有很多人从各种角度来分析微软的成功。使命、愿景、价值观这些词虽然听起来很励志，但总给人虚无缥缈的感觉。今天，就让我们从更落地、更实实在在的角度，来全面剖析下这家公司成功背后的技术转型实践，相信会对大家有所启发。DevOps at Microsoft本系

5、列文章我们会重点介绍微软的DevOps转型实践，为了确保其准确性，我会引用很多来自其Azure DevOps内部的”第一手资料”，力争做到客观全面。本系列文章预计会包含的实践内容如下：微软的分支策略：Release Flow微软的敏捷原则和实践微软的DevSecOps文化转型微软的Live-Site生产优先模式微软从单体应用到云服务的转型微软如何利用功能开关开展实验测试左移以获得速度和可靠性测试右移以在生产环境进行验证微软的安全部署实践微软在云端的弹性工程实践我们先从微软工程效率的一个重要基石 - 分支策略开始。微软的分支策略转型之前微软原来采用的分支策略非常重型：有一条共享的主干，每个大的产

6、品组拉出自己的Group分支进行开发，然后基于Group分支拉出小组SubGroup分支，而在开发具体功能时还需要拉出Feature分支进行编码。每一级分支都需要跟上一级分支进行同步，然后把验证后的代码合并回上级分支（RI: Regression Integration）。当团队人数众多时，从叶子分支合并回主干会经历漫长的”合并地狱”，效率非常低下。进入到Git时代，工作在单一主干上、并且使用Pull Request 工作流合并代码经常被看做是远离技术债、保证发布稳定的关键因素。于是微软Azure DevOps团队逐步转型为一种被称为”Release Flow”的分支模型。转型思路为了能够更快

7、速、更有规律的发布，Azure DevOps团队开始采用”主干开发”的分支策略。这种策略能够满足规模化的开发需求：帮助跨越三个主要办公室、工作在同一个代码库上，拥有数百名工程师的整个产品团队，高效地开发并部署代码到全球多个数据中心。开发过程1. Branch当开发人员想要实现一个Feature或修复一个Bug时，从主集成分支master拉出一条新的分支。由于Git具有轻量级的分支管理，我们每次想要开发一些代码时都创建一条短时存在（Short-lived）的特性分支。开发人员被鼓励尽早提交代码，并通过使用功能开关来避免长期存活的长特性分支。2. Push当开发人员准备好对他们的变更进行集成，并共

8、享给团队其他人的时候，他们Push本地的分支到远端服务器，并且创建一个Pull Request。因为我们有数百名工程师工作在代码库上，每个人都有很多条分支，我们使用一种命名约定来帮助减轻混淆。通常，开发人员的本地分支命名为：users/username/feature，其中username是开发人员的账户名。3. Pull Request团队通过Pull Request来控制开发人员的特性分支合并到master。Pull Request确保了我们的分支规则被满足：首先，构建想要合并的变更并运行快速验证测试。我们会在仅仅5分钟之内就运行60,000个L0和L1级别的测试。其中L0级别主要是单元测

9、试，不依赖于产品被安装运行；L1级别测试也类似于单元测试，但是会依赖数据库等外部资源。注意，这并不是我们完整的测试矩阵，但是可以足够快速地给我们合并代码的高度自信。接下来，我们需要团队的其他成员Review代码并审批代码变更。代码评审的目标是找出自动化测试没有发现的问题，特别是指出那些架构相关的问题。人工代码评审可以保证团队中的更多工程师对于变更的可见性，并确保代码质量保持在较高水准。4. Merge当所有的构建规则被满足，并且代码评审通过，Pull Request就完成了。这意味着特性分支合入到了主集成分支master。在合并之后，我们运行额外的、需要更长时间运行的验收测试。这类似于传统的代

10、码提交后测试，我们运行这些测试进行更加全面的验证。这带给我们在快速反馈和完善的测试覆盖之间的良好平衡。截止到目前，你可能会觉得这里的分支策略很类似典型的主干开发模型。但是，与其他开发模型（如GitHub Flow）不同的是，我们不会在代码通过Pull Request合并到主干之前部署并测试他们，也不会在Pull Request合并之后立即部署到生产环境。GitHub Flow模型中经常会被忽略的一点，就是Pull Request实际上会在合并回master之前就直接交付到生产环境（做测试），这意味着开发人员需要在合并之前等待”部署队列”来验证他们的变更。Azure DevOps团队拥有数百名开

11、发人员在代码库上工作，每天在主干上会有超过200个Pull Requests。如果每个合并请求需要部署到全球多个数据中心，我们的开发人员将会浪费掉大量的时间等待队列而不是开发代码。在Sprint里程碑进行发布在每个Sprint结束，我们会基于master创建一个发布分支。比如在Sprint 129，我们会创建releases/M129。然后我们使用这个分布分支进行部署上线。当我们拉出发布分支，master分支保持开放，开发人员可以合并变更。当然，这些变更我们并不会立即部署到生产环境，而是会等待下个迭代的部署。发布Hotfix很明显，有一些变更需要更快地发布到生产环境（而不是按迭代）。我们通常不

12、会在迭代过程中添加大型的新特性，但有时我们需要把缺陷或可用性问题快速修复并发布到生产环境，解决影响用户的问题。在这种情况下，我们从普通工作流开始：从master拉取分支，修改代码并评审通过，完成Pull Request并合并回主干。注意，我们总是从在master上进行变更开始，这样可以让我们快速创建变更内容，然后在本地验证它，而不需要切换到发布分支。更重要的是，遵循这样的流程，我们可以保证我们得变更被合并到master。这对我们非常重要：如果我们先在发布分支修改缺陷，然后很可能会忘记把变更合并回master，那么下次发布的时候（比如从主干拉出的Spring 130发布分支）就会导致问题复发。因

13、为在遇到生产环境问题或中断时，我们总是充满了混乱和压力，很可能忘记将代码合并回主干。所以，我们要保证每次变更首先合入master，以便确保在master和发布分支上都会有本次变更。当然，以上流程在Azure DevOps中也有支持，可以在Pull Request页面，选择Cherry-Pick一个Pull Request到不同的分支（Gitlab也有类似的功能）。为了能够让变更立即发布到生产环境，每当我们合并Pull Request到主干，我们Cherry-Pick这个变更到发布分支。这样会创建一个新的、目标为发布分支的Pull Request，用于移植主干上最新的变更内容。通过创建一个新的P

14、ull Request，我们通过分支策略获得了可追踪性和可靠性。使用Azure DevOps提供的Cherry-Pick功能可以让我们做得更快：我们不需要把发布分支的代码下载到本地电脑然后Cherry-Pick变更，因为这些都已经在服务端高效地完成了。如果你需要做一些变更，比如修改合并冲突或者因为两条分支的不同而修改一小部分内容，我们也可以在服务端完成。我们可以直接在工具内置的文本编辑器中修改内容，或者使用Pull Requet Merge Conflict插件完成。当我们创建了目标为发布分支的Pull Request，仍然需要再次进行代码评审，评估分支规则并测试它。当变更被合并，就会在几分钟

15、内部署到第一批次的服务器。从这里开始，我们会使用”部署环”逐步扩展部署到更多的用户群体，金丝雀用户-早期采用者-全部用户。随着变更暴露给更多的用户，我们将会监控其成功率，以确保变更修复了缺陷的同时，没有引入其他的问题及性能衰退。勇往直前在迭代完成后，我们完成了向Sprint 130中增加特性，那么我们可以部署这些变更了。为了进行部署，我们从master创建了新的发布分支releases/M130。在这个时间点上，实际上我们有两条生产分支：由于我们使用”部署环”向生产环境安全地部署，”快速环”已经融入了Sprint 130的变更，与此同时”慢速环”仍然保持在Sprint 129，因为新的变更正在生产环境进行验证。这会带来一个有趣的问题：如果我们需要在部署期间做一个新的Hotfix变更，则需要同时在Sprint 129和Sprint 130发布上进行。当所有的”部署环”都部署完成，Sprint 129的老发布分支将会被移除。我们不再需要它，因为我们已经非常小心地确保了任何加入到Sprint 129的Hotfix变更都同时存在于master分支了。那么