你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

通过数字发明为采用提供支持

创新的最终考验是客户对发明的反应。 假设是否成立？ 客户是否使用该解决方案？ 它是否可以缩放以满足用户所需百分比的需求？ 最重要的是，他们是否会回访？ 直到部署了最小可行产品 (MVP) 解决方案，才可提出这些问题。

本文将重点介绍如何使用持续集成和持续部署 (CI/CD) 管道工具来为采用提供支持。 持续集成是每天多次自动执行代码，以便拥有更新的单个项目。 持续部署是一天中自动交付这些功能。

减少影响采用的 CI/CD 摩擦

通过技术和流程的组合，可以最大程度地减少采用的一些障碍。 如果读者了解 CI/CD 或 DevOps 流程，则不会对以下 CI/CD 管道流程感到陌生。 本文为推动创新和反馈循环的云采用团队建立一个起点。 随着产品和团队的成熟，这个起点可能会培养出更可靠的 CI/CD 或 DevOps 方法。

如衡量客户影响中所述，任何假设的积极验证都需要迭代和确定。 这篇 CI/CD 文章旨在最大限度地减少阻碍创新的技术峰值，同时确保你采用最佳做法。 这样做将有助于团队设计未来的成功，同时满足当前的客户需求。

为采用和数字发明提供支持：成熟度模型

创新方法的主要目标是建立客户合作伙伴关系并加速反馈循环，从而推动市场创新。 下面的图片和部分描述了支持此方法的初始实现。

• 共享解决方案：为解决方案的所有方面建立集中式存储库。
• 反馈循环：确保可以通过迭代以一致的方式管理反馈循环。
• 持续集成：定期生成和合并解决方案。
• 可靠测试：验证解决方案质量和预期更改，以确保测试指标的可靠性。
• 解决方案部署：部署解决方案，以便团队可以与客户快速共享更改。
• 集成度量值：将学习指标添加到反馈循环，以便整个团队进行清楚的分析。

为了最大程度地减少技术峰值，假设这些原则的成熟度最初会很低。 通过与可随着假设更精细化而缩放的工具和流程保持一致来提前规划。 在 Azure 中，GitHub 和 Azure DevOps 可使小型团队在几乎没有摩擦的情况下开始工作。 这些团队可能会发展到包括数千名开发人员，他们在大规模解决方案上进行协作，并测试数百个客户假设。 本文的其余部分介绍了“大计划、小开始”的方法，以支持这些原则的采用。

共享解决方案

如衡量客户影响中所述，任何假设的积极验证都需要迭代和确定。 在任何创新周期中，失败数都远多于成功数。 这是正常情况。 但是，当客户需求、假设和解决方案大规模一致时，局势就大有不同了。

缩放数字发明和创新时，没有什么工具比共享的解决方案代码库更有价值了。 遗憾的是，无法可靠地预测哪个迭代或哪个 MVP 组合在一起会成功。 这就是为什么建立共享代码库或存储库永远都不嫌早的原因。 这是一个不应延迟的技术尖峰。 当团队遍历各种 MVP 解决方案时，共享存储库可实现轻松协作和加速开发。 当对解决方案的更改拖累了学习指标时，通过版本控制可回滚到解决方案的更早、更有效的版本。

用于管理代码存储库的最广泛采用的 CI/CD 工具是 GitHub，只需几个步骤即可创建共享代码存储库。 此外，Azure DevOps 的 Azure Repos 功能可用于创建 Git 或 TFVC 存储库。

反馈循环

让客户成为解决方案的一部分是在创新周期中建立客户伙伴关系的关键。 这部分是通过衡量客户影响来实现的。 它需要与客户进行对话和直接测试。 两者都会生成必须有效管理的反馈。

每个反馈点都是满足客户需求的潜在解决方案。 更重要的是，客户的每一点直接反馈都是改善合作关系的机会。 如果反馈演变成了一个 MVP 解决方案，这对双方而言都是一个好消息。 即使某些反馈是不可操作的，仅仅是透明地决定不去设置反馈的优先级也表明了成长型思维模式和对持续学习的关注。

Azure DevOps 包括请求、提供和管理反馈的方法。 这些工具集中了反馈，使团队能够采取措施，并为透明反馈循环提供跟进服务。

持续集成

持续集成是每天多次自动执行代码，以更新单个项目。 随着采用规模和假设越来越接近真正的大规模创新，要测试的较小假设的数量往往会迅速增长。 为了实现准确的反馈循环和平稳的采用过程，重要的是将这些假设进行集成，并支持创新背后的主要假设。 这需要快速进行创新和发展，于是就需要多个开发人员来测试核心假设的变体。 对于后期开发工作，你甚至可能需要多个开发团队，每个团队都朝着共享解决方案的方向发展。 持续集成是管理所有移动部件的第一步。

在持续集成中，代码更改经常合并到主分支中。 自动化生成和测试过程确保了主分支中的代码始终保持生产质量。 这可确保开发人员协同工作，共同开发提供准确且可靠反馈循环的共享解决方案。

Azure DevOps 和 Azure Pipelines 只需在 GitHub 或其他存储库中执行几个步骤即可提供持续集成功能。 有关详细信息，请参阅什么是持续集成？或尝试持续集成动手实验室。 可以使用解决方案体系结构加速通过 Azure DevOps 创建 CI/CD 管道。

可靠测试

任何解决方案中的缺陷都可能会生成假正或假负。 意外错误很容易导致对用户采用指标的误解。 它们还可能产生来自客户的负面反馈，而这些反馈并不能准确地代表假设的检验结果。

在 MVP 解决方案的早期迭代期间，预计会出现缺陷。 早期采用者甚至可能会觉得它们很讨人喜欢。 在早期版本中，验收测试通常不存在。 然而，建立同理心的一个方面涉及对需求和假设的验证。 两者都可以通过代码级别的单元测试和部署前的手动验收测试来完成。 总之，它们提供了一些测试可靠性的方法。 应尝试自动执行一系列定义明确的生成、单元和验收测试。 这些将确保与对假设和生成的解决方案进行更精细调整相关的可靠指标。

Azure Test Plans 功能提供了在手动或自动测试执行期间开发和操作测试计划的工具。

解决方案部署

也许授权采用最有意义的方面是能控制向客户发布解决方案。 通过提供用于向客户发布解决方案的自助服务或自动化管道，将会加速反馈循环。 通过允许客户快速与解决方案中的更改进行交互，你可以邀请他们参与该过程。 这种方法还可以更快地测试假设，减少假设和潜在的返工。

有几种解决方案部署方法。 最常见的三种是：

• 持续部署是最先进的方法，因为它会自动将代码更改部署到生产环境中。 对于正在测试成熟假设的成熟团队来说，持续部署可能非常有价值。
• 在开发的早期阶段，持续交付可能更合适。 在持续交付中，任何代码更改都会自动部署到类似生产的环境中。 开发人员、业务决策者和团队中的其他人可以使用此环境来验证他们的工作是否已生产就绪。 还可以使用此方法来验证客户的假设，而不会影响正在进行的业务活动。
• 手动部署是最不复杂的发布管理方法。 顾名思义，团队中的某些人员会手动部署最近的代码更改。 这种方法容易出错、不可靠，大多数经验丰富的工程师都认为这是一种反模式。

在 MVP 解决方案的第一次迭代期间，手动部署很常见，尽管之前进行了评估。 当解决方案非常流畅且客户反馈未知时，重置整个解决方案（甚至是核心假设）存在重大风险。 这是手动部署的一般规则：没有客户证明，没有部署自动化。

初期投资可能会导致时间损失。 更重要的是，它可以在发布管道上创建依赖关系，使团队能够更好地抵御早期的数据透视。 在前几次迭代之后，或客户反馈表明潜在的成功后，应快速采用更高级的部署模型。

在假设验证的任何阶段，Azure DevOps 和 Azure Pipelines 都提供持续交付和持续部署功能。 详细了解持续交付，或查看动手实验室。 解决方案体系结构还可以加速通过 Azure DevOps 创建 CI/CD 管道。

集成度量值

衡量客户影响时，了解客户对解决方案更改的反应非常重要。 该数据称为遥测，可让你深入了解用户（或用户群组）在使用解决方案时所采取的操作。 借助这些数据，很容易对假设进行定量验证。 然后可以使用这些指标来调整解决方案并生成更精细的假设。 这些细微的更改有助于在后续迭代中使最初的解决方案更加成熟，最终推动大规模的重复采用。

在 Azure 中，Azure Monitor 提供了从客户体验中收集和审查数据的工具和界面。 可以使用 Azure Boards 应用这些观察和见解来优化积压工作 (backlog)。

后续步骤

在了解了支持采用所需的 CI/CD 管道工具和流程之后，是时候研究更高级的创新学科了：与设备交互。 这门学科可以帮助减少物理体验和数字体验之间的障碍，使解决方案更易于采用。

与设备交互