精通微软 PowerPlatform 上的 DevOps（一）_power platform

原文：annas-archive.org/md5/500a107f5b6fc7d7506eff9576d6eaca

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

Microsoft Power Platform 是全球领先的低代码、无代码平台——一个现代化的应用运行时，能够实现无限数量的业务解决方案。 随着这些场景变得越来越复杂且业务关键，专业的 DevOps 流程需求也愈加迫切。 本书聚焦于定制软件开发项目中的著名实践，并将这些常见活动映射到 Microsoft Power Platform 工具集。 我们探讨软件开发生命周期的每个阶段，以及此软件即服务（SaaS）产品所提供的工具和功能，详细讨论诸如打包、构建、部署、测试和发布解决方案等常见的 DevOps 活动。 此外，我们深入探讨 DevSecOps 流程，并介绍在 Microsoft Power Platform 中融入安全性的开发实践。 您将了解现代 DevOps 工具，如 Azure DevOps 服务和 GitHub，以及如何为 Microsoft Power Platform 实施 DevOps 流程的不同方式。 通过正确的 DevOps 实施，我们的解决方案可以在高度监管的行业中以受控且 有序的方式运行。

我们坚信，低代码平台是为专业开发人员设计的。 Microsoft Power Platform 是一个快速应用开发框架，是唯一为公民开发者（创作者）提供 UI 界面的框架。 该平台是为专业开发人员和工程团队创建的，旨在减少业务应用程序的上市时间。 但是，这只有在专业的 DevOps 流程支持下才有效。

作为一种独特的方法，本书将这两个正交的领域结合在一起：一方面是能够构建复杂解决方案的低代码/无代码爱好者，另一方面是了解 DevOps 和应用生命周期管理的专业开发人员。 这些知识对您来说是一个独特的机会，亲爱的读者，能够帮助您建立起有力的竞争力， 在就业市场中占据优势。

作为最后的思考，随着生成性 AI 解决方案的崛起，开发者的工作将发生显著变化，重点将转向提示工程和更大的构建模块。 由于 AI 代理可以充当不同的角色（如开发者、测试人员或项目经理），并且仅凭提供的提示就能独立合成应用程序，因此我们不再编写代码行，而是制作组件。 这些组件可以与 Power Platform 提供的构建模块相对应。 考虑到 Power Platform 的 Copilot，新的应用程序构建时代刚刚开始，只有在与定制开发项目相同的 DevOps 流程得以实施时，才能获得成功。 开发项目。

本书适合的人群

本书面向对软件开发和 IT 运维领域感兴趣的专业人士，特别是那些希望了解应用程序 生命周期 管理 (ALM)以及针对 Microsoft Power Platform 的 DevOps 流程的人士。 适合以下人群：

• 软件开发人员

• DevOps 工程师

• 云架构师

• 站点可靠性工程师

• 测试人员

• 低代码工程师

本书对那些已经具备基本软件开发流程和生命周期工具理解的读者尤为有益。 此外，它也是那些对 Power Platform 的 ALM 和 DevOps 方面感兴趣的专业开发人员的绝佳资源。

本书内容

第一章，掌握 DevOps 和 ALM 以提高软件开发效率，概述了软件开发行业中最重要的突破，如敏捷、精益和 DevOps，并解释了先进的应用程序开发流程和模式，以及前沿的 DevOps 和 ALM 实践。

第二章, Microsoft Power Platform 入门，首先介绍了低代码/无代码开发方法，概述了微软 Power Platform 服务，并描述了该平台如何遵循各种治理和合规标准，使其成为一个适合企业的开发平台。 它展示了如何配置一个试用环境，可以用来配合书中的示例进行操作。 本章还深入探讨了管理 Power Platform 的工具以及开始构建业务应用程序的选项。

第三章, 在微软 Power Platform 中探索 ALM 与 DevOps，致力于建立 ALM 与 DevOps 与 Power Platform 之间的联系。 本章简要介绍了 Azure DevOps 和 GitHub。 为了帮助组织理解如何利用 Power Platform 来改善现有的应用程序组合，本章讨论了应用现代化选项。 本章最后通过连接能力成熟度模型指数（CMMI）和 Power Platform 采纳成熟度模型，帮助组织制定计划，在不同领域提高成熟度。

第四章, 理解 Power Platform 环境与解决方案，涵盖了 Power Platform 的基本构建块：环境和解决方案。 本章还讨论了环境策略、托管环境和 Power Platform 流水线。 本章最后通过一个实践实验室，指导我们如何利用 Power Platform 流水线构建第一个持续集成和持续交付流水线。

第五章, 通过 DevOps 工具简化 Power Platform 开发，更进一步，释放了超越 Power Platform 流水线的工具。 本章讨论了 Git、PAC CLI 和 Azure DevOps Services 流水线，结合 Power Platform 特定的构建任务和 GitHub 动作，来进行跨环境的 CI/CD 解决方案。 最后，本章将前一章中的 Power Platform 托管流水线结果与专业 DevOps 工具相结合，并直接从托管流水线中查看版本控制集成。

第六章，持续集成/持续部署（CI/CD）管道深度剖析，描述了 DevOps CI/CD 流程的高级模式，如 Git 分支策略、Power Platform 的自动化测试框架以及 Power Platform Catalog 的包管理。 它讲解了 Azure DevOps 中的 YAML 管道和 GitHub 工作流，这些工作流分别通过使用各种 PAC CLI 命令、GitHub 动作和 Azure DevOps 构建任务，自动启动开发者分支和开发者环境。 此外，它讨论了 Power Platform 的 ALM 加速器，以及该解决方案如何利用管道模板、分支策略和环境管理等作为可复用的解决方案应用于 我们的项目。

第七章，Power Platform 中的 DevSecOps 概述，介绍了软件开发项目中 DevSecOps 的理论，并将与安全相关的活动映射到我们 Power Platform 项目的 DevOps 流程中。 它深入探讨了 GitHub 高级安全性和静态应用程序安全测试的 CodeQL。 它介绍了解决方案检查器，并展示了如何在有 Entra ID 组、服务主体和其他安全防护措施的情况下大规模启动 DevSecOps 项目。 最后，它通过对已建立流程的表面攻击和风险分析，给出了解决方案管理的建议 ，跨租户管理。

第八章，展示 ALM 和 DevOps 实施，深入探讨了 DevOps 和 ALM 原则的实际应用。 本章提供了一个现实世界示例——Power Platform 企业模板公共仓库中的 Kudos 应用——的动手练习，从 Git 分支策略到 CI 和 CD 管道，再到自动化测试、待办事项管理以及生产环境中应用的监控。 最后，本章介绍了功能标志来控制 功能发布。

第九章, 实施融合开发方法，强调了构建融合团队的重要性，这些团队帮助组织实现目标。 本章展示了融合开发方法的示例，并讨论了 InnerSource 实践的重要性。 然后，继续探讨与 Microsoft Azure 云服务集成的可能性。 最后，通过展示一个常见的 Azure 和 Power Platform 集成场景来结束本章。

第十章, 在 Power Platform 中启用专业开发者扩展性，继续解释专业开发者在为 Power Platform 开发时的各种可能性。 本章涵盖了集成场景中连接器的强大功能以及将配置与应用程序解耦的选项。 它深入探讨了可重用组件和自定义代码组件的强大功能。 本章展示了如何开发代码组件，并如何将 ALM 实践应用于代码组件。 本章最后通过探索 Power Pages 的应用生命周期管理来结束。

第十一章, 环境管理 生命周期 与设计最佳实践，基于设计最佳实践。 本章讨论了 Power Platform 的架构设计及 Power Platform 的着陆区，解释了它们如何帮助组织构建遵循最佳实践并部署在有治理和安全环境中的应用工作负载。 接着，本章转向环境生命周期管理，并讨论了不同方法的自动化环境管理，包括基础设施即代码和 Terraform。 最后，本章通过探讨 Power Platform 卓越中心及 CoE 启动工具包如何帮助组织管理 Power Platform 租户。

第十二章，与 Copilots、ChatOps 和 AI 注入应用程序展望未来，是本书的最后一章，讨论了人工智能如何帮助组织丰富其应用程序。 它有助于理解如何使用各种 Copilot 来提高开发者的生产力，以及 AI Builder 或 Azure OpenAI 如何现代化现有的业务流程。 我们通过讨论 Copilot Studio 和它能够创建定制化 Copilot 来结束这一章和本书，Copilot 可以帮助组织使用定制的 AI 助手自动化 DevOps 流程。

要充分利用本书

你需要具备 Microsoft Power Platform 产品系列的基本了解，以及软件开发实践和 IT 应用管理、支持和监控的基础知识。 除了这些理论知识，你还需要安装以下软件组件，以便能够在本地执行提供的脚本 代码片段：

本书涉及的 软件 操作系统要求 Windows 子系统 适用于 Linux Windows Bash Linux .NET Framework 4.7.2 或更高版本 Windows Windows PowerShell 版本 5.x Windows Dotnet 6 Windows 或 Linux PAC CLI Windows 或 Linux Visual Studio Code Windows 或 Linux

请注意，脚本是为在 Azure DevOps 或 GitHub 的云托管代理上运行而创建的，本地执行仅用于 演示目的。

为了充分利用本书，你需要拥有 Power Platform 开发者许可证、Azure DevOps 或 GitHub 组织（公共仓库的免费计划足矣），以及一个 Microsoft Azure 租户。 不需要 Microsoft Azure 订阅，因为我们将仅使用 Microsoft Entra ID 功能来将 Power Platform 世界与我们首选的 DevOps 工具连接起来。 当然，如果你的组织有这些在线服务的企业级套餐，使用示例的体验将更加顺畅 且直接。

书中有许多示例，是为 Azure DevOps 服务和 GitHub 创建的。 这些章节中阐述的概念在这些 DevOps 工具之外是相同的，脚本可以轻松地在这些平台之间迁移。 我们强烈建议你在自己选择的 DevOps 工具中创建工作流，因此可以选择使用 Azure DevOps 或 GitHub 来进行书中的示例。 书中的样例。

在 第七章中，建议为 GitHub 或 Azure DevOps Services 安装 GitHub 高级安全插件。 尽管可以在本地执行 CodeQL 命令，但 Azure DevOps 和 GitHub 的高级安全功能仅在公共项目和公共仓库中可用。 也是如此。

如果你正在使用本书的数字版本，我们建议你亲自输入代码，或者通过 GitHub 仓库（下一个章节提供链接）访问并 fork 代码。 这样做有助于你避免因复制粘贴代码而可能出现的错误。 代码。

你可以将现实世界的示例放在 第八章 的单独仓库中，将你在本书中学到的所有内容放入同一个解决方案中。 这样，你将拥有一个端到端的、生产就绪的 DevSecOps 参考实现，适用于 你的组织。

下载示例代码文件

你可以从 GitHub 下载本书的示例代码文件，地址为 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform。如果代码有更新，将会在现有的 GitHub 仓库中更新。

我们还提供了其他来自我们丰富书籍目录的代码包，地址为 https://github.com/PacktPublishing/。快来看看吧！

使用的约定

本书中使用了许多文本约定。

文本中的代码：指示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。 例如： “我们将通过更改 SingleLine.Text 为数字（Whole.None）来更改 高亮的属性。”

代码块设置如下 ：

 pac admin helppac admin list help

当我们希望特别引起您对代码块中特定部分的注意时，相关的行或项会以 粗体显示：

 codeql.exe database analyze .\\codeql-database-js .\\codeql-pack\\ javascript\\codeql\\javascript-queries\\0.8.12\\codeql-suites\\ javascript-code-scanning.qls --format=csv --output=results.csv

任何命令行输入或输出如下所示：

 pac solution create-settings --solution-zip .\\EnvConnRef_1_1_managed.zip

粗体：表示一个新术语、一个重要的词汇或您在屏幕上看到的词汇。 例如，菜单或对话框中的词汇会这样显示。 例如：“这次我们选择 新建 | 更多 | 环境变量。”

提示或重要说明

显示如下。

联系我们

来自读者的反馈 总是欢迎的。

一般反馈：如果您对本书的任何部分有疑问，请在邮件主题中注明书名，并通过邮件联系我们 至 customercare@packtpub.com。

勘误：虽然我们已尽一切努力确保内容的准确性，但错误偶尔会发生。 如果您发现本书中的错误，我们将感激您向我们报告。 请访问 www.packtpub.com/support/errata，选择您的书籍，点击勘误提交表单链接并填写 详细信息。

盗版：如果您在互联网上遇到任何我们作品的非法复制版本，我们将非常感激您提供该地址或网站名称。 请通过 copyright@packtpub.com 与我们联系，并提供相关材料的链接。

如果您有兴趣成为作者：如果您在某个主题上有专业知识，并且有兴趣撰写或参与撰写一本书，请 访问 authors.packtpub.com。

分享您的想法

阅读完 *《Mastering DevOps on Microsoft Power Platform》*后，我们非常希望听到您的反馈！ 请 点击此处直接访问亚马逊的本书评论页面 并分享 您的反馈。

您的评论对我们和技术社区都非常重要，它将帮助我们确保提供优质的 内容。

下载本书的免费 PDF 副本

感谢您购买 本书！

喜欢在路上阅读，但又无法随身携带印刷版 书籍吗？

您的电子书购买是否与您选择的设备不兼容？ 您的选择设备无法使用该电子书吗？

不用担心，现在购买每一本 Packt 图书，你都能免费获得该书的无 DRM PDF 版本 ，无需额外费用。

随时随地，任何设备都能阅读。 从你最喜欢的技术书籍中直接搜索、复制和粘贴代码到 你的应用程序中。

福利不止于此，您每天可以在 收件箱中获得独家折扣、新闻通讯和精彩的免费内容

按照这些简单的步骤获取 福利：

1. 扫描二维码或访问以下 链接

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_QR_Free_PDF.jpg

https://packt.link/free-ebook/978-1-83588-084-5

1. 提交您的购买证明 购买证明

2. 就这样！ 我们将直接把您的免费 PDF 和其他福利发送到您的 电子邮件中

第一部分：理解微软 Power Platform 中的 DevOps

在本节中，我们将建立现代 DevOps 和软件开发方法所需的基础知识，并探讨过去十年低代码/无代码框架兴起的原因。 我们将深入探讨微软 Power Platform，概述其丰富的功能集，并将这些功能与已建立的软件开发生命周期方法进行关联。 此外，我们将研究 CMMI 模型的理论及其对 Power Platform 采纳成熟度模型发展的影响，强调这一模型在 我们实践中的重要性。

本部分包括以下章节： 以下是本部分的章节：

• 第一章, 高效软件开发中的 DevOps 与 ALM 精通

• 第二章, 微软 Power Platform 入门

• 第三章, 在微软 Power Platform 中探索 ALM 与 DevOps

第一章：掌握 DevOps 和 ALM 以实现高效的软件开发

自从第一个程序在打孔卡上编写以来，软件开发实践和方法论已经发生了很大的变化。 如今，各行各业的每个业务流程都依赖软件，我们甚至无法想象没有应用程序的生活，因为它们几乎在我们与世界的每一次互动中都被使用。 在疫情期间，数字化转型得到了加速，创建更多应用程序的需求已达到一个无法仅通过传统软件开发工具和框架来满足的程度。 如今，所有组织都可以看作是软件开发公司，不论其所属行业，得益于全球的 数字化转型。

在本章中，我们将 探讨 应用生命周期管理 (ALM) 在软件开发中的背景。 我们将从 软件开发生命周期 (SDLC)概述开始，接着讨论各种软件开发方法论。 然后，我们将深入探讨 ALM 的概念，从 SDLC 的角度审视它，并探讨从需求工程到开发、测试、生产和维护的全过程。 这些知识至关重要，因为它为我们提供了有效管理和简化规划、创建、测试以及部署各种应用程序过程所需的理解。 我们还将探讨精益（Lean）概念的起源，这是一种强调为客户创造价值和消除浪费的哲学，起源于汽车 制造行业。

接着，我们将介绍敏捷宣言和 Scrum 方法论，这是现代软件开发实践中的关键框架。我们将进一步学习 DevOps 支持的架构，包括各种设计模式和非功能性需求，如可测试性和可部署性。我们还将涵盖持续集成（CI）和持续部署（CD），这两种实践自动化了应用程序生产的各个阶段。最后，我们将讨论发布列车和发布周期的概念，这些是以协调和可预测的方式管理新特性发布的策略。这些知识将帮助我们优化开发流程并提高产品质量。

到本章结束时，我们将熟悉最先进的应用程序开发流程和模式，以及前沿的 DevOps（将开发和运维团队整合在一起，持续为客户交付价值）和 ALM 实践。

本章我们将涵盖以下主要内容：

• 软件开发生命周期（SDLC）——它的全部内容

• 软件开发方法概述

• 什么是 ALM？

• 精益原则、敏捷宣言和 Scrum 方法论

• DevOps 支持的架构模式

• 持续集成（CI）和持续交付（CD）

软件开发生命周期（SDLC）——它的全部内容

软件开发生命周期（SDLC），有时也被称为软件开发过程，是用于以成本效益高的方式生产高质量软件的系统化方法论。我们可以使用过去几十年中开发的几种方法论来开发或修改计算机系统。

最初，这一概念是在 1960 年代创建的。 它的主要目标是建立一个可重复、可审计的、当时顺序的软件开发过程，覆盖从应用程序的构思到最终交付解决方案的步骤，目标是企业大型计算机系统。 自那时以来，许多改进、创新和发明已被实施，从面向对象的编程语言引入，到 DevOps 和 DevSecOps 实践，再到云原生架构，这些都推动了更新的 SDLC 方法论的出现。 随着持续的过程改进，大多数现代软件开发方法论如今遵循敏捷 原则。

阶段

无论选择哪种软件开发方法论，软件开发过程的阶段（阶段）是 相同的：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_001.jpg

图 1.1 – 软件开发阶段

让我们来探索 这些阶段：

• 需求分析 或 需求工程是开发团队收集客户需求和目标的步骤。 开发团队与客户代表密切合作，以确定解决方案的关键特性。 在此阶段，需求也会被分析，即需求会被验证并且明确记录。 该阶段还包括识别系统的非功能需求，如性能、资源需求或可用性预期。 这是确保最终产品满足客户需求 和期望的关键步骤。

• 规划与设计阶段 是开发团队制定项目计划、安排节奏和关键交付成果的阶段。 这个过程通常以 工作分解结构 (WBS) 为结束，开发团队接着将里程碑分配到 WBS 的不同部分，以便在更高层次上跟踪进度。 里程碑通常表示合同义务的完成，从而触发财务结算。 在这一 阶段，团队还设计软件架构和 用户体验 (UX) 。通常使用 UI 的线框图和架构的原型图来获取更多的工作量估算输入。 另一种计算 WBS 任务工作量和复杂度的方法是进行 所谓的 规划扑克。团队成员使用带有数字的卡片分别为任务分配值。 最后，扑克团队成员展示他们的卡片，并讨论结果，直到达成 共识。

• 开发阶段 本质上是编码部分。 团队实现应用程序，编写单元测试，并调试代码。 传统方法将开发阶段视为仅仅是编写代码。 与此不同，敏捷方法消除了这种分离，并将测试和部署早期纳入过程。 他们这样做是为了能够以迭代方式多次重复编码-测试-部署循环。 此外，这些现代方法通过在 每个迭代结束时提供工作软件的访问，促进了开发团队与客户代表之间的协作。

• 测试与质量保证阶段 是关于为应用程序创建不同层次的测试。 开发团队编写并执行集成测试、系统测试、端到端测试、性能测试以及其他非功能性测试，如资源使用或混沌测试，以验证系统是否符合定义的需求。 过去，曾有专门的测试团队，其主要任务是提供这些测试并确保软件满足客户需求。 当 验证通过后，软件就可以交付到生产环境了。

• 部署阶段 是 开发团队将解决方案部署到客户环境中的步骤。 它不仅涉及安装系统，还可能包括配置系统和在某些情况下迁移来自旧解决方案的数据。 部署可以针对本地或云基础设施进行。 如今，这一过程已经完全自动化。 如果需要，开发团队还会进行用户培训，并将文档（用户手册）交给 客户。

• 维护阶段 是 监控生产环境中解决方案的阶段。 根据结果和客户反馈，开发团队会提供更新、升级、修复错误、安全补丁，甚至新增功能。 这一阶段有时被称为支持期，客户需要支付额外费用才能获得开发团队提供的这些服务。 开发团队。

应用运行平台

低代码/无代码平台 是 应用运行平台 ，使专业开发团队能够开发各种类型的应用。 由于这种应用开发与任何其他定制应用开发完全相同，因此可以将相同的 SDLC 方法论应用于这些低代码或 无代码应用。

根据软件开发项目的不同，组织可以采取不同的工作方式，从遵循固定的指南到适应变化的情况。 然而，在所有情况下，上述阶段是相同的。 在下一部分，我们将学习最常用的方法论。

方法论

正如我们所见，SDLC 描述了软件开发过程的主要阶段，重点关注 为什么，但它没有定义 什么 或 如何 实现这些阶段。 方法论告诉我们在这些阶段中应该交付什么，以及如何工作 的细节。

通过考察以下两种不同的方法论，我们可以更好地理解它们各自在软件 开发项目中旨在定义的内容：

• Scrum 框架会在每 2-4 周 迭代完成 SDLC 的所有阶段，包括需求分析、规划、开发、测试、部署和维护。

• 瀑布方法论 仅按顺序一次性完成 SDLC 阶段，通常需要几个月，甚至有时 需要数年

一些主要的方法论包括以下几种，按时间顺序排列：

• 瀑布

• V 模型

• XP

• 迭代式和 增量开发

• 敏捷（Scrum）

在接下来的部分中，我们将深入了解这些框架和方法论，以及它们如何应用于低代码/无代码平台，如 Microsoft Power Platform。

瀑布

这是最古老的软件 开发过程，按顺序严格定义软件 开发阶段。 并且要求严格。

它常常因为其僵化和顺序化的方法而受到批评。 正如我们将看到的，所有后续的方法论都试图以不同的方式改进这种原始方法，但它在软件开发项目中仍然有一些优势，尤其是在编写内核驱动程序或编程关键任务应用程序（如核电厂软件）方面。 下图展示了本章前面讨论过的瀑布模型中的开发阶段：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_002.jpg

图 1.2 – 瀑布模型

这些 阶段，包括需求分析、规划和设计、开发、测试和 质量保证、部署和维护，与本章前面描述的阶段相当。 不同之处在于 这些阶段的顺序执行方式。

该模型的优点如下： 如：

• 它是 用于任务或 业务关键项目的首选方法论。

• 当 重复的 应用程序开发是必要时，它是首选。 这种情况发生在项目高度相似时，比如开发自助服务机应用或编写嵌入式软件。 在这些情况下，需求和客户期望非常明确，不预期会有任何变更。

• 项目 里程碑和截止日期已经 明确定义。

缺点 如下： 如：

• 较高的前期 设计成本

• 在 需求分析后，客户期望无法再被考虑

• 市场推出时间巨大，通常以年为单位进行衡量，并可能导致 交付过时

• 测试 直到 SDLC 的最后才开始进行 测试

尽管有上述缺点，即使在低代码/无代码平台上，我们仍然可以使用这种方法论，利用 平台提供的基础来创建我们的应用程序。

V 模型

该模型是对 之前模型的改进，以通过在 过程中引入并行活动来提高 市场推出时间 关键绩效指标 (KPI)，并通过此方式提升软件质量。

下图展示了该过程 的详细信息：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_003.jpg

图 1.3 – V 模型

一切 从将需求（领域空间）分解为可以单独实现的模块或组件开始。 V 模型期望的是模块化架构，但不一定是松散耦合的架构，其中这些组件被视为大系统设计的子系统。 低代码/无代码平台，如微软 Power 平台，提供内建的测试和验证工具，帮助开发人员确保他们的应用程序符合需求并按预期功能运行。 在低代码/无代码环境中，可以通过遵循一个结构化的开发过程来实现 V 模型，该过程包括需求分析、设计、开发、测试和部署。 过程的每个阶段都可以使用低代码/无代码平台提供的工具和功能来完成，使开发人员能够以流畅和 高效的方式构建、测试和部署他们的应用程序。

作为美国政府标准的一部分，针对美国政府机构有一个相应的 V 模型定义。 它比原始的 V 模型定义更加详细和严格，以满足美国 政府的要求。

优点如下： 如下：

• 更快的 市场推出时间，具有更高的 整体速度

• 内建 质量保证

缺点如下： 如下： 如下：

• 它仍然是一个 僵化的过程

• 需求 变化几乎 无法管理

极限编程

极限编程 (XP)作为 一种软件开发方法论，强调 通过保持高 软件质量， 来加速开发团队对客户不断变化的需求作出反应的时间——这是任何软件开发项目中预期的——

这种方法论 已经因为一些范式的转变而闻名，例如引入 结对编程 和严格的代码审查，以及追求最简架构解决方案，这些方案被称为 最小可行产品 (MVPs)。 结对编程技术意味着两个开发者一起编写相同的代码。 一个开发者编写代码，另一个实时审查每一行新代码。 两个开发者经常在这些活动（编写和审查）之间切换，但最终，他们会在 WBS 中专注于相同的活动。 MVP 是最简化的产品，可能存在技术债务和架构违例，但已经能够展示客户或实际需求方要求的特性。 MVP 用于收集来自客户或 合同合作伙伴的反馈。

MVP 的目标是测试产品的核心假设，并评估它是否具备市场适配性，即是否对客户有价值。 在 XP 中，通常的做法是保持这些 MVP 不变，不做超出预期的事情。 XP 的主要原则如下：

• 客户参与: XP 强调开发团队与 客户之间的紧密协作

• 频繁发布: XP 主张频繁发布可用的软件，即使它没有完全实现所有功能

• 结对编程: XP 鼓励开发者成对工作，一人编写代码，另一人 进行代码审查

• 测试驱动开发: XP 强调在实现业务逻辑之前先编写测试，以 确保代码符合 需求

• 持续集成: XP 鼓励频繁集成代码变更，以尽早发现集成 问题

虽然 XP 并不是专为低代码/无代码平台设计的，但 XP 的许多原则可以应用于这些平台的开发。

XP 与低代码/无代码平台

微软 Power 平台作为低代码/无代码平台的市场领导者，支持这些原则中的一些。即使是配对编程（PowerApps 画布应用程序的共同编写功能，带有基于 YAML 的代码编辑器）、画布应用的测试驱动开发以及 CI 也已完全适配到 PowerApps 中。

优点如下：

• 它促进了团队合作与协作，从而可以更有效地解决问题和做出决策。

• 它强调客户满意度，确保客户获得他们需要的产品，也就是产品完全符合他们的期望。

• 它允许灵活性和适应性，因为随着需求的变化和新要求的出现，开发过程可以随时调整。

• 它鼓励频繁的沟通和反馈，这有助于在开发过程中尽早识别并解决问题。

缺点如下：

• 最基本的架构解决方案增加了整体的技术债务。

• 在具有严格等级制度或不重视团队合作与协作的组织中实施可能会面临挑战。

• 准确估算每次迭代所需的时间和资源可能是困难的，这会使项目规划和管理更加困难。

迭代与增量开发

在软件开发中，有两个同样重要的目标：速度和质量。我们已经在之前的方法中看到质量是如何融入到流程中的。然而，质量意味着减速，因为它需要开发团队花费时间和精力，而这些本可以用来创建新的功能和需求。这就是为什么软件行业引入了速度这一概念。速度通过团队在一段时间内交付的功能（故事点）的数量来定义。这是几乎每种 SDLC 方法中的主要 KPI 之一，也是推动增量和迭代方法发展的主要驱动力之一。

迭代和增量开发 是一种软件开发方法，强调将开发过程分解为小块可管理的任务，并 在每次迭代中交付可用的软件。 这种方法提供了灵活性和适应性，因为变更和新需求可以在 它们出现时被整合到开发过程中。

低代码平台，如微软 Power Platform，可以用来支持迭代和增量开发。 这些平台提供构建模块，使得开发人员能够快速构建和部署应用程序，而无需大量编码。 这使得能够快速和迭代地交付可用软件，从而允许频繁的反馈和适应。 在使用低代码平台进行的迭代和增量开发过程中，开发人员可以处理小块、可管理的功能，并随着开发进展不断构建和部署它们。 这使得从最终用户处获得频繁反馈成为可能，并使开发人员能够根据需要整合变更和新需求。 低代码平台提供的可视化开发环境使得更改和添加新功能变得容易，从而使开发人员能够迅速适应 不断变化的需求。

优点如下： 如以下所示：

• 它使得 能够从最终用户那里获得早期反馈和验证，从而确保产品完全符合 他们的期望

• 它使开发人员能够在开发过程中随着问题的出现实时整合变更和新需求，从而提供更大的灵活性 和适应性

• 它降低了项目失败的风险，因为问题可以在 开发过程中早期识别并加以解决

• 它使得 能够快速和迭代地交付可用的软件，从而在 开发过程中早期为最终用户和利益相关者提供价值

缺点如下： 如以下所示：

• 它可能 会给准确估算每个迭代所需的时间和资源带来挑战，这可能使得项目规划和管理 变得更加困难

• 它要求团队成员之间高度的协作和沟通 。

• 由于变更和新需求不断被整合到 开发过程中， 因此很难保持项目的一致愿景和方向 。

快速应用程序开发

快速应用程序开发 （RAD）最初作为瀑布模型的替代方法开发，正如其名字所示，它关注在软件开发生命周期中追求速度和效率。 它由 James Martin 于 1991 年正式提出。 RAD 方法强调通过迭代发布和持续的客户反馈来快速开发应用程序。 通过应用敏捷方法和快速原型设计，RAD 确保了软件的可用性、对用户反馈的响应能力和及时交付。 RAD 的过程驱动特性，专注于 测试原型 和快速调整，使得在 较短的时间内交付预期产品成为可能。

低代码或无代码平台，如 Microsoft Power Platform，是 RAD 的理想工具，因为在传统软件开发中的现有构件——如软件组件和包——之上，开发人员可以轻松添加自定义功能并专注于 价值创造过程。

优点 如下：

• 缩短开发时间并提高团队效率：RAD 方法专注于快速原型设计和迭代发布，这可以显著减少 开发时间。

• 灵活性和适应性：RAD 方法允许在开发过程中进行更改，使其更加灵活，能够适应项目需求的变化。

• 更容易的风险管理：通过将开发过程拆解为更小、更易管理的模块，可以在开发初期识别并解决问题，从而降低 重大挫折的可能性。

• 更少的自定义代码和更短的测试时间：RAD 方法依赖于使用预构建的组件和代码生成工具，这可以减少所需的手动 编码量。

• 实时用户反馈：RAD 方法允许客户随时向开发人员提供反馈，因为开发迭代非常快速，并且它们 最终总是能够交付可用的软件。

缺点 如下：

• 它可能不适用于需要详细规划和设计的大型复杂项目。 RAD 依赖于软件组件的重用，这可能会限制最终产品的灵活性和定制性。 最终产品可能会受到影响。

• RAD 可能导致产品质量较低，因为专注于快速开发可能导致采取捷径和在 开发过程中做出妥协。

• RAD 可能不适用于对安全性、可靠性和性能有严格要求的项目，因为快速开发过程可能无法进行彻底的测试 和优化。

这些缺点 与定制软件开发项目相关，因为测试原型（MVP）和技术债务是硬编码进开发过程中的。 如今，RAD 工具通过公共仓库提供框架和可重用包，支持专业开发团队获得所有快速开发的优势。

RAD 的繁荣

由于企业的数字化转型需求，世界面临传统的长开发周期和软件开发人员短缺的困境，根据 IDC 的预测，到 2025 年，大约 400 万开发人员将从市场上消失。 低代码/无代码平台抓住这一机遇，为 专业开发人员提供 RAD 工具。

敏捷

敏捷 原则强调 灵活性、协作和客户满意度。 “唯一不变的是变化”， “快速测试，快速失败”， “个人和协作优于流程”，以及 “客户优先的思维方式” 是关于敏捷开发过程最常听到的短语。

RAD 与敏捷

尽管 RAD 和敏捷方法论在某些方面有相似之处，但它们在方法上有关键的不同。 RAD 优先开发原型以收集用户 反馈，而敏捷将项目划分为更小的功能，并通过一系列迭代的冲刺逐步交付这些功能 ，贯穿整个开发周期。

在软件开发生命周期中，敏捷是一种迭代方法，专注于频繁交付可用软件，并高度适应不断变化的需求。 敏捷开发团队与客户和利益相关者紧密合作，以优先考虑特性和需求。 他们使用如 CI、自动化测试和频繁发布等技术，确保软件始终处于 工作状态。

在使用低代码平台的敏捷开发过程中，开发人员可以与终端用户密切合作，收集反馈并将变更纳入开发过程中。 低代码平台提供的可视化开发环境使得更改和添加新功能变得容易，允许开发人员迅速适应 变化的需求。

优点是 如下：

• 敏捷 开发允许早期获得终端用户的反馈和验证，这有助于确保最终产品完全符合 预期

• 它使得开发人员能够在开发过程中随时加入变更和新需求，从而提供更大的灵活性 和适应性

• 它降低了项目失败的风险，因为问题和风险可以在 开发过程中 尽早被识别和解决

• 它允许快速和迭代地交付可用软件，在 开发过程中 为终端用户和利益相关者提供价值

缺点是 如下：

• 准确估计每次迭代所需的时间和资源可能具有挑战性，这会使得项目规划和管理 更加困难

• 它需要团队成员之间高度的协作和沟通，这在某些 组织文化 中可能很难实现

• 在项目中维持一致的愿景和方向可能很困难，因为变更和新需求会不断融入 开发过程

理解敏捷概念的一种方式是将其与另一种 SDLC 方法进行比较，例如 V 模型方法。 在 V 模型方法中，产品的范围是预定的，而时间和资源是可以调整的。 使用 V 方法的组织会增加程序员的数量并延长进度，以交付他们计划发布的产品。 另一方面，在敏捷方法中，产品的范围是 可以适应的，而资源和时间是固定的。 敏捷团队承诺按时交付软件，且不增加人员。 他们交付的产品是客户需求和他们在给定 时间范围内能够创造的功能的灵活组合。

敏捷、Scrum 和精益

过去几十年里，软件行业受到了其他概念、理念和看法的重大影响。 一些方法被借鉴自其他行业，例如丰田生产系统的精益管理，另一些则由软件行业的关键人物创立。 我们将简要讨论这些方法，以便了解 DevOps 和 DevSecOps 如何成为软件行业的下一个重要步骤。 软件行业。

敏捷宣言

我们已经讨论过将敏捷作为一种软件开发生命周期（SDLC）方法，因为这个总称不仅可以直接应用于软件开发阶段，还可以映射到整个软件开发组织 及其更广泛的领域。

敏捷宣言 由一群软件开发者于 2001 年创建，他们正在寻求一种更好的软件开发方式。 他们提出了四个核心价值观和十二条原则，成为了敏捷运动的基础。 这四个核心价值观和十二条原则， 自此成为敏捷运动的基础。 敏捷宣言的四个核心价值观如下：

• 个人与互动 重于过程 和工具

• 可工作的软件 重于 详尽的文档

• 客户协作 重于 合同谈判

• 应对变化 重于 遵循 计划

这些价值观和原则已被广泛采纳，帮助软件开发团队提高了软件开发过程的效能和效率。

敏捷（Agile）作为 一个总括性术语，是一个涵盖多种方法论的广泛概念，包括精益、Scrum、看板（Kanban） 等。

精益管理

精益管理由 丰田生产方式的创始人大野耐一发展，是一种通过优化资源、减少浪费（muda ，日语中意指“浪费”）和持续改进流程来为客户创造价值的方法论。 大野的目标是缩短从汽车订单到汽车交付之间的时间：

“我们所做的就是从客户下订单的那一刻起，到我们收取现金的时刻，观察整个时间线。 我们通过去除不增加价值的浪费，来缩短这一时间线。”——大野耐一

精益管理的原则包括 以下内容：

• 价值：识别 客户重视的内容，并集中精力将其交付给客户 。

• 价值流：识别产品或服务的所有步骤，并去除那些没有 创造价值的步骤 。

• 流动：确保 创造价值的步骤平稳连续地流向 客户

• 拉动：让客户需求通过价值流拉动产品或服务，而不是根据 预测推动它 。

• 完美：不断 追求改进，识别并消除流程中的浪费（追求 完美）

任何类型的组织 都可以应用这些原则和流程来提高效率，最小化成本，并提高客户满意度。 其他行业领域，如会计，也已经应用了精益原则。 软件行业采纳这一概念也并不令人惊讶，它将自己视为一个软件生产工厂，并相应地应用 这一类比。

价值流 和 价值流分析 是 最相关的领域，为任何 组织提供了一个工具，用以理解、可视化并改善其价值 创造流程。

下图展示了一个假设的软件开发组织，以及它如何响应客户请求。 交付时间 (LT) 是指从进入阶段到关闭阶段所花费的时间，而 处理时间 (PT) 是指实际工作 或活动所花费的时间：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_004.jpg

图 1.4 – 实践中的价值流分析

客户请求会经过不同的团队（如账户、业务分析、工程和运维），每个团队有不同的 LT 和 PT，直到它们到达生产环节。 这个假设的组织可以通过减少每个阶段的 LT 时间，并加快 PT 时间，来提高效率。

显然，低代码/无代码平台，如微软的 Power Platform，可以显著降低 不仅是 PT（处理时间），还包括任何应用程序开发项目的整体 LT（交付时间）。 它们通过使用预先构建的构件，如前端视觉组件、业务逻辑组件和数据访问层，来减少整体开发、测试和部署成本， 从而降低定制应用程序的开发成本。

Scrum

Scrum 是一种源自于一般敏捷原则的框架，常用于软件开发。 它是最广泛应用的敏捷方法之一。 正如我们之前讨论的，敏捷是一个总括性术语，可以在许多方面应用于软件开发生命周期（SDLC）方法、项目管理和组织。 Scrum 是敏捷的具体实现，具有自己的角色、事件、产物 和规则。

Scrum 是一种敏捷 框架，基于透明度、评估和调整的价值观运作。 它采用迭代和增量的方法，以增强可预测性并管理风险。 Scrum 团队通过简短且时间有限的迭代（称为冲刺）交付功能性软件，同时不断评估和调整其过程，以改善产品和工作流程。 下图展示了增量规划 和交付过程：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_005.jpg

图 1.5 – Scrum 过程

自主的 Scrum 团队根据客户的优先级和团队的速度决定在给定冲刺中将处理哪些待办事项。这些待办事项将从产品待办列表转移到冲刺待办列表。一个冲刺通常持续 2-4 周，并且每个冲刺结束时，Scrum 团队可以交付一个潜在可交付的产品。

Scrum框架定义了三个主要的角色：产品负责人、Scrum 主管和开发团队。产品负责人负责最大化产品的价值，并代表利益相关者（客户）。Scrum 主管负责推动和支持 Scrum，组织著名的仪式，并鼓励每个人遵守 Scrum 的规则和价值观。开发团队是一个自组织的跨职能团队，负责在每个冲刺结束时交付一个潜在可交付的产品。

Scrum 有多个仪式或事件，用于规划、回顾和改进流程。这些包括冲刺规划、每日 Scrum、冲刺回顾和冲刺回顾会。冲刺规划用于规划即将到来的冲刺的工作。每日 Scrum 是一个简短的日常会议，用于同步开发团队的工作。冲刺回顾安排在当前冲刺结束时，回顾完成的待办事项，并将未完成的项转移到下一个冲刺。冲刺回顾会安排在冲刺回顾后，讨论诸如“哪些做得好？”、“哪些可以做得更好？”以及“我们如何作为团队进行改进？”等问题。结果，团队可以发现潜在的改进点，并将其规划到下一个冲刺中。

Scrum 框架很容易应用于低代码/无代码平台，因为这些平台提供一个生态系统，确保在每个冲刺结束时交付可交付的产品（应用），并且框架定义了角色和仪式。

什么是 ALM？

有很多 关于 ALM 的书籍和文章，看看这些定义，有一点在所有定义中都是共同的：ALM 比 SDLC 更广泛，涵盖了应用程序从构思到开发 再到终止的整个生命周期。

根据定义，ALM 指的是计算机程序整个生命周期的管理，包括治理、开发、维护和终止。 它涉及广泛的活动，如需求管理、软件架构和 项目管理。

SDLC 是 ALM 的一个组成部分，提供了应用程序开发阶段的详细描述。 ALM 在应用程序生命周期中可以涉及多个 SDLC 的迭代，即在不同阶段可以应用多种方法论，如敏捷方法和 V 模型。 ALM 在开发和首次发布后继续进行，直到应用程序不再使用。 不再使用。

ALM 将多个学科和角色结合在一起。 它包括项目管理、变更管理、需求管理、软件架构、CI、开发、CD、测试、发布管理和维护。 这些学科在过去是分开管理的，组织在建立 ALM 之前，通常是高度孤立的。 内部流程优先于不同角色和部门之间的协作与沟通。 组织内部。

如今，ALM 工具为软件开发团队和相关部门（如项目管理、业务分析、测试和 IT 运维）之间的沟通与协作提供了一个标准化的平台。 这些工具还可以通过自动化简化软件开发和交付的过程。 通过自动化。

现代集成的 ALM 工具，如 Azure DevOps Services、GitHub 或 GitLab，支持 以下内容：

• 需求工程

• 项目管理 – 包括规划 和跟踪

• 错误和 问题跟踪

• 版本 控制系统

• 构建 – CI

• 自动化测试

• 发布 – CD

• 在生产环境中监控应用程序，并从使用模式、遥测日志 和故障中学习

下图展示了 ALM 的主要领域以及这些不同学科如何以 循环方式协同工作：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_006.jpg

图 1.6 – ALM 的主要领域

ALM 很容易应用于低代码/无代码平台，因为这些平台旨在作为现代应用程序运行平台，承载和执行由 专业开发人员创建的数百个甚至数千个应用程序。

在接下来的章节中，我们将学习如何结合 Microsoft Power Platform 实现 ALM 的各项规范。

CI 和 CD

CI 和 CD 是现代软件开发和 ALM 实践中广泛使用的 过程和工具。 CI 管道（工作流）用于编译源代码并使用构建代理生成二进制文件，而 CD 管道则将这些二进制文件及其配置整个解决方案部署到不同的环境，如开发、测试、 或生产环境。

CI 有时被称为 CI 构建，因为它最终在专用构建机器上执行源代码的官方编译（有时这些机器只是 Docker 容器）。 在 CI 构建过程中，还会执行单元测试；这些测试不需要协调应用程序，并且运行在毫秒级别。 CI 是确保软件质量并避免应用程序回归的最重要过程之一。 对于大型开发项目，创建 构建农场 是非常常见的， 这些构建农场由数百台构建机器组成，用于在每次 代码变更时生成交付物或包。

实践中有两个 CD 术语。 持续交付 意味着应用程序随时准备交付，但部署过程并不自动化。 持续交付的典型例子是编译代码后创建 Docker 镜像，或为生成的二进制文件创建安装程序。 持续部署 则需要一个额外的步骤，并且自动化部署过程到目标环境。 在本书中，CD 的缩写指的是后一种定义。 需要注意的是，CD 过程会将应用程序的相同版本传输到不同的环境，并在每个阶段设立质量门。 下图展示了一个典型的 CD 过程：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_007.jpg

图 1.7 – 带质量门的 CD

在 CI 过程中成功编译源代码后，生成的二进制包会通过部署流水线。 部署流水线将这些包以完全自动化的方式传递到不同的环境（开发、UAT、生产），并通过执行 自动化测试来验证和确认更改。

在 DevOps 实践高度成熟的组织中，通常会频繁进行 CD，有时一天进行几十次甚至上百次，以将解决方案的一部分直接交付到生产环境。

作为部署过程的一部分，通常会使用 CD 工作流来实施开发应用的部署策略。 有几种部署策略可以用来发布新版本的 应用程序：

• 基本部署 是最简单的 部署策略，方法是 将应用的新版本部署到生产环境中，替换掉旧版本。 这种方法直接明了，但可能会导致停机时间，并且如果出现问题，不能提供一个简单的方式回滚到之前的版本。

• 蓝绿部署 涉及拥有两个完全相同的生产环境。 一个运行着 旧版本的 应用（蓝色），另一个运行着新版本（绿色）。 一旦新版本经过测试并准备好发布，流量将逐渐从蓝色环境切换到绿色环境。 这种方法使得如果出现问题，回滚变得容易，因为流量可以简单地切换回 蓝色环境。

• 金丝雀部署 类似于蓝绿部署， 但不是一次性切换所有流量，而是最初只有一小部分流量会被导向应用的新版本。 这种方法可以在完全发布之前，使用真实用户和真实流量来测试新版本。 如果一切顺利，流量将逐步转向新版本，直到它处理所有流量。

• A/B 测试 是一种 常用于测试应用新功能或更改的部署策略。 它涉及同时运行两个版本的应用，一部分用户被引导到旧版本，另一部分用户被引导到 新版本。

• 滚动部署 是一种策略，通过这种策略，应用程序的新版本会逐步发布到生产环境。 此操作通过一次更新一部分服务器或实例来完成，而其余的服务器或实例则继续运行应用程序的旧版本。 一旦更新完成并确认正常工作，接下来的一部分服务器或实例将被更新，以此类推，直到所有服务器或实例都运行新版本的 应用程序。

现代的 ALM 工具，如 Azure DevOps Services、GitHub 或 GitLab，提供了端到端的 CI/CD 管道和工作流支持，并自动化了所有在代码提交到 Git 仓库之后的操作。

在使用 Kubernetes 编排器托管和扩展高度分布式服务的云原生微服务架构中，广泛采用所谓的 拉取 模型 将最新版本部署到生产环境中。 这种方法被称为 GitOps。诸如 ArgoCD 或 FluxCD 之类的工具运行在 Kubernetes 集群内，当监控的 Git 仓库发生变更或提交时，这些工具会在集群内部署更新，并实现零停机时间的发布。 在低代码或无代码平台中，这种方法仅部分适用于可以考虑拉取模型的场景，例如从中央仓库获取配置数据或利用 功能开关（feature flags）。

DevOps 支持的架构模式

DevOps 是我们在软件行业中看到的左移（shift-left）方法之一。 它将运维团队（ops）与开发团队（devs）紧密结合，以实现并加速持续的价值交付给我们的客户。 这意味着对人们的思维方式和文化的改变；它要求有流程和工具来将一个组织转变为 DevOps 组织。

“你构建，它就由你来运行”是描述开发和运维团队如何需要紧密合作，形成一个多元化团队，覆盖从编码到部署再到运营的端到端重复过程的最有力的名言之一。 运维成为团队的一部分。 这种左移方法提高了组织的整体生产力。 DevOps 是一个范式转变，也是一个文化上的变革，旨在提升开发和运维团队之间的协作，并提高软件生产的效率和质量。 一种复兴 Day 0 公司 心态的方法，通常被称为 创业心态，涉及定义企业客户在受监管行业中需要实施和维护的基本规则、流程和保障措施。 在大规模下保持敏捷和价值导向意味着去除所有不属于价值创造过程的浪费。 DevOps 还为企业带来了另一个好处，那就是仅维护一个版本的已开发产品：即运行在 生产环境中的版本。

此外，DevOps 期望对生产环境中的软件进行高级监控，以避免盲目操作服务。收集遥测数据、追踪和调用栈以防故障至关重要，能够了解已开发的 服务或组件是如何被使用的。 应用性能监控 (APM)工具，如 Azure 应用洞察，可以用于监控并主动发现性能下降，避免 故障发生。

DevOps团队同样强调，解决方案应该能够创建零停机部署的生产环境。 如 Kubernetes 等调度器和应用程序运行时通过设计本身支持这一方法，采用 滚动部署。

在高度成熟的 DevOps 团队中，滚动向前的概念也被广泛应用。滚动向前意味着，如果在生产部署过程中遇到问题或错误，团队会为其修复并推出该版本。 回滚到先前版本不再被考虑。

DevOps 还在软件开发行业定义了新的角色。 其中之一是 直接负责个人 （DRI）角色，这个角色 也被称为 Google 的 警长 或 Facebook 的 指定响应个人。该 DRI 负责事故管理、服务可用性和服务健康。 他们是冲刺期间的唯一联系人，既包括内部也包括外部。 如果发生高影响或中等影响的停机，他们将与客户、报纸以及其他媒体沟通。 这显著改善了整体客户体验。 另一方面，他们还在服务事故发生期间，向其他 DevOps 团队提供信息。

高度成熟的 DevOps 团队及其成员甚至可以在每个冲刺中担任不同的角色。 例如，DRI 角色在团队内每个冲刺中轮换。 这为团队成员带来了巨大的好处：经过几个冲刺后，团队中的每个人都可以在每个领域（编码、测试和操作 服务）积累专家知识。

DevOps 还假设高度自动化的流程。 在大型 IT 公司中，有一些工程团队遵循自动化一切的原则。 经验法则是：如果我们只需要做一次，我们可以手动完成，但如果需要重复做，即使只是再做一次，我们就有责任创建自动化脚本 来实现它。

任何架构都涉及到所谓的 -ilities ，它们是非功能性要求，如可审计性、可用性、兼容性、组合性、可配置性、可访问性、适应性、可承受性、可定制性、可演示性、可部署性、耐用性、可用性、可扩展性、灵活性、互操作性、可管理性、可移植性、可预测性、可恢复性、可靠性、可重复性、可重用性、可扩展性、可维护性、社会性、简易性、可测试性、可持续性、可追溯性、可复制性等。

Power Platform 和 -ilities

Power Platform 组件 被设计成这样，几乎所有这些能力都可以开箱即用。 作为 Power Platform 解决方案架构师，我们无需担心诸如审计性、可用性、可重用性等要求，因为这些都由 底层应用程序运行时作为 软件即服务 （SaaS）提供。

有两个非常重要的因素 对于 DevOps 来说：

• 可部署性 指的是 能够轻松、可靠地将应用程序的新版本部署到生产环境的能力。 生产环境

• 可测试性 指的是 系统或其组件是否能够轻松地进行测试，以确保它们符合指定要求并且 正确地运作

这两者 能力 使得开发人员能够更改代码库中的任何部分，并轻松、可靠地部署新版本。 理想的 DevOps 架构基于松耦合的服务（不一定是微服务），这些服务可以在不同的发布周期中部署到生产环境。 应用程序及其组件被设计为支持多种部署策略，例如基础部署、蓝绿部署、金丝雀部署、A/B 测试和滚动部署，正如 前面提到的那样。

下图展示了基于单体架构的部署与现代 基于微服务的方法：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_01_008.jpg

图 1.8 – 单体架构与松耦合服务和发布

在单体架构中，尽管 团队们在软件的不同部分进行工作，但发布只能是一次性进行的，包含所有服务的更改。 如果 A 团队开发的 A 服务导致发布失败，那么 B 团队和 C 团队的更改也无法到达生产环境。 另一方面，如果底层软件架构基于松耦合服务（例如，基于 OpenAPI 规范的 REST API 端点），那么不同团队开发的服务可以并行部署到生产环境中。 部署 失败的影响仅限于局部，从而减少了 爆炸半径 在生产环境中的影响。

ALM 和 DevOps

ALM 是一个更广泛的概念，涵盖了软件开发的各个方面，而 DevOps 主要关注开发与运维团队之间的协作，以提高软件开发过程的效率。 DevOps 可以视为 ALM 的一部分，因为它有助于简化软件应用程序的开发、测试和部署。

如果大型工程组织需要基于 DevOps 实践在企业规模上运行敏捷， 精益敏捷框架 （SAFe）提供了 合适的结构。

SAFe 是一个用于在企业规模实施敏捷原则的模式和实践框架。 它详细定义了角色和职责，并提供了如何通过价值创造过程在如此大规模上规划和管理工作的具体指导。 SAFe 旨在在大型团队和业务单元中实施敏捷实践，并使得能够获得这些敏捷 团队进展的组合级概览。

SAFe 基于七个核心的业务敏捷能力，这些能力包括精益敏捷领导力、团队和技术敏捷性、敏捷产品交付、企业解决方案交付、精益组合管理、组织敏捷性和持续学习文化。 这些能力旨在帮助组织实现其业务目标，并为 客户提供价值。

SAFe 还包括 一个 敏捷发布列车的概念，这是一个跨职能的敏捷团队，负责按同步节奏规划、构建和交付软件。 在这种方法中， 发布列车 负责协调应用程序新版本的部署，使用 DevOps 架构支持的部署策略。 这使得发布过程更加顺畅高效，同时确保应用程序以高质量和高可靠性持续交付给用户。 SAFe 可以通过定制我们的工作项跟踪体验来支持功能、史诗、发布列车以及 多个待办事项列表，在 Azure DevOps 服务中的 Azure Boards 上实现。

总结

在本章中，我们探索了软件行业中最重要的突破，深入研究了各种 SDLC 方法论、敏捷宣言、精益管理、Scrum 框架、ALM 和 DevOps 实践。 我们了解了定义现代应用程序开发和架构的模式和实践。 这些技能和经验是软件开发的基础，且是每位工程师必须掌握的核心概念。

正如我们所总结的，现代应用程序开发遵循 DevOps 原则，利用 ALM 工具和学科来最大化价值。 现代应用程序架构基于松耦合服务或微服务，并支持两个关键模式：可部署性 和可测试性。

在接下来的章节中，我们将探索如何将这些现代应用程序开发模式和实践应用于 Microsoft Power Platform，以及如何为 Power Platform 实施 DevOps 和 ALM。

进一步阅读

• Geoffrey Elliott (2004). 全球商业信息技术：一种集成系统方法。 皮尔森 教育*😗 https://www.amazon.com/Global-Business-Information-Technology-integrated/dp/0321270126

• Everatt, G.D.; McLeod, R Jr (2007). “第二章: 软件开发生命周期”。 软件测试：跨整个软件开发生命周期的测试。 约翰·威利与 儿子公司*😗 [https://dahlan.unimal.ac.id/files/ebooks/2007%20[McLeod_R.]_Software_Testing_Testing_Across_the_E.pdf](https://tinyurl.com/uw2r7c8r)

• V-Model： 美国交通部，联邦公路管理局。 系统工程手册 ITS: https://www.fhwa.dot.gov/cadiv/segb/index.cfm

• Power Apps RAD： https://powerapps.microsoft.com/zh-cn/rapid-application-development-rad/

• ALM: DAVID CHAPPELL (2008): 什么是应用程序生命周期管理？: https://aws.amazon.com/what-is/application-lifecycle-management/

• 精益管理： 大野耐一：丰田生产方式 系统： https://www.amazon.com/Toyota-Production-System-Beyond-Large-Scale/dp/0915299143

• DevOps： https://learn.microsoft.com/en-us/devops/what-is-devops

• 麦肯锡公司*：通过开发者速度推动商业成果* 2020： https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance#/

• DRI 角色： https://www.microsoft.com/insidetrack/blog/rotating-devops-role-improves-engineering-service-quality/

• SAFe: https://scaledagileframework.com/agile-release-train/

第二章：开始使用 Microsoft Power Platform

Microsoft Power Platform，作为多年来被公认为领先的企业低代码应用平台，是一种帮助组织实现业务流程数字化的技术。 在本章节中，我们将为你提供 Microsoft Power Platform 的概述，并帮助你理解为什么每位专业软件开发人员或业务用户都应该掌握这项低代码/无代码 应用平台的技能。

我们将探索 Microsoft Power Platform 家族中的各种产品，例如 Power Automate、Power Pages 和 Copilot Studio。 熟悉 Microsoft Power Platform 家族成员将帮助你更好地理解如何挑选和选择合适的服务来简化你的工作流程。 我们将创建我们的第一个试用环境，以测试 Power Platform 的功能。 然后，我们将进入 Power Platform 管理，讨论 Microsoft Power Platform 遵循的标准和合规性规定，并以使用 Power Apps 和 Power Automate 的一些常见真实世界商业解决方案的解释作为结束。

在本章节中，我们将讨论以下 主要内容：

• 低代码/无代码的崛起 低代码/无代码的崛起

• 开始使用 Microsoft Power Platform 服务

• Power Platform 管理

• 治理、合规性和 数据隐私

• 开始构建真实世界的 商业解决方案

技术要求

本章节不要求任何特定的技术前提。 我们将介绍 Microsoft Power Platform 服务和管理配置选项，你可以通过使用带有现代浏览器并连接互联网的工作站来跟随学习。

在本章节中，我们将使用一组试用的 Microsoft Power Platform 许可证，以便创建一个 Power Platform 环境，之后你可以继续使用它来测试 Microsoft Power Platform 服务。

如果你已经拥有自己的 Microsoft Power Platform 环境，可以随时使用它来跟随本章节的内容，更重要的是，之后的章节会有更多动手练习，你可以继续使用它。 我们建议为本书中的工作创建一个单独的 Power Platform 环境。

低代码/无代码的崛起

在本 节中，我们将探讨 低代码/无代码 (LCNC) 开发的概念，并探索为什么市场上对采用这种方法及其相关工具的需求日益增加。 通过这样做，我们将深入了解这种应用开发方法的意义以及它在 未来的发展方向。

LCNC 是一种应用开发方法，允许开发者在较短时间内以较少或无需编写代码的方式创建软件应用，并借助 软件即服务 (SaaS) 平台，抽象化了与扩展、数据管理等相关的复杂性。 尽管我们经常看到 LCNC 作为一个完整的术语，但 LC 和 NC 之间还是存在一些区别。

LC 开发方法仍然要求应用开发者至少具备基本的软件开发知识，因为某些部分的应用可能仍然需要使用代码来支持业务逻辑或某些功能。 这使得我们能够构建比 NC 应用程序更为复杂和精密的软件应用。

在今天的 人工智能 (AI) 和 AI 助手（例如微软的 Copilots），它们通过仅使用自然语言指令帮助我们提高工具使用效率，我们也可以通过仅提供自然语言提示，从中获得完整的代码。 这缩小了 LC 和 NC 开发方法之间的差距。 然而，这些 AI 助手之所以被称为 Copilot，是有原因的，因为用户仍然需要理解收到的建议，以验证其是否会执行所指示的操作。 本书的最后一章将介绍微软的 Copilots，特别是适用于 Power Platform 服务的 Copilots，这将帮助我们进一步了解如何从中受益。

NC 开发方法专注于使用可视化工具，通过拖放功能直观地构建应用程序，允许进行简单的定制，如属性和配置。 使用这种方法意味着我们的定制性会更受限制；相反，我们不需要任何软件开发的先验知识。 这使得几乎任何组织中的人都可以成为应用程序开发者。 NC 方法还可以用于快速原型开发应用程序，之后将其交给具有 LC 经验的专业开发者或应用程序开发者，进一步扩展应用程序的 复杂逻辑。

许多平台，包括 Microsoft Power Platform，结合了这两种开发方法，从而使组织能够根据项目/应用程序和 可用资源选择合适的方法。

LCNC 应用程序开发方法并不是什么新鲜事物。 LCNC 开发平台可以追溯到 20 世纪 80 年代。 Microsoft Excel、第四代编程语言以及快速应用程序开发工具在 Microsoft Power Platform 的发展中都发挥了重要作用。 第四代编程语言 (4GLs)实际上是专门为那些不一定是软件开发者的人设计的，因为与其他编程语言相比，编程语言更简化，操作时需要的命令更少。 编程语言。

尽管市场上有许多工具可以使用户使用 NC 方法构建他们的应用程序和网站，但微软工具如 Microsoft Excel、Access 以及其他商务生产力工具的丰富历史，在我们今天所知的 LCNC 开发平台的创建中，起到了重要作用。 它们今天的面貌。

LCNC 开发方法背后的理念是为非开发者、业务分析师和业务用户提供一个平台，他们可以利用已有的知识来使用该平台。 由于许多用户已经知道如何使用像 Microsoft Excel、Microsoft Word 和 Microsoft PowerPoint 这样的微软工具，他们可以轻松学习如何使用 Microsoft Power Platform，它就像是这些产品的组合。 这使得任何人都能更快地创建业务应用程序，无需或仅需少量编写代码。 有趣的是，甚至代码编写部分也遵循相同的模式，并与 Microsoft Excel 中的公式编写经验相匹配，这进一步强化了微软工具之间连接体验的理论。 Microsoft 工具。

LCNC 开发的当前状态与未来趋势

随着工作节奏的加快 以及不断推动数字化运营的需求，许多公司寻求在更短的时间内做更多的事情，借助的工具不仅可以被传统的软件开发人员使用，还能被其他员工使用。 任何有决心开发新应用、数字化并优化业务流程的人，都可以成为应用开发者，构建支持业务运营的应用程序、自动化工作流和聊天机器人。 “每个人都可以成为开发者”这一理念推动了 LCNC 工具的普及。 然而，我们看到这些工具普及的背后，还有其他一些原因。 这些工具的普及有着更多的推动力。

在过去五年中，全球范围内对 LC 开发平台的兴趣显著增加。 推动这一增长并促使各组织加速数字化转型的最大里程碑无疑是 COVID-19 大流行。 在全球大流行期间，各组织急于寻找快速适应市场变化并数字化其运营的方式。 这需要更快地开发业务应用程序，从而 增加了对熟练专业开发人员的需求。 然而，结果是，这导致了市场上专业开发人员的短缺。

根据 2022 年美国劳工统计局的预测，在未来 10 年内，应用开发和质量保证测试需求将增长 25%，这一增速远高于所有职业的平均水平，正如他们报告中所提到的。 公司现在可以通过招聘 LC 开发人员或培训其业务用户成为 应用开发者 来弥补专业开发人员的短缺。

根据 Gartner 的预测，LC 开发技术市场将进一步增长。 根据 2022 年的市场研究，预计到 2024 年，LC 应用平台将成为 LC 开发技术市场的最大组成部分，收入将接近 123 亿美元。 LC 应用平台预计将在 2024 年达到接近 123 亿美元的收入。 收入将继续增长。

在我们讨论 LC 开发工具时，你可能会认为这只涉及软件应用程序开发领域；然而，我们不应忽视对超自动化的日益关注。 这是一个涵盖多种技术的领域，包括 机器人过程自动化 (RPA) 和 数字过程自动化 (DPA)，这些技术帮助组织 应对其 业务操作数字化的巨大需求。

同样，AI 助手，如 Microsoft Copilot，可以帮助提高 LCNC 工具的采用率。 仅凭自然语言，应用开发者就可以将他们的想法转化为完全 功能性的应用程序。

理解 LCNC 的好处

LCNC 开发 方法为组织提供了多个好处。 其中一个最大好处是，几乎任何人都可以成为应用开发者，无论他们的开发技能如何，这有助于弥合专业开发者的差距。 那些没有软件开发经验、且偏好可视化开发体验的人可以利用 NC 方法，而那些具有一定软件开发技能或编写公式经验的人可以从 LC 方法中受益，在这种方法中，应用开发者可以专注于特定业务应用的业务逻辑，而非专注于软件应用程序的底层源代码。 软件应用程序。

这种开发方法能够帮助组织节省时间和成本，使他们能够以更少的资源、更快速和更轻松的方式构建定制的软件应用程序，同时其应用程序由 SaaS 平台提供支持，该平台提供安全性、可扩展性、治理和 数据管理。

最后，我们不能忽视这样一个事实，即 LCNC 开发工具提供了与第一方和第三方工具的极好集成可能性，这使得软件应用程序的开发速度更快，不同系统、应用程序 和服务之间实现集成。

开始使用 Microsoft Power Platform 服务

本节将介绍 Microsoft Power Platform 及其基本组成部分。 我们将解释这些工具如何帮助用户创建业务应用程序、自动化流程，甚至获取数据洞察。 我们还将解释如何创建自己的 Power Platform 试用帐户，以创建一个可用于测试平台功能的环境，并帮助你跟随以下章节。

什么是 Microsoft Power Platform？

Microsoft 的 LCNC 开发方法不限于单一工具；相反，它提供了一个用户 工具套件 ，涵盖不同的重点领域， 允许用户单独使用或结合使用这些工具，构建端到端的 业务解决方案。

Microsoft Power Platform 包括五个 主要产品：

• Power Apps

• Power Automate

• Copilot Studio

• Power Pages

• Power BI

这些服务都通过一个可扩展的基于云的数据存储系统连接，称为 Microsoft Dataverse。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_1.jpg

图 2.1 – Power Platform 的五大主要产品和支持服务

拥有多样化的 LCNC 产品组合使用户能够以灵活且模块化的方式构建业务解决方案。 这些工具不仅与其他 Microsoft 产品本地集成，还使用户能够更 高效地构建解决方案。

通过此功能，用户还可以灵活地仅为所使用的产品购买许可证，因为 Microsoft Power Platform 的服务是单独授权的。 许可证可以是独立的，例如 Power Apps Premium 许可证，也可以与 其他许可证一起包含。

作为一个包含许可的示例，一些微软产品（例如 Microsoft 365 或 Dynamics 365）使你可以使用选定的微软 Power Platform 服务的有限功能。此类封装许可类型被称为**“种子许可”**。例如，Microsoft 365 E3 或 E5 的许可证包括 Power Apps 和 Power Automate 的有限功能集。要启用 Power Apps 和 Power Automate 的所有 Premium 功能，需购买并使用单独的 Premium 许可证。通常，这些许可证使用按用户订阅的模式；不过，也有其他变体。

重要提示

尽管本书不会深入讨论许可细节，但我们鼓励大家浏览微软网站上提供的各种许可模型，因为微软 Power Platform 的许可会定期更新，这使得它成为一个高度动态的话题。管理员和 DevOps 工程师应将定期检查变更作为其职责的重要组成部分。保持信息更新有助于在 Power Platform 生态系统中确保有效的管理和合规性。

有关 Power Platform 功能和定价的更多信息，请参阅 Power Platform 许可指南，您可以在以下文档页面访问：learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus。

2016 年 10 月，微软发布了普遍可用的 Power Apps 和 Flow（现称为 Power Automate），今天，我们拥有一个非常成熟的平台，连续五年被 Gartner 评为“企业 LC 应用平台”领域的领导者，在 Gartner Magic Quadrant TM 中名列前茅。

虽然该平台主要面向市民开发者，但它使你能够构建集成场景，并且具有可扩展性，甚至适用于专业开发者（例如，通过在 Azure API 管理中发布的自定义 API 构建自定义连接器，使用 Power Apps 组件框架开发代码控件，以及使用AI Builder发布自定义模型）。

接下来，让我们来看看微软 Power Platform 的家庭成员。

Power Apps

Power Apps 是一款 允许用户创建和运行定制业务应用程序的产品。 应用程序可以通过使用 Visual Maker Studio 和拖放功能，无需大量编码就能快速开发。 专业开发者和应用程序开发者可以创建连接到各种数据源，并通过连接器与许多现有应用程序和服务集成的应用程序。 应用程序可以作为画布应用程序开发，重点是设计和定制界面，或者作为模型驱动的应用程序开发，重点是数据模型。 画布应用程序的一个有趣方面是，这种类型的应用程序可以打包成原生的移动应用程序包，类似于定制的 Android 和 iOS 应用程序。 然后，这些应用程序可以通过 Google Play 商店、Apple Business Manager、Microsoft Intune 和 Microsoft App Center 分发给移动终端用户。

Power Automate

Power Automate 是一款 基于云的工作流服务，帮助客户解决超自动化问题。 它不仅限于构建自动化简单的日常重复任务的工作流，还可以自动化跨各种服务和系统的复杂业务流程。 如果你已经使用 应用程序接口 (API)来访问一些后台服务，那么 数字化流程自动化 (DPA)可以通过 Power Automate 来实现。 如果你想要 自动化在桌面应用程序中执行的重复任务，或者通过 RPA 构建网页自动化，Power Automate 可以为你提供 支持。

Copilot Studio

Copilot Studio 是一个 构建独立助手的平台。 它基于 Power Virtual Agents 平台构建，该平台用于构建智能虚拟助手和聊天机器人。 Copilot Studio 使我们能够通过构建控制对话流程或使其更具动态性的主题来创建自定义助手，借助 大型语言模型 (LLMs)，例如 GPT。 自定义助手帮助用户执行任务或回答问题。 它们可以通过连接器和插件与组织数据相连接，组织数据作为知识库，通过后端系统来解决复杂任务。 助手可以通过不同的渠道发布，如网站、自定义的移动/网页应用程序，或任何其他用于通信的服务，如 Facebook、Slack、 或 Twilio。

Power Pages

Power Pages 是一个 企业级、可扩展且安全的基于云的服务，用于构建丰富且数据驱动的网站。 它广泛依赖于 Dataverse 来存储配置和数据，这些数据会在网站上展示。 尽管它是 Power Platform 家族中最年轻的成员之一，但 Power Pages 在发展成今天所知的产品过程中，经历了相当长的历程。 它始于微软收购 Adxstudio Inc.，然后变成了 Power Apps Portals，而今天，我们 拥有了 Power Pages。 它的核心保持不变——一个允许用户创建、托管和管理现代且具有视觉吸引力的网站的平台，以数据为 核心。

Power BI

而 Power Platform 家族中的其他产品旨在自动化业务流程和构建业务应用程序，Power BI 是一套工具，使我们能够深入了解数据并构建智能报告，帮助我们快速提取数据中的关键信息。 仪表板和报告可以遵循与业务应用开发相同的 LCNC 方法进行构建。 通过使用拖放体验，我们可以连接各种数据源，构建表示 提取数据的图表和方块。

Power Platform 的扩展生态系统

除了这五个核心产品外，Power Platform 产品还由其他服务和功能支持，如 Dataverse、Power Fx、连接器、Copilots 和 AI Builder。 Power Platform 中的 Copilots 和 AI Builder 将在本书的最后一章深入讲解，但我们将在 这一章讨论其余内容。

Dataverse

Dataverse 是一个 安全且可扩展的云数据存储，广泛应用于 Dynamics 365 和 Power Platform。 它允许我们创建将被业务应用程序使用的新表，并对其应用严格的安全模型和治理策略，如权限、基于列的安全性和审计能力。 它还允许我们在 Dataverse 中创建视图和表单，随后可以在数据模型上快速构建应用程序。 Dataverse 还允许我们构建定义数据生命周期流转和适用业务规则的业务流程流。 这些规则适用于表格。

Power Fx

Power Fx 是一个 通用的 LC 语言，广泛应用于 Microsoft Power Platform。 最初在 Power Apps 中出现的 Power Fx，现在已扩展到其他 Power Platform 服务，为构建公式提供了统一的体验。 Power Fx 被用于在业务解决方案中构建自定义逻辑。 凭借类似电子表格的公式和与 Microsoft Excel 的相似性，它促进了快速的采用。 Power Fx 是开源的，这 使得它具有更高的透明度并且 支持社区协作。

连接器

连接器 在 Microsoft Power Platform 生态系统中发挥着至关重要的作用。 它们充当 Power Platform 与外部服务或数据源之间的集成桥梁。 每个连接器都有一组自己的触发器和操作。 从许可角度来看，它们被分为标准连接器和高级连接器，但从技术角度来看，它们被分为预构建连接器（连接到第一方或第三方服务）和自定义连接器。 我们将在 后续章节中深入探讨连接器。

设置我们的第一个环境

现在我们对 Power Platform 家族中的产品有了更好的了解，接下来我们来创建一个环境，用于测试 这些服务。

如前一部分简要提到的，Power Platform 产品是单独授权的，因此在创建试用环境时需要特别注意。 我们建议首先创建一个 Microsoft 365 E3 或 E5 试用环境。 这 将使我们能够测试与 Microsoft 365 或 Office 365 服务的集成功能——例如，在 Power Automate 中创建一个工作流，使用 Office 365 中的 Outlook 发送电子邮件。 另外，可以使用 OneDrive for Business/SharePoint Online 文档库来存储和管理一些 Excel 文件，然后这些文件在 Power Apps 中使用，数据通过表单 和图库进行可视化展示。

获取 Microsoft 365 E3 或 E5 试用账户

通过搜索 Microsoft 365 (M365) 网站上的 可用计划和 定价，我们可以找到多个带有一个月免费试用的 M365 计划。 此类计划的示例如下： https://www.microsoft.com/en-us/microsoft-365/enterprise/office-365-e3。由于链接可能会发生变化，我们建议浏览 M365 网站上的可选项，并在 立即购买 按钮下，会有一个 免费试用 选项，可以启用免费试用。 然后，向导会引导我们完成试用许可证的配置过程。 首先，我们需要 提供我们的电子邮件地址和 登录 信息。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_2.jpg

图 2.2 – 一个 Microsoft 365 E3 试用账户

请记住，我们可能需要添加信用卡，仅用于验证。 我们建议在租户中至少保持添加的支付方式，直到完成所有所需试用许可证的配置，因为 Power Platform 许可证也需要支付方式进行验证。 一旦我们完成了将选择的试用许可证添加到租户，或者我们想要移除支付方式以避免任何可能的许可证延期和相关费用时，我们可以在 Microsoft 365 管理中心 (https://admin.microsoft.com) 使用全局管理员帐户移除支付方式。 如果我们后来决定 继续使用此试用帐户并将其转换为更长期的测试环境或生产环境，我们可以向帐户中添加支付方式，并继续在 此租户中运行服务。

我们可以通过登录到 Microsoft 365 管理中心，进入 帐单 | 支付方式 部分，添加新支付方式，或者选择现有的支付方式并 将其移除。

现在我们已经创建了一个 Microsoft 365/Office 365 租户，接下来让我们将 Power Platform 产品添加到 租户中。

Power Platform 试用许可证

由于 Power Platform 产品 是单独授权的，因此每个我们即将测试的产品都需要单独获得试用许可证。 不过，如果我们打算将大部分时间投入到 Power Apps 和 Power Automate 中，另有一种选择——Power Apps 开发者计划。 让我们仔细看看 这两种选择。

单独的产品试用许可证

在 Microsoft 365 管理中心停留，前往 帐单 | 购买服务 并寻找你想要添加的 Power Platform 产品许可证。 它们中的大多数都有可以添加到租户的免费试用。 我们可以使用右侧的搜索功能 购买服务 部分来更快速地找到产品，例如 Power Automate Premium，如下所示的 截图所示。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_3.jpg

图 2.3 – 购买服务

接下来，点击所选产品许可证的 详细信息 按钮，这将打开一个 产品详情 页面。 如果所选产品允许添加试用许可证，则会在 开始免费试用 选项旁边显示 购买 按钮。 选择后，您将开始将许可证添加到租户的过程。 如果您在前一步中已将信用卡作为 Microsoft 365 租户的支付方式，您将能够通过点击 立即试用 按钮在 结账 屏幕上添加试用许可证。 我们可以采用相同的方法将任何其他 Power Platform 产品添加到 租户中。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_4.jpg

图 2.4 – 确认试用许可证的订单

试用许可证通常以 25 个用户许可证为一组，非常适合在业务用户和开发人员之间进行内部分发，以测试产品功能。 试用许可证的有效期为 30 天。 试用许可证到期后，我们可以购买所需的计划以继续使用 该产品。

某些产品也 附带附加组件，例如 Power Automate 无人值守 RPA 附加组件。 这些附加组件通常依赖于独立许可证，通常称为合格的基础许可证。 一旦我们为租户添加了所需的合格基础许可证，例如 Power Automate Premium 试用版，就可以添加选择的附加组件——在这种情况下，是 Power Automate 无人值守 RPA 附加组件试用版。 我们可以在 计费 | 购买服务 部分搜索附加组件，正如我们之前所做的，或者在 附加组件 部分找到它们，位于 产品详情 屏幕中，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_5.jpg

图 2.5 – 添加附加组件试用许可证

Power Apps 开发者计划

Power Apps 开发者计划 是一个免费的开发环境，可用于开发和测试业务应用程序。 它允许您使用 Power Apps 和 Power Automate 的高级功能，包括高级连接器和 Dataverse。 任何拥有 Microsoft 工作或学校帐户并连接到 Microsoft Entra ID 的用户，都可以注册此开发者计划。 我们可以通过以下网站获取 Power Apps 开发者计划 ： https://powerapps.microsoft.com/en-us/developerplan/。如果开发者拥有 Visual Studio 订阅，则可以在 Visual Studio 订阅的 Dev Essentials 网站上激活 Power Apps 开发者计划 （https://my.visualstudio.com/benefits）：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_6.jpg

图 2.6 – 通过 Visual Studio 订阅启用 Power Apps 开发者计划

每个用户最多可以拥有 三个 Power Platform 租户中的开发环境。 开发者环境可以由管理员为用户创建，也可以由用户自行创建；但是，管理员也可以阻止用户创建此类环境 的可能性。

与期限为 30 天的试用许可证相比，Power Apps 开发者计划不会过期，并且只要该计划有任何活动，就会保持有效。 如果超过 90 天没有活动，计划将被删除。 另一个重要说明是，试用许可证带来了付费许可证的所有功能，而 Power Apps 开发者计划则不包含所有功能/能力。 此外，开发者环境不能转换为生产环境，尽管试用环境可以转换为生产环境。 开发者环境在 Dataverse 容量上也有限制，最大数据库大小为 2 GB。

开发者计划是一个完美的选择，可以在独立的开发环境中测试和构建 Power Platform 中的业务解决方案。 一旦我们对解决方案感到满意，就可以遵循 持续集成/持续部署 (CI/CD) 管道 将解决方案部署到测试和 生产环境中。

Power Platform 管理

本节探讨了 Power Platform 管理员可以使用哪些工具来配置 Power Platform 环境、管理 Power Platform 产品功能，以及如何了解不同环境中 Power Platform 产品的使用情况。 不同的环境。

除了 Microsoft 365 管理中心，管理员还应该知道另一个管理中心，帮助他们管理 Power Platform 租户。

Power Platform 管理中心 是一个统一平台，用于与 Power Platform 相关的管理任务。 它可以通过 https://admin.powerplatform.microsoft.com/ 访问，并允许管理员执行与 Power Platform 相关的大多数操作，例如一般环境管理、产品功能管理，以及获取关于 产品使用情况的分析洞察。

重要说明

需要注意 Power BI 有一个单独的管理中心，叫做 Power BI 管理中心（可通过 https://app.powerbi.com/admin-portal）访问，允许 Power BI 管理员管理其 Power BI 实例。 Power BI 管理中心不在 本书的讨论范围内。

Power Platform 为管理员提供了三种交互和管理方式——通过 Power Platform 管理中心、PowerShell cmdlet 和连接器——Power Platform 管理员和 Power Platform 开发者。

Power Platform 管理中心

熟悉 Microsoft 365 管理中心的用户会发现这个管理中心相似且易于使用。 使用 Power Platform 管理中心，管理员可以管理环境、查看关键指标和使用情况、理解并采取有关许可证和容量利用的措施等等。 这些控制项被整齐地分组，放置在管理中心左侧的导航菜单栏中，提供简洁的 用户体验。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_7.jpg

图 2.7 – Power Platform 管理中心

一个常被忽视的功能是 帮助 + 支持 功能，允许管理员在需要 Microsoft 支持时提交支持请求。 在这里，管理员还可以查看之前提交的支持请求、其状态以及 沟通历史。

在 帮助 + 支持 中有一个方便的功能，名为 已知问题，该功能通知管理员有关 Dynamics 365 和 Power Platform 产品当前已知的活动问题。 它解释了每个已知问题，并提供了一个解决方法。 这是一个方便的方式，可以主动向管理员告知平台已知问题的状态。 除此之外，还有 Power Platform 的服务健康状况。 有关此信息可以在 Power Platform 管理中心的主页上找到，在那里我们可以找到一个 服务健康 仪表板，包含关于 Power Platform 服务的任何事件或通知的信息。

消息中心 提供有关之前和即将进行的服务更新的信息，说明它们可能如何影响用户，以及如何做好准备以尽量减少潜在影响。 有关服务健康和即将进行的计划变更的更多信息，可以在 Microsoft 365 管理中心找到。

Power Platform 管理中心还为管理员提供了设置各种 策略的可能性，从 数据丢失防护 （DLP）策略 到 计费策略。

租户设置可以通过进入 Power Platform 管理中心 | 设置来访问。这些是适用于整个 Power Platform 组织的租户级设置。 在这里，您可以配置诸如租户级分析、未分配的 AI Builder 信用使用情况和环境分配等设置。 我们将在本书后续章节中详细介绍这些设置，当我们探讨 IT 团队与 DevOps 原则对齐的重要性时。 了解哪些租户级设置可用非常重要，因为它们对用户体验有很大影响。 IT 管理员应当检查这些设置，理解它们，并为 他们的组织进行正确配置。

在 租户级别的设置旁边，我们有环境设置，可以通过访问 Power Platform 管理中心 | 环境 | 选择一个环境 | 设置来访问。 设置 按钮会在选择环境后出现在上方工具集选项中。 此 设置 部分为您提供环境设置的访问权限，包括从 产品 和 功能 配置到 审计和日志 管理，适用于所选环境：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_8.jpg

图 2.8 – 访问环境设置

功能 配置允许我们启用或禁用 Power Platform 中通常可用的功能或预览功能。 例如，随着生成性人工智能的引入，Copilot 和其他与 AI 相关的功能现在可以提供给 Power Platform 用户，但前提是这些功能在 功能 配置中已启用。 一些新功能默认启用，管理员可以在此处禁用它们。 我们建议访问 消息中心 （可以在 Power Platform 管理中心的主页上找到），阅读微软 Power Platform 博客上的文章，或者查看 Dynamics 365 和 Microsoft Power Platform 发布计划，以 了解 Microsoft 中的新版本和即将发布的功能 Power Platform：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_9.jpg

图 2.9 – 环境设置

Power Platform 管理和自动化，适用于管理员、开发者和开发人员

从管理员中心的图形用户界面切换到 命令行界面 （CLI），我们可以看到 Power Platform 提供了一套命令工具，用于自动化管理任务。 根据我们是否来自负责管理环境的 IT 运维团队，是否是需要管理应用的应用开发者，或者是旨在打包解决方案并自动化业务解决方案部署的专业开发者，每个人都会使用不同的 CLI 工具。

开发人员的 Power Platform CLI

Power Platform CLI (PAC CLI) 是管理 Power Platform 的首选和最推荐的 CLI 工具。 它面向开发者和管理员，提供一套命令，支持与解决方案打包、环境生命周期、代码组件、Dataverse 环境等相关的各种操作。 管理员将会发现许多便捷的命令，可以简化管理任务。 PAC CLI 支持内环和外环开发，这意味着在内环开发中，开发人员使用该 CLI 来处理解决方案，而在外环中，开发人员使用 CLI 工具确保所生产的解决方案能够部署到 其他环境中，遵循 应用生命周期管理 (ALM) 策略。

Power Platform CLI 的安装可以在 Windows、macOS 和 Linux 设备上进行。 可以通过 一个 .MSI 安装包进行安装。

首先，针对 VS， Power Platform 工具 可以 在 VS Code 内的 扩展 部分找到，或者在 VS Code 的 市场中找到。你可以在 VS Code 内使用搜索框查找该扩展，然后点击 安装 按钮进行安装。 市场也可以采用类似的方法。 请访问 https://marketplace.visualstudio.com/vscode 进入 VS Code 市场，使用搜索框查找 Power Platform 工具 扩展，然后点击 安装。该扩展由微软发布（我们可以看到已验证的发布者标记），并且是免费的。 安装完成后，VS Code 将激活该扩展，并在主侧边栏中显示。 卸载扩展在 VS Code 中进行，方法与安装类似，只需点击 卸载 按钮：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_10.jpg

图 2.10 – VS Code 的扩展

接下来，我们还可以使用 PAC CLI，通过 使用 .NET 工具 (dotnet 工具)。 在这种情况下，工作站上需要安装 .NET（目前推荐使用 .NET 6.0 版本）。 然后可以在终端或命令提示符下使用以下命令进行安装：

 dotnet tool install --global Microsoft.PowerApps.CLI.Tool

同样的方法适用于 macOS 和 Linux。

命令目前分为 23 个组。 每个组都有其特定的用途，例如 pac admin 用于操作 Power Platform 管理员帐户， pac data 用于操作 Dataverse 组织， pac pcf 用于操作 Power Apps 组件框架项目， pac connector 用于连接器。

在我们开始使用这些命令之前，我们需要在计划运行命令的工作站上创建一个身份验证配置文件。 可以使用 pac auth create 命令创建身份验证配置文件，系统会打开一个提示框 用于输入凭证：

 # more specific auth profile creation with environment infopac auth create --environment xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --name DevInitialAuth

为了列出选定设备上的所有身份验证配置文件，我们可以运行 以下命令：

 pac auth list

这将返回关于工作站上所有身份验证配置文件的信息。 我们可以通过提供授权配置文件的索引或名称，在它们之间来回切换： 授权配置文件：

 pac auth select --name DevInitialAuth

现在我们已经有了身份验证配置文件，可以运行 pac 命令来执行所需的任务。 为了了解 PAC CLI 中有哪些可用的命令，我们可以运行 以下命令：

 pac help

为了获得某个特定命令的详细帮助，我们只需在每个命令后添加 help 即可： 我们想要使用的每个命令：

 pac admin helppac admin list help

命令中的帮助开关 返回一个使用示例，非常方便，特别是当我们第一次运行命令时。 以下是一个 admin 命令的示例，用于列出我们在连接的 Power Platform 组织中的所有沙盒类型环境。

 pac admin list –-type Sandbox

在接下来的章节中，我们还将使用 PAC CLI，并提供更多具体的示例。

管理员使用的 PowerShell

在PAC CLI旁边，我们有适用于管理员的 PowerShell 命令，模块名称为Microsoft.PowerApps.Administration.PowerShell，它允许我们执行一系列操作来管理 Power Platform 租户、环境以及 Power Apps 和 Power Automate 产品。

管理员的 PowerShell 模块可以通过以管理员身份运行 PowerShell 并安装必要的模块来进行安装，使用以下命令。 作为前提条件，我们应使用 Windows PowerShell 版本 5.x，并且在安装过程中，设备上应已安装 NuGet 提供程序。 如果 NuGet 提供程序尚未安装，安装过程会要求我们先安装它，然后再继续安装 PowerShell 管理员模块。 使用 PowerShell 命令的管理员需要具备以下角色之一才能操作 PowerShell cmdlet – Power Platform Administrator、Dynamics 365 Service Administrator 和 Microsoft Entra ID Global Administrator：

 Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

另外，如果我们没有管理员权限，可以将作用域设置为当前用户， 针对选定设备：

 Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser

我们可能会被要求更改InstallationPolicy，确认从不受信任的存储库安装，并然后继续。

更新模块可以通过以下命令完成：

 Update-Module -Name \"Microsoft.PowerApps.Administration.PowerShell\"

一旦 cmdlets 安装完成，并且在我们开始执行管理 Power Platform 的命令之前，我们需要获取一个授权令牌，该令牌将与我们执行的 Power Platform PowerShell 命令相关联。 要获取令牌，我们需要调用Add-PowerAppsAccount，该命令将提供一种交互式方式，通过我们的管理员帐户登录。 如果我们的帐户 受到 USGov 或 Preview保护，我们应向 Add-PowerAppsAccount 命令添加 -Endpoint 参数，并指定 所需的端点：

 $password = ConvertTo-SecureString \"securePassword\" -AsPlainText -ForceAdd-PowerAppsAccount -Username adminuser@domain.com -Password $password

一旦我们提供了凭证并获得了授权令牌，就可以继续运行管理员命令。 如果我们需要支持来查看可用的命令以及如何使用它们，我们可以使用一个简单的命令，Get-Help，后面跟上 cmdlet 名称，如下所示：

 Get-Help Get-AdminPowerApp -Detailed

Get-Help将下载模块的最新帮助文件，并为我们提供反馈。

重要提示

查找任务的正确命令及如何编写命令的示例，可以通过Get-Help来完成。然而，随着技术的发展，借助生成式 AI，我们现在可以更快地获得命令的答案和支持。现在，我们可以通过自然语言向像 Microsoft Copilot 这样的工具寻求帮助，完成某项任务。

所有管理员可用命令的列表可以在这里找到。

PowerShell 用于应用程序开发者

应用程序开发者有自己的模块，可以让他们管理 Power Apps 应用、Power Automate 流程，以及在流、应用和连接器之间定义的连接器和权限。

安装过程与管理员模块相同——通过以管理员身份运行 PowerShell 或定义-Scope为CurrentUser。首先，我们需要安装该模块：

 Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber

我们可能会被要求更改InstallationPolicy。确认从不受信的存储库安装并继续。

管理员的处理流程与之前相同——在运行任何命令之前，我们需要获取一个授权令牌。此操作通过Add-PowerAppsAccount命令完成，支持交互式身份验证模式；它还可以与 MFA 支持的帐户一起使用：

 Update-Module -Name \"Microsoft.PowerApps.PowerShell\"

所有可用的制造商命令列表可以在这里找到。

管理员和管理连接器

最后但同样重要的是，使用管理员和管理连接器的选项，它们在 Power Platform 中与其他 1,000 多个可用连接器一起随时可用。

连接器被分为五个不同的组：

• Power Platform for Admins：使 管理员能够管理环境生命周期，管理 DLP 策略，并在 指定环境中创建 Dataverse 数据库。

• Power Apps for Admins：使 管理员能够查看和设置跨 Power App 应用程序、连接器，以及连接的各种权限和所有者。

• Power Apps for Makers：允许 应用程序开发者发布他们的应用程序，并查看和管理他们的应用程序、连接器，以及连接。

• Power Automate for Admins：使 管理员能够管理 Power Automate 流程状态，通过停止、运行或删除 流程。

• Power Automate Management：允许 应用程序开发者查看和编辑他们在特定环境中有权限的流程。 此连接器还包含一些特定于管理员的操作，可以用来修改流程所有者或恢复 已删除的流程。

所有这些连接器都是标准类型的连接器，并且可以在所有地区的 Power Apps 和 Power Automate 中使用。 Power Platform for Admins 版本 2 (V2) 在公共预览中可用，您可以在 Azure Logic Apps 中使用相同的连接器。 目前它还不完全与 V1 兼容，但连接器会随着时间的推移不断更新，因此我们可以预期，在某个时刻，V2 会替代 V1。 通过使用连接器中可用的操作，管理员可以自动化重复的管理任务。 例如，管理员可以使用 Power Automate 创建自动化工作流，自动化创建 Power Platform 环境的过程，同时获得 Power Automate 产品的所有好处，比如能够查看流程 运行历史的输出。

治理、合规性和数据隐私

本节介绍了 Microsoft Power Platform 如何符合许多法规和标准，以及它如何为客户提供一套工具，以使其应用程序符合所需的法规。 它解释了 Microsoft Power Platform 如何遵循与其他 Microsoft 产品和服务相同的方法，保持合规，并遵循 Microsoft 对 客户的承诺。

微软承诺对其客户透明，展示用于确保客户数据在微软产品线中安全、合规和隐私保护的政策、操作实践和技术。 微软声明数据仍由客户掌控，并且对数据存储的位置保持透明。 微软还解释了数据在静态存储时如何保护，以及如何在传输过程中进行加密，并且最终通过其服务和部门来保护客户数据。 这样的承诺非常大胆，并为客户提供了信任感。 这些声明支持微软的 云服务 ，这些服务建立在四个基本原则之上： 安全性、隐私与控制、合规性和透明度。 安全性 专注于保护客户免受外部网络威胁。 隐私与控制 使客户能够控制对其数据的访问。 合规性 确保微软的服务符合全球标准。 透明度则是为客户提供政策和程序的洞察。

即使微软为其客户提供了所有承诺，我们仍然需要理解，云部署遵循共享责任模型。 这意味着， 根据组织使用的云服务模型类型，无论是 基础设施即服务（ IaaS ）、平台即服务（ PaaS ）还是 SaaS，不同的责任层次分别由云服务提供商和其客户承担。

Power Platform 是一个企业级 SaaS 平台，这意味着管理物理数据中心、物理网络、主机、操作系统和网络控制是微软的责任领域。 然而，客户使用的 Power Platform 产品属于共享责任模型。 在共享责任模型下，组织必须记住，它们有责任确保其最终产品的安全性，并遵守相关的法规。 需要遵守的规定。

共享责任模型的一个好例子是微软如何持续监控威胁态势，并以一种保护 Power Platform 免受 OWASP 前十名风险的方式构建 Power Platform。 OWASP 前十名 是针对有兴趣了解 web 应用安全的开发人员的标准意识文档。 微软在 Power Platform 中实施控制措施来防范这些风险，同时也为客户提供了可以在 Power Platform 或支持的服务中使用的指导和控制措施，如 Entra ID，以进一步保护他们的 Power Platform 应用免受威胁，例如破坏性访问控制、加密失败和 安全配置错误。

治理和合规性也与数据驻留领域相关。 让我们来看看微软如何处理 客户数据。

数据驻留

与其他微软服务一样，Power 平台服务托管在微软遍布全球的数据中心，并通过微软的网络基础设施进行连接，以减少网络延迟并确保数据传输的安全性。 Power Platform 客户可以在全球不同地理位置（区域）创建环境，从而将服务和数据更靠近最终用户。 这种方式对拥有全球分支机构的公司非常便利。 世界各地的公司都可以受益。

客户可以在全球各地的数据中心区域创建环境，如美国、欧洲、亚洲、澳大利亚、阿联酋、英国、日本、法国、 和瑞士。

有时，环境的位置在 Power Platform 中某些产品功能的可用性方面可能起到重要作用。 尽管功能会逐步在所有数据中心位置启用，但评估拥有一个备用测试环境的选项以验证 预览功能始终是明智之举。

对于在 以下地区运营的组织 而言， 欧盟 （EU），Power Platform 支持 欧盟数据边界 （EU Data Boundary），这是一个地理上定义的边界，帮助客户满足其数据驻留要求，将 数据驻留限制在仅限欧盟和 欧洲自由贸易协会 （EFTA）国家。

实践中数据驻留要求的一个好例子是 生成性人工智能 （GenAI）功能 在 Microsoft Power Platform 中的应用。 Power Platform 利用 Azure OpenAI 服务来实现其 GenAI 功能，但也可能发生 Azure OpenAI 服务并不位于与 Power Platform 托管的相同数据中心区域。 组织可以选择允许或禁止数据在区域之间的流动。 这意味着，如果特定功能在某个环境区域没有启用，通过允许数据流动，数据可能会流向启用了某项服务的区域。

观察托管在欧洲地区的环境，一旦启用数据移动功能，并使用 GenAI 能力，数据交易可以转移到瑞典或瑞士地区，这些地区已启用相应的服务。 这两个国家都位于欧盟数据边界内。 其他国家/地区可能有其他与 GenAI 功能相关的地理区域对。

与欧盟一起，另一项保护个人及其数据的法规是通用数据保护条例 （GDPR）。GDPR 为那些向欧盟居民提供商品和服务或收集并分析欧盟居民数据的组织引入了新规则，无论您或您的企业位于何处。 Microsoft Power Platform 为组织提供了一组服务和 功能，这些服务和功能可在接收到 数据主体权利 （DSR）请求后使用。 DSR 请求 是数据主体（个人）向数据控制者（提供服务的组织）提出的正式请求，要求数据控制者处理存储在其系统中的个人数据。 数据主体有权要求删除其数据，限制数据的处理，获取其在数据控制者系统中的数据副本等。 这意味着 Power Platform 必须为管理员提供基于 DSR 请求的能力，以查找并处理数据。

在 Power Apps 中，管理员可以使用 Power Platform 管理中心或上一节中的 CLI 命令集来查找并导出用户的数据。 例如，在 Power Apps 中，这些数据可能包括用户有权使用的应用列表、用户创建的环境、用户创建的连接或作为共享连接使用的连接，等等。

重要提示

关于欧盟数据边界和 GDPR 以及如何使用 Power Platform 中的功能响应 DSR 请求，还有很多内容可以写，我们在这里无法详细讨论。 要了解更多信息，我们建议访问 Microsoft Trust Center（https://www.microsoft.com/en-us/trust-center/product-overview），以及在 Microsoft Docs 中响应 DSR 请求（https://learn.microsoft.com/en-us/power-platform/admin/powerapps-privacy-dsr-guide）。

合规性要求

公司必须满足其商业解决方案的监管合规标准。 这就是为什么微软确保其产品和服务符合许多全球、地区、行业或美国政府特定的合规性规定。 因此，Power Platform 和其他微软在线服务实施了一个安全框架，遵循行业最佳实践，并遵守各种全球 标准，例如 国际标准化组织（ISO） 的标准，如 ISO 27000 系列标准（ISO 27001，ISO 27017，ISO 27018 等）和 系统和组织控制（SOC） ，例如 SOC 1 和 2；行业特定的 标准，如 HIPAA 和 PCI-DSS；或者与特定国家或地区相关的区域性标准，如适用于欧盟的 GDPR。

Power Platform 和其他微软在线服务会定期接受合格的第三方认证评估员的审计，以确保符合全球标准 和规定。

除了全球标准和法规外，微软通过其产品条款，之前发布了一份单独的文档，名为**《在线服务条款》**（OST），该文档解释了微软对客户的合同承诺，涵盖了使用微软产品的不同方面，包括关于客户数据处理和安全的隐私与安全条款及其他数据类型的条款。

任何人都可以使用微软信任中心，了解微软的产品及其如何遵循不同的安全、隐私和合规性标准及法规。

使用微软服务信任门户，客户可以调查与数据安全和合规性相关的各种文档，例如针对特定标准或法规的合规证明，或其他文档，如审核检查或对 Power Platform 产品的渗透测试。

数据保护

微软 Power Platform 具备安全策略和流程，帮助保护客户数据免受损坏、泄露和丢失的风险。这包括帮助保护客户数据免受数据泄露和数据丢失事件的机制。微软在多个层面应用安全机制并保护数据，从数据中心的物理安全到网络安全，保护静态数据和传输中的数据，并允许客户设置嵌入产品中的额外安全控制，从而进一步提升安全级别。

在微软在线服务的核心部分，包括 Power Platform 服务中，租户隔离至关重要，这就是为什么微软采取了帮助正确隔离租户的机制。微软 Entra ID 在此过程中发挥了重要作用，帮助隔离客户的租户。一旦用户完成身份验证，他们只能访问自己租户环境内的数据。

然后，用户许可证验证也随之而来。用户可以使用他们已获得许可证的 Power Platform 产品和组件。没有许可证，用户将无法访问并操作服务。

Power Platform 产品的数据存储的主要服务是 Microsoft Dataverse。 作为 Power Platform 产品的中央数据存储平台，Microsoft Dataverse 拥有三个不同的存储区域。 第一个是存储 数据，第二个是存储 日志，第三个是存储 文件。Dataverse 实现了数据静态加密和传输加密机制。 对于静态数据，Dataverse 数据库使用 SQL 透明数据加密 (TDE) 进行 在读/写操作期间对数据进行实时加密和解密。 此机制作为数据和日志文件的数据静态加密机制。 为了存储图像和文档等文件，Dataverse 在后台使用 Azure Blob 存储。 为了保护这些二进制数据，Azure 存储加密与 Azure Blob 存储一起使用。 这是一种自动加密/解密机制，采用 256 位 AES 加密。 这两种解决方案（SQL TDE 和 Azure 存储加密）都符合 FIPS 140-2 标准。

对于数据加密，使用的是 由微软管理的密钥，密钥由微软存储和管理。 那些希望获得更多数据保护控制或需要满足特定法规或合规要求的客户 可以使用 客户管理的加密密钥 (CMK) 功能。 这使得客户可以提供自己的加密密钥，该密钥由 他们的 硬件安全模块 (HSM) 生成并管理，并且该模块必须是 Azure 密钥保管库提供的受支持 HSM 之一。 另外，他们还可以使用 Azure 密钥保管库来生成和管理 加密密钥。

传输中的数据通过 行业标准传输协议进行保护，其中之一是 传输层安全协议 (TLS)。 为了加密客户端与服务器之间的消息，并确保符合安全策略以建立安全连接，使用最新的 TLS 1.2 协议，并结合一组称为加密套件的密码算法。 数据在用户客户端设备与服务之间、在 Microsoft 数据中心之间的通信中，以及在 Microsoft 数据中心内部，即使在使用 Microsoft 网络骨干时，也得到保护。 这样可以确保数据免受拦截，并确保 事务的完整性。

在用户身份验证并检查其许可证后，Power Platform 实现了一系列控制措施，这些控制措施可以进一步保护在应用程序或流程中使用的应用、数据或连接。 这些控制措施的例子包括共享应用程序、在 Dataverse 中使用安全角色来限制用户对其数据操作的访问，以及使用连接凭据来确定对 给定服务的访问权限。

我们将在 第十一章中更深入地讨论一些关于治理和安全的控制措施。

开始构建现实世界的业务解决方案

本节演示了 Power Platform 提供的一些选项和模板思路，帮助你快速入门，构建现实世界的业务解决方案。 我们将查看 Power Platform 产品中有哪些模板可用，以及有哪些其他选项可以从之前生成的设计或通过 自然语言描述的想法开始构建应用程序。

使用 Power Platform 模板创建解决方案

我们将从 模板开始。 Power Platform 产品，如 Power Apps、Power Pages、Power Automate 和 Copilot Studio，都提供了预定义的模板，帮助我们启动一个想法或业务流程。 Power Apps 拥有一份广泛的预构建应用模板列表，可以作为起点使用。 这些模板可以被采用，并对其进行额外的自定义。 在这里，我们可以找到支持业务场景的应用模板，如预定房间、提交费用报告、提交休假申请、通过帮助台助手将最终用户与支持专家连接，以及通过预算跟踪器保持项目预算。 这些都作为快速创建业务应用程序的方式。 应用模板可以通过访问 Power Apps 制作门户主页上的 从应用模板开始 来找到（https://make.powerapps.com/）。 使用这种方法有助于应用开发者快速开始构建应用程序。 由于所有这些模板都使用数据源来存储应用程序中使用的数据，一个非常重要的步骤是设置正确的数据源，并将其与应用程序正确连接。 然后，改变应用程序的图形外观可能是应用开发者的下一步操作——应用符合公司徽标和图形设计外观的图形。 图形设计。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_11.jpg

图 2.11 – 使用应用模板创建应用程序

应用 模板还 提供了一种便捷的方式来学习如何构建 这样的应用程序，配置控件，构建业务逻辑，并在应用程序内连接和集成不同的组件。 应用程序。

类似的方法可以在 Power Automate、Power Pages 和 Copilot Studio 中找到。 在 Power Automate 中，你可以找到一组预定义的工作流，它们可以作为构建工作流的起点。 在 Power Pages 中，提供了包括网站图形设计和布局的布局模板。 拥有 Dynamics 365 许可证的用户可能会看到额外的 Dynamics 365 模板，其中包括客户自助服务、合作伙伴门户、员工自助服务和社区模板等示例。 在 Copilot Studio 中，我们可以找到构建 自定义助手的模板。

无论你选择哪个模板，都有很大概率需要实现与数据源的连接，因为许多应用程序会使用并存储数据用于 它们的操作。

企业模板

那些希望从更高级 模板入手的用户，应选择企业模板。 微软推出了一套免费的六个企业模板供使用。 企业模板可以在 Microsoft AppSource 上找到，并附有 Microsoft Learn 平台的文档，您可以在这里阅读更多关于每个模板场景的内容 以及如何实现 它（https://learn.microsoft.com/en-us/power-platform/enterprise-templates/overview）。

企业模板涵盖了六种案例，从员工认可计划、入职伙伴、奖励与认可等人力资源案例，到 IT 案例，如硬件请求和预约 预定流程。

与上一节中提到的模板一样，企业模板的目的是减少在组织中围绕某些案例构建应用所需的时间。 我们还可以使用它们来学习如何利用 Power 平台服务开发特定场景。

这些模板中的每一个都包含两个应用程序；一个是画布 应用程序 ，面向最终用户。 它是一个富含 UI 的应用程序，具有响应式布局或适配移动设备，因此也可以随时使用。 第二个应用程序是模型驱动 的，面向管理员。 它是一个数据密集型 应用程序，管理员可以在其中对数据进行管理操作，或者后台团队可以管理数据源中的所有条目。

应用程序也使用 Dataverse 作为数据源，其中创建并使用一个或多个表来 存储数据。

最重要的是，还会生成 Power Automate 流，根据 项目执行某些业务操作。

这是 Power Apps 中非常常见的应用开发方式，整个过程由 Power Automate 支持，同时数据保留在 Dataverse 中，安全角色可以应用于进一步保护数据访问 。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_12.jpg

图 2.12 – 使用 Microsoft AppSource 获取企业模板

你可以通过访问 Microsoft AppSource，选择所需的模板，并点击 立即获取。首先，我们会被要求使用账户登录，并在继续安装前确认权限详情。 之后，我们将被重定向到 Power Platform 管理中心 | 资源 | Dynamics 365 应用，在这里我们选择要安装该模板的环境。 接受条款后，我们可以安装应用程序。 当我们想要更新或移除已部署的应用程序时，可以返回到 Power Platform 管理中心，选择环境，然后点击 Dynamics 365 应用 进行 操作：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_13.jpg

图 2.13 – 安装企业模板

Power Platform 模式

Power Platform 项目 开发包括项目规划、设计、开发、测试和部署等阶段。 由于 Power Platform 项目的开发遵循敏捷方法论，它是一个迭代和可重复的过程。 这种方法意味着，一旦我们部署了解决方案，就可以轻松地回到项目开发的初始阶段，在那里我们设计和开发应用程序的新版本。 在接下来的章节中，我们将看看如何遵循我们的业务应用程序和解决方案的 ALM；然而，值得一提的是，许多基于 Power Platform 构建的项目遵循类似的模式。 这些模式包括审批、资产管理和检查应用程序。 微软将它们整合在一起，并创建了一个列出所有已识别 Power Platform 模式的清单，包括每种模式的模板解决方案及其安装文档。

这些模式 与模板可以在 此处找到： https://learn.microsoft.com/en-us/power-apps/guidance/patterns/overview。

每种模式都有其独特的目的；然而，从技术角度来看，它们通常由一个或多个 Power Apps 应用程序、中央数据存储（例如 Dataverse、SQL 数据库或 SharePoint Online）以及支持业务流程的 Power Automate 流程组成。 某些模式还包括 Power Pages，用于用户前端体验，而不是 Power Apps 应用程序。

构建业务解决方案的其他方式

让我们来看几种不同的方式来构建一个 业务解决方案。

从对话中创建

Power Platform 使你能够通过与 Copilot for Power Platform 的自然语言对话来创建业务解决方案。 Copilot 可在所有产品的主页上使用，例如 Power Apps、Power Automate、Power Pages 和 Copilot Studio。

描述我们想要创建的应用程序类型非常简单，AI 会尝试理解我们描述的上下文，并帮助我们构建应用程序。 它不仅帮助我们创建应用程序，还能帮助我们设计应用程序将使用的数据表模式。 将使用的数据表模式。

在 第十二章中，我们将深入探讨 Copilot for Power Platform 及其功能。 深入了解。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_14.jpg

图 2.14 – 从对话中创建应用程序

从设计（图像或 Figma）创建

了解用户如何与数据交互有助于我们构建应用程序的概念设计。 概念设计帮助我们确定应用程序中将执行哪些任务。 这使我们能够绘制一个简单的画布应用程序屏幕或 Power Pages 表单的表示。 在画布应用程序中，Power Apps 允许我们将纸上绘制的应用程序屏幕草图转换为应用程序或表单。 这个 Power Apps 功能将我们的草图转换为功能性屏幕，并从草图中识别出组件。 我们还可以使用 Figma 和 Figma 中的画布应用程序 功能。

Figma 是一个 用于界面设计的协作网页应用程序。 它允许每个人创建应用程序的用户界面和原型。 Microsoft Power Platform 提供了一个 Figma UI 套件，允许我们直接从 Figma 创建 Power Apps 应用程序 ：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_02_15.jpg

图 2.15 – 从图片或 Figma UI Kit 创建画布应用

客户故事

微软在他们的 Power Apps 客户案例网站（https://powerapps.microsoft.com/en-us/blog/power-platform-stories/）上有一 个汇总的真实客户故事列表，任何人都可以阅读，了解客户面临的挑战以及他们如何通过构建解决方案来解决问题，使用的正是微软 Power Platform。

2020 年，微软宣称 97% 的《财富》500 强公司以多种方式使用微软 Power Platform。 毫无疑问，我们可以看到该平台的受欢迎程度正在不断攀升，这也是我们相信越来越多的真实世界案例将被记录并与更广泛的社区分享的原因，从而让人们从中学习并应用这些案例来解决他们 自己的挑战。

尽管并非所有客户故事都对外公开，但公开的那些给我们提供了宝贵的洞察，了解客户为何决定使用这项技术，我们也可以了解到他们是如何 实施解决方案的。

摘要

本章介绍了 LCNC 开发方法的兴起以及它在近年来获得的关注。 我们希望本章能帮助你理解为何意识到这种开发方法如此重要，它的好处是什么，以及它与经典软件 开发方法的区别。

我们简要介绍了 Power Platform 的主要组件，并重点讲解了如何开设试用账户。 这应该有助于你了解如何开始使用该平台，因为接下来的章节将专注于实践活动，而准备一个测试环境以便 跟随操作是非常重要的。

接下来，我们介绍了管理 Power Platform 的工具，从管理中心到不同的 CLI 工具，PAC CLI 是首选工具，还有各种连接器可以帮助自动化管理任务。 无论你是 IT 管理员、DevOps 工程师还是专业开发人员，都很有可能在开发或管理 解决方案时，使用一个或多个这些工具与 Power Platform 配合。

本章节的最后两个部分专注于理解如何保持平台的安全性和符合不同标准及法规的要求，以及如何利用 Microsoft 公共网站发布的各种模板和模式。 这将帮助你建立对平台的信任，并加速你的初始项目设置，使用现有的模板（至少是前几个 项目）。

在下一章节，我们将运用 Power Platform 的知识，探讨为什么 ALM 和 DevOps 对 Power Platform 项目至关重要。 我们还将深入了解 Power Platform 采用成熟度模型，以及它如何帮助组织评估当前的成熟度水平并改善 DevOps 过程。

进一步阅读

• Microsoft Power Platform 博客： https://www.microsoft.com/en-us/power-platform/blog/

• Dynamics 365 和 Power Platform 发布 计划： https://releaseplans.microsoft.com/en-US/

• Power Platform 管理员 文档： https://learn.microsoft.com/en-us/power-platform/admin/

• Power Platform CLI： https://learn.microsoft.com/en-us/power-platform/developer/cli/introduction

• PowerShell 支持管理员和 开发者： https://learn.microsoft.com/en-us/power-platform/admin/powerapps-powershell

• 管理员和管理 连接器： https://learn.microsoft.com/en-us/connectors/powerplatformforadmins/

• Microsoft 信任 中心： https://www.microsoft.com/en-US/trust-center

• Microsoft 产品 条款： https://www.microsoft.com/licensing/docs/view/Product-Terms

• Microsoft 企业 模板： https://learn.microsoft.com/en-us/power-platform/enterprise-templates/

• Power Apps 模式： https://learn.microsoft.com/zh-cn/power-apps/guidance/patterns/overview

• Power Platform 故事： https://powerapps.microsoft.com/zh-cn/blog/power-platform-stories/

第三章：探索 Microsoft Power Platform 中的 ALM 和 DevOps

Microsoft Power Platform 使用户能够以更简单、更快捷的方式创建业务应用程序，这对于任何人来说都是具有吸引力的，无论其开发技能如何。 一旦我们超越了个人生产力应用程序的创建，并开始自动化具体的业务流程，我们就需要开始规划如何为这些新构建的应用程序设置最佳的生命周期模型，以便在 组织中进行管理。

客户案例帮助我们理解，一旦组织采用了 Power Platform，组织中生产的应用程序数量很可能会大幅增加。 组织应该有一个计划，来处理如何构建、部署、管理和维护这些应用程序。 这就是 应用生命周期 管理 (ALM) 的作用所在。 然而，这不仅仅是关于开发人员的事情。 IT 专业人员和安全工程师必须与开发人员沟通，确保他们参与到规划、创建、管理和监控应用程序运行环境的过程当中。 这就是为什么 将 ALM 与 DevOps 结合扩展对于 低代码/无代码 (LCNC) 开发方法来说也非常重要。

在本章中，我们将继续在前几章的基础上，解释为什么 LCNC 项目应该使用 ALM 和 DevOps，以提高整体协作和质量保证。 在探索 ALM 如何帮助我们构建应用程序后，我们将深入探讨应用现代化的话题，因为组织通常有许多现有的遗留应用程序，这些应用程序应该进行评估并决定其未来。 本章的最后，我们将了解 Power Platform 采用成熟度模型如何与 ALM/DevOps 和应用现代化相关联，以及为什么提高组织的成熟度水平至关重要。 在组织中。

在本章中，我们将涵盖以下 主要主题：

• 为什么在 Power Platform 中实施 ALM 和 DevOps？

• 通过 LCNC 方法进行应用现代化

• 构建 Power Platform 采用之旅

为什么在 Power Platform 中实施 ALM 和 DevOps？

本节 探讨了为什么像微软 Power Platform 这样的 LCNC 平台需要实施 ALM 流程，以及它将如何改善团队协作、提高质量保证并帮助减轻 潜在风险。

在采纳的初期阶段，我们可以看到组织将 Power Platform 服务提供给 他们的 公民开发者。公民开发者是指在组织内部不具备传统编程技能的个人或员工，他们通常来自业务部门，而非 IT 或开发团队。 他们使用 Power Platform 主要为自己构建业务应用程序，以提升个人生产力，并且不对 使用方式施加严格的指导。

随着组织的成熟，对 Power Platform 的认识和知识逐渐增加，开始构建更复杂的项目时，他们会寻求可扩展、一致、稳定且安全的构建和维护业务应用程序的方法。 这与理解 ALM 的重要性直接相关，ALM 为如何共同治理、开发和维护应用程序提供了实践。 采用 ALM 方法来构建应用程序可以对开发速度、可靠性和最终 用户体验产生积极影响。

在谈到 开发速度时，我们需要提到 ALM 提供了一个框架，旨在使用允许多个贡献者同时在应用程序上进行工作的平台。 这时版本控制工具就显得尤为重要。 由于如今许多工具，如 Azure DevOps 和 GitHub，提供了一个单一平台来覆盖 ALM/DevOps 生命周期，我们可以通过实施自动化构建、测试和部署管道，利用 CI/CD 流水线提高开发速度。 然而，我们也可以通过改进开发方式来提高交付时间。 构建可重用的代码组件可以让我们在不同项目中复用这些构建块，从而节省开发时间。 在可靠性方面，由于我们已经建立了版本控制系统，我们有可能将系统回滚到之前的版本，因为在开发过程中错误是难以避免的。 拥有这一能力可以增加我们维持系统稳定性的选择。 前面提到的 CI/CD 流水线将帮助我们确保应用程序在不同环境中持续部署，从而最大限度地减少配置漂移和 意外行为。

最后，拥有一个 无 bug 的应用程序在塑造用户体验中起着重要作用。 实施持续自动化测试将帮助我们在流程早期发现潜在问题。 通过自动化测试，我们还可以查看潜在的性能瓶颈。 这有助于我们去除或优化这些问题，从而提高性能，并最终改善 用户体验。

每当我们在考虑 Power Platform 中的应用生命周期管理时，我们会集中关注两个主要概念： 解决方案 和 环境。我们在项目中开发的所有内容，作为业务解决方案的一部分，无论是画布应用、流程、Dataverse 表格还是自定义组件，都作为一个 解决方案组件呈现。这些解决方案组件被添加到一个解决方案中，并且我们应用 ALM 过程，使得能够自动化地将解决方案导出和导入到不同的环境中。 环境充当一个容器，隔离我们租户中的内容，并允许目标受众的分离。 解决方案和环境这两个概念可能对于 IT 专业人士、专业开发人员和 DevOps 工程师来说是非常熟悉的。 这是因为在传统的软件开发中，也使用类似的方法，其中应用程序被打包成一个包（在 Power Platform 的上下文中是解决方案），并部署到不同的目标环境中，如开发环境、测试环境、预生产环境和 生产环境。

解决方案和环境的概念将在 第四章中详细描述。Power Platform 中的 ALM 只是故事的一部分。 许多人认为 ALM 仅仅是将解决方案部署到不同环境的过程，但实际情况远不止于此。 我们应该将其与 DevOps 结合，并考虑实施额外的步骤，例如构建环境管理策略、自动将 Power Platform 资源打包成解决方案、保障和管理环境，以及最后，在确保所生成的工作经过适当测试的情况下，一致地自动部署到不同环境。 Power Platform 上的 DevOps 不仅关注应用开发者和专业开发者，还着眼于帮助 IT 管理员构建强大的平台和 IT 运营（IT ops）流程，这些流程使我们能够自动化平台特定任务，如环境配置、平台管理、DLP 政策管理、审计等。 许多时候，商业应用扩展超出了 Power Platform，因此 IT 运营团队还需要负责网络管理，例如在配置 Power Platform 与 Azure 服务或其他本地后端系统的集成时。 后端系统。

正如在 第一章中提到的，ALM 是一个将软件开发多个阶段以循环方式连接起来的软件开发过程。 现在，让我们从一个更高的视角来看看这些阶段在 Power Platform 中的意义。

计划和跟踪

我们在开始开发项目之前，需要做的第一件事是进行充分的项目准备和规划， 我们可以通过进行一个 需求研讨会 流程来实现。 这有助于我们理解项目的目标和范围。 它让我们开始为这个阶段构建成果。 这个步骤需要提出有效的验证问题，帮助我们理解目标和项目范围。 理解项目范围有助于我们了解可用的时间表和资源，包括预算。 它还让我们可以进行可行性研究，以确定是否存在一些我们应当注意的重要障碍。 一旦我们理解了项目的范围，就可以继续收集所有的功能需求并优先排序。 然后使用 四象限法：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_03_1.jpg

图 3.1 – 四象限法

接下来，我们将 识别与所选项目相关的所有团队成员，并为他们分配 各自的角色。 指定的敏捷方法论，如 Scrum，已经有预定义的角色及其相应的任务，当我们将角色分配给团队成员时，可以参考这些方法论。 这将帮助我们在项目规划工具中将团队成员分配到定义好的任务和用户故事中。 使用所选的项目规划工具，我们将把工作项类型与我们将在项目中使用的方法论对齐，并开始创建工作项，如用户故事和任务，并根据项目进度和责任人进行映射。 团队成员。

从项目规划的角度来看，这也是一个我们应当定义和构建环境设计、定义数据战略并开始进行数据建模的阶段。 在这里，我们正在进行项目架构设计。 安全团队还应该开始进行威胁建模，以识别潜在威胁，并通过调整架构设计（无论是物理的还是逻辑的）来减轻这些威胁。 最后，为了解决用户体验部分和功能请求，我们可以从应用程序故事板或线框图开始。 或线框图。

如我们所见，在 ALM 的第一阶段，我们甚至可能还没有接触到 Power Platform 服务。 相反，我们将专注于与项目规划相关的活动。 我们可以通过 项目规划工具来支持这个阶段，比如 Azure Boards （Azure DevOps），它内置了项目规划功能。 它允许我们通过工作项定义项目，并随着时间的推移计划和跟踪已完成的工作。 时间进展时。

在这里，我们还将决定我们的战略，这将影响下一阶段——我们的分支策略。 我们还将决定是使用单一仓库还是 多仓库方法。

开发

开发阶段是应用开发人员和专业开发者合作，按所使用的方法论和项目计划中的一系列冲刺实现已定义任务和用户故事的阶段。 根据项目的不同，在这一阶段我们将使用 Power Platform 服务来开发我们的业务应用程序、流程、定制协助工具和网站。 为了支持这一阶段，我们将启用并将项目与版本控制系统连接。 版本控制系统通过保存代码的快照来保护开发团队，让他们能够恢复到之前的版本。 它还通过为开发人员提供一种简单的方式来识别并系统地解决代码冲突，保护他们免受可能出现的并行开发冲突。 这种系统的一个例子是 Azure Repos，它是 Azure DevOps 的一部分，或者是 GitHub 仓库。

即使我们已经从规划和跟踪阶段转向开发阶段，但这一阶段以及生命周期中所有后续阶段仍然依赖于第一阶段，因为我们将继续使用选定的项目规划工具，如 Azure Boards。 这些工具将帮助我们跟踪工作项的状态并相应地更新它们。 我们还使用 Azure Boards 与其他项目成员合作，通过交换想法和评论来共同处理工作项。 工作项。

开发 任务是在 Power Platform 服务和 集成开发环境 (IDEs) 中完成的， 例如 Visual Studio Code。

作为 Power Platform 服务中协作的一个例子，我们可以提到 Power Apps 支持在模型驱动应用中进行协同创作，并且即将在画布应用中支持这一功能，这使得多个开发者能够同时在应用中进行更改，并且他们的更改实时反映给其他人。 然而，并不是所有服务目前都支持相同程度的协同创作体验；因此，为了缓解代码优先开发者与公民开发者之间的协作挑战，微软推出了 Power Platform Tools 扩展，这在 前一章中已提到。

与 DevOps 一样，我们努力自动化手动任务。 在这一阶段，我们将开始构建 CI/CD 流水线，帮助我们自动化构建、测试和部署过程，这将在 DevOps 的下一个阶段中完成。 自动化的 CI/CD 流水线是在 DevOps 工具中构建的，并配备有 Power Platform 中自动化任务的工具。 这些工具的例子包括 Power Platform Build Tools、 Power Platform CLI (PAC CLI)， PowerShell cmdlets。

构建和测试

一旦 必要的功能已开发完毕或问题已解决，且开发人员准备好进入下一个阶段，他们需要启动一系列任务，将完成的工作构建并打包成一个准备好部署到 目标环境的解决方案。

DevOps 中的最佳实践之一是 尽可能地实现自动化。 在 持续集成 (CI) 流水线中，我们定义了构建和测试解决方案所需的任务。 对于此任务，我们可以使用 CI/CD 工具，例如 Azure DevOps，它本身内置了 Azure Pipelines 功能。 或者，我们可以使用 GitHub Actions，它是 GitHub 产品的一部分。

每当工作提交到代码库时，CI 流水线可以自动触发。 这减少了启动过程时对人工干预的需求。 该过程由系统自动开始。

在我们的 CI 流水线中，我们已经放置了一系列使用 Power Platform Build Tools 或 PAC CLI 来执行 必要操作的任务。

我们不能不提测试。 在继续到下一个阶段之前，应该在这里进行一组适当的测试。 Azure DevOps Pipelines 或 GitHub Actions 使我们能够在 CI 流水线期间自动运行测试。 例如，使用管理员和开发人员的 Solution Checker 或 PowerShell cmdlets，特别是 Microsoft.PowerApps.Checker.PowerShell 模块，我们可以将解决方案检查器功能集成到 CI 流水线中。 这种方法允许开发人员在构建验证过程中实施静态分析检查，并在开发过程中识别出问题模式。 从这里开始，我们可以使用 Power Platform 中的其他测试工具，如 Power App Test Studio 或 Power Apps Test Engine，来构建 Power Apps 中的端到端测试。

作为 此阶段的结果，使用我们提到的工具，我们已经生成了一个构建工件。 工件是构建过程的副产品，在 Power Platform 的背景下，它将是一个打包的解决方案，其中包含已添加到解决方案中的所有组件。 这将在接下来的 部署阶段中使用。

部署

既然我们 在前一个阶段的结果中有了一个工件，我们可以专注于将其部署到必要的环境，并在那里运行额外的测试，如集成、性能、安全和 UI 测试。 与 前一个阶段一样，持续部署 (CD)**旨在自动将解决方案部署到各种环境，包括生产环境。 通过使用 DevOps 工具和 CD 流水线，再加上 Power Platform 构建工具，我们可以确保部署过程 得到自动化。

此过程中的一个重要步骤是为解决方案准备好环境。 这涉及遵循环境策略并按照组织定义的治理准则行事。

环境准备就绪后，我们可以遵循协商一致的部署策略。 此策略定义了我们如何向用户交付应用程序。 存在各种部署策略，如蓝绿部署流程、A/B 测试、金丝雀发布等。 所有这些部署策略的目的都是以受控的方式将更新的应用程序提供给一组用户，以便分析不同的指标，如性能、用户行为、功能影响等。 作为实际部署策略的示例，我们可以采用蓝绿部署策略，并使用应用程序共享选项向一组用户引入新功能。 向多个用户或组共享的过程可以通过 CLI/cmdlets 自动化 完成。

由于部署有时可能不如预期，我们应该准备好回滚策略，以防在部署或 测试阶段出现任何问题。

在此阶段，我们还可以执行与数据相关的任何活动，例如将测试数据导入 Dataverse 表格或为测试环境提供新表格，并从不同环境中复制数据 使用数据流。

操作

此阶段的 目的是确保系统的 可用性 以及部署解决方案的稳定和健康状态。 由于 Power Platform 是一项 SaaS 解决方案，IT 管理员无法控制运行服务的基础设施，这就是他们必须依赖 微软来保持系统正常运行的原因。 服务水平协议 (SLA) 描述了微软对正常运行时间和连接性的承诺。 然而，事情会发生，为了验证服务的状态，IT 管理员可以在 Power Platform 管理中心的 服务健康 仪表板中验证当前状态。 在这里，他们可以看到是否有任何正在进行的服务降级或未来的 计划中断。

一套工具，比如在 Power Platform 管理中心或 卓越中心 (CoE) 启动工具包，帮助 我们了解环境和部署解决方案的状态。 通过将我们的应用程序与应用程序性能监控解决方案，如 Azure Application Insights，连接，我们可以收集并分析健康、性能和使用数据， 覆盖应用程序。

此外，在此阶段，我们可以控制新开发的功能和应用程序对最终用户的暴露。 通过功能标志和商定的部署策略，我们可以验证开关的功能，并确保用户能够按设计访问特定 用户组的功能或服务。

监控和学习

连续 DevOps 生命周期的 最后阶段旨在确保监控工具到位，并为我们提供可以用来 分析使用情况和性能 的业务应用程序的遥测数据。 这些信息帮助我们学习并改进当前的 DevOps 流程。 它能为我们提供洞察，帮助判断是否需要构建更好、更具吸引力的 应用程序。

除了其他方面，DevOps 还关注特性功能的持续交付。 如果我们使用特性标志，允许对新功能的启用进行精细控制，那么必须有一个监控服务来捕获或收集新功能的使用信息。 这可以通过向 Azure 应用程序洞察发送自定义遥测数据来完成。 Azure 应用程序洞察是 Azure 监控的扩展，最初用于监控不同环境中的应用程序。 它允许我们了解性能和用户流，创建针对存储在日志分析中的日志的自定义查询等等。 通过创建警报，我们可以对性能或使用中的异常进行响应。 正如我们所看到的，通过收集用户遥测数据，我们可以了解应用程序的使用情况，以及我们是否根据 用户的需求投资构建正确的功能。

然而，需要注意的是，这一阶段并不仅仅关注理解来自用户的遥测数据。 在此阶段，我们的项目和开发团队还需要反思已完成的工作，诚实地回答 ALM 流程中哪些部分有效，哪些无效。 这种方法将帮助他们在过程中不断学习和成长，并在方向错误时进行修正。 所学的经验将反馈到 ALM 中，并用于下一个迭代周期。 持续学习和持续改进展示了我们对优化流程和为用户交付有价值产品的承诺。 考虑到这一点，让用户向开发团队提供反馈可以解锁有关如何使应用程序对用户更有意义的宝贵信息 。

从 工具的角度来看，团队将利用 Power Platform 内的分析功能以及 Azure 应用程序洞察。 团队还将使用项目规划工具，如 Azure Boards，来调查流程和团队表现中的瓶颈。 通过 Power BI 仪表板和报告，可以直观地展示 并进行调查。

我们已经提到了一些可以支持 ALM 和 DevOps 流程的工具。 在下一部分，我们将更深入地了解本书中将使用的两个工具的功能 以便进行动手操作。

ALM 和 DevOps 工具

市场上有许多不同的工具可用于管理 ALM/DevOps。 有些工具仅设计用于覆盖 CI/CD 过程，而另一些则构建成涵盖整个 DevOps 过程，包括项目规划、构建、管理测试场景等工具。 从生产力和集成的角度来看，拥有一个可以在整个应用程序生命周期管理过程中使用的工具总是一个不错的选择。 我们将深入了解微软提供的两个最重要的支持 ALM 和 DevOps 的工具：Azure DevOps 和 GitHub Enterprise。

Azure DevOps

Azure DevOps 有着与微软开发者密切相关的悠久传统。 这一切始于一款名为微软 Team Foundation Server (TFS)的产品，该产品于 2006 年初发布。 TFS 是一个用于管理开发项目配置工作流的协作工具。 顾名思义，它是一个客户必须部署到其本地环境中的服务器产品。 随着世界的发展以及云计算的兴起，微软开始寻找将 TFS 转变为 SaaS 产品的途径。 2011 年，TFS 作为 SaaS 解决方案在 Windows Azure 平台上推出。 它被命名为 TFS。 后来，它被 更名为 Visual Studio Team Services (VSTS)。 2018 年，微软将 VSTS 重新命名为 Azure DevOps 服务，同时也将 TFS 更名为 Azure DevOps Server。 Azure DevOps Server 2019 是首个重新命名后的本地版本。

由于一些组织尚未采用云战略，或者在受监管的行业中运营，Azure DevOps 仍然提供两种版本，以便客户可以根据自己的需求选择最适合的产品版本——Azure DevOps 服务或 Azure DevOps Server。 有时，客户可能会遇到需要混合配置的复杂环境。 在这种情况下， 构建代理 可以位于本地服务器上，用于 CI/CD 管道，同时仍然使用 Azure DevOps 服务在线的其他功能。 这是可能的，而且是一个非常常见的场景。 它解决了特定客户的需求，这些需求通常与法规有关，但也可以用于其他 技术原因。

Azure DevOps 包含 五个服务，支持 ALM/DevOps 流程：

• Azure Boards：用于项目规划和工作跟踪，提供看板、待办事项和 团队仪表板。

• Azure Repos：专注于提供私有 Git (以及较早的 Team Foundation 版本控制 (TFVC)) 仓库。 支持分支和 拉取请求机制。

• Azure Pipelines：专注于为任何项目构建 CI/CD 管道，支持任何语言，并可部署到任何平台。 由构建代理组成，构建代理是执行在 Azure Pipelines 中定义的操作的组件。 代理可以是微软托管的，当使用 Azure DevOps 服务时，或是自托管的，当在本地配置 Azure DevOps Server 时。 两者的组合，也可以作为混合设置。

• Azure Test Plans：旨在构建测试场景，以支持手动和 探索性测试。

• Azure Artifacts：作为一个包管理功能，允许用户从公共和 私有源创建和分享 NuGet、Maven、npm、Python 和通用包源。

Azure DevOps 非常可扩展。 通过扩展，管理员可以增强 Azure DevOps 的功能。 扩展可以通过 Visual Studio Marketplace（https://marketplace.visualstudio.com/azuredevops）找到并安装，那里有 Azure DevOps 服务和 Azure DevOps Server 的扩展。 Microsoft Power Platform 构建工具是这些扩展的一个例子，我们将使用它来支持 ALM 流程。

Azure DevOps 还支持 REST API 集成，用于自动化任务和与其他系统及应用程序的集成。 IT 管理员或 DevOps 工程师还可以利用 Power Platform 中的 Azure DevOps 连接器，这使他们能够对 Azure DevOps 中的项目执行操作，如创建新版本、创建新工作项或仅查看 项目状态。

GitHub Enterprise

GitHub 成立于 2007 年，GitHub 服务于 2008 年 2 月推出。 2018 年 6 月，微软宣布收购 GitHub。 这次收购也强调了微软对开源社区的承诺。

GitHub 提供不同的定价计划，根据计划解锁不同的产品功能。 GitHub 的计划旨在适应个人、小型团队，甚至更大的组织：个人或组织可以使用 GitHub Free，个人帐户可以使用 GitHub Pro，而大型公司则可以选择 GitHub Team 或 GitHub Enterprise。

GitHub Enterprise 是功能最丰富的选项，适用于大规模开发项目。 从功能角度来看，它与 Azure DevOps 类似，但也有一些区别。 与 Azure DevOps 一样，GitHub Enterprise 也有两种变体，分别是 作为云服务的 GitHub Enterprise Cloud，或者作为本地实例的 GitHub Enterprise Server。 这为客户提供了灵活性，选择如何部署和使用该工具。

与 Azure DevOps 类似，GitHub 产品旨在覆盖 DevOps 生命周期的所有阶段，具有以下功能：

• GitHub Issues 和 GitHub Projects：用于计划和跟踪项目中的工作。

• GitHub 仓库：专门用于提供私有或公共 Git 仓库，用于存储和协作项目中的源代码和文件。 支持分支和拉取请求机制。

• GitHub Actions：专注于提供支持 CI/CD 的平台，用于自动化构建、测试和部署流水线。 GitHub Actions 允许 DevOps 工程师扩展 CI/CD 流水线以外的任务，并根据仓库中的活动自动化项目中的其他任务。 GitHub Runners 是运行 CI/CD 流水线的关键组件。 它们执行 GitHub Actions 中定义的活动。 与 Azure DevOps 相比，它们类似于构建代理。 GitHub 还提供 GitHub 托管的运行器，或者可以在本地环境中部署的自托管运行器。

• npm、NuGet、Maven，等等。

GitHub 在其产品组合中拥有一套旨在增强开发者体验、改善 DevOps 过程中的协作，并实施 DevSecOps 的工具。 这些产品越来越受欢迎，值得一提的是： 这些工具包括：

• GitHub Codespaces：允许 开发人员快速提供一个安全的云开发环境，为选定项目配置。 这意味着它包含必要的开发工具，如 Visual Studio Code 和所有必需的扩展，帮助开发人员更快地开始项目开发。

• GitHub Copilot：这是 一个 AI 编码助手，通过提供基于 AI 的实时代码补全建议，帮助开发人员编写代码。 有关 Microsoft Copilot 的更多信息将在本书的最后一章中介绍。

• GitHub 高级安全：提供 额外的工具，进一步保护项目的安全。 通过代码扫描、密钥扫描和依赖项审查等功能，GitHub 高级安全使组织能够在开发周期中提前进行安全检查。 代码扫描让我们可以发现源代码中潜在的安全漏洞和编码错误。 密钥扫描会扫描我们的源代码，寻找任何可能被开发人员和 IT 工程师无意中提交到代码中的密钥和令牌等机密信息。 最后，依赖项审查使我们能够查看项目中使用了哪些依赖项，并检查项目所用版本是否存在已知漏洞。 GitHub 高级安全还可以与 Azure DevOps 一起使用。

现在我们已经 了解了 DevOps 生命周期阶段和支持 DevOps 生命周期的工具，我们准备深入探讨具体的现代化选项。 在决定将应用程序从现有技术栈迁移到 LCNC 平台时，我们将考虑可用的现代化策略。

LCNC 方法的应用程序现代化

在这一 部分，我们将重点讨论通过 Power Platform 进行的应用程序现代化。 我们将讨论不同的应用程序现代化策略选项，以及 LCNC 开发方法如何作为现代化应用程序的选项之一。

组织 现在，比以往任何时候都面临一个挑战，他们需要以快速的速度创新，以在市场上建立竞争优势。 拥有一堆构建在过时技术栈上的遗留应用程序，使其与现代系统集成的可能性变得更加复杂。 这类应用程序往往因为技术过时和难以 维护而存在潜在的安全威胁。

过时的技术也会在人员配备方面带来挑战，因为可能很难找到愿意继续使用旧编程语言和框架以及老旧开发工具进行开发的开发人员。 另一方面，维护现有的遗留应用程序可能会导致技术债务 显著增加。

因此，组织正在考虑现代化遗留应用程序的可能性。 Power 平台的 LCNC 开发方法允许组织加速交付新应用程序，减少开发成本，并通过允许公民开发人员参与流程来扩展资源池，并最小化对大量 定制编码的需求。

遗留应用通常没有我们可以连接的 API。 通过 Power Automate，Power 平台允许组织实施 机器人流程自动化 (RPA) 进程，这些进程 模拟用户与遗留应用程序的交互。 它允许他们将这些流程插入到新的现代业务流程和 云流中。

当现有应用程序公开 API 时，我们可以专注于为应用程序构建新的前端，并使用自定义连接器连接到后端 API。 这些用于执行特定操作，如数据库操作或功能逻辑。 这两种方法都允许我们以较小批次的迭代方式逐步现代化遗留应用程序，在进行现代化过程中启用功能。 这种 逐步现代化应用程序的方法 也有助于在不干扰 业务运营的情况下现代化组织高度依赖的应用程序。

Power Platform 可以与 Microsoft Azure 集成。 这使得已经采用 Microsoft Azure 云服务的组织能够以 LCNC 开发方式构建新应用或扩展现有应用，并简化 Power Platform 服务的采用。 由于 Power Platform 通过连接器支持与许多服务的集成，因此它也适用于现有应用的现代化。 第九章 将讨论 Power Platform 与 Microsoft Azure 之间的集成场景，希望能够为 应用现代化提供新思路。

已经采用融合开发方法的组织在进行应用现代化时将受益匪浅，因为这种方法允许专业开发人员、应用创建者和 IT 运维团队专注于他们在应用现代化过程中各自的角色。 我们将在 第九章 中进一步讨论 该方法。

应用现代化选项

在决定 现代化遗留应用的战略时，我们应该考虑应用现代化的不同选项，以便做出有根据的决策。 组织不应仅仅将遗留应用重写为使用更现代的框架和语言。 相反，他们还应该审查和更新使用的流程和数据库。 遗留应用是基于当时可用的技术开发的，同时也围绕适合当时的流程进行。 那个时候，同一个项目现在可能会与当时遗留应用开发时的方式完全不同。 现有的技术可能在当时并不存在，而我们今天能够交付的流程也可能与当时的完全不同。 现在我们正处于更广泛采用 AI 的时代，因此我们应该探索通过 AI 优化流程和创新的方式。 曾经手动完成的工作，现在有可能通过 AI 的帮助完全实现自动化。 因此，在处理应用现代化时，我们应该从流程优化和现代化的角度看待现代化——包括应用 和数据库。

流程现代化

我们应该首先 从 流程现代化 开始，以便能更多地从实际应用中受益 现代化和数据库现代化的过程。 流程现代化包括评估现有流程，以便了解我们可以在哪些方面进行改进。 然后我们可以继续优化和重新设计现有的业务流程，并利用现代技术的能力使其与现代时代相适应。 这个过程的结果是现代化和优化后的流程，在分析过程中识别出了瓶颈，并通过自动化在一定程度上或完全消除了这些瓶颈。 这使我们能够获得操作效率，从而降低现代化工作负载的总拥有成本。 现代化的工作负载。

Power Platform 有一个名为 Power Automate 流程挖掘的产品。 Power Automate 流程挖掘是一个可以帮助我们发现、监控和改进流程的产品。 在 2024 年 5 月，微软的流程挖掘解决方案被评为 2024 年 Gartner® 魔力象限™ 流程挖掘平台的领导者。 流程挖掘平台。

我们不应忘记提到，流程现代化的一个关键部分是组织文化和人员，而不仅仅是技术。 现代化不仅仅是关于技术，它是一种思维方式的转变，涉及到组织中每个人都参与到这一变化中，从领导层到一线员工。 接下来我们将探讨 Power Platform 采纳成熟度模型如何帮助我们实现这一目标。 下一部分将详细讲解。

应用现代化

应用程序现代化是一个 将软件应用程序更新以与技术进步对齐，满足当前业务需求，并改善用户体验的过程。 如今，在许多情况下，应用程序现代化与迁移到云端密切相关，但不仅仅是这样。 类似于流程现代化，它需要全面审视应用程序的状态，以改善用户体验，使应用程序更安全、更可靠、兼容更新的技术栈等。 应用程序现代化的一个好处是能够加速创新。 Power Platform 使我们能够做到这一点。 使用一个可以快速原型设计以及实际开发应用程序的平台意味着组织将有更多时间进行创新。 通过将 DevOps 或 DevSecOps 整合到整个过程中，我们还可以提高市场响应速度，同时保持我们的 应用程序安全。

在开始现代化应用程序之前，组织应该首先进行 应用程序合理化。这 将帮助他们了解他们的应用程序组合中有哪些应用，以及应该如何处理它们。 在识别了整个组织的所有应用程序之后，我们应该对这些应用程序进行评估。 这不仅将帮助我们建立一个应用程序清单，还能深入了解每个应用程序的情况。 这种评估可以通过手动或使用特定工具自动进行。 在这里，我们将查看应用程序的架构、应用程序依赖关系、基础设施架构、用户分析和使用模式，包括应用程序的使用频率，更重要的是，应用程序上次使用的时间。 许多时候，客户尝试现代化或迁移所有 应用程序，但实际上可能没有必要这样做，因为某些应用程序已经多年未使用。 在这种情况下，为审计目的保留数据可能就足够了，同时可以停用 这些应用程序。

一旦应用程序评估完成并且应用程序清单建立，我们应该决定应用程序的 现代化策略。

在 2011 年，Gartner 提出了 五个 R 迁移战略 five Rs migration strategy ，帮助我们将应用程序划分为迁移战略。 今天，我们可以看到市场上出现了更多的迁移战略选项，超越了五个 R 模型。 然而，它们或多或少建立在原始的五个 R 迁移战略基础上，具体如下： 如图所示：如下：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_03_2.jpg

图 3.2 – 应用现代化战略

我们可以看到，我们 可以将每个应用程序分为三个 主要部分。

• 首先是通过完全停用现有应用程序，或用基于 Power Apps 或 Dynamics 365 的现成解决方案替换它，从而终结现有应用程序。

• 接下来是迁移过程，将应用程序按原样重新部署到云基础设施中，通常是在虚拟机等 IaaS 工作负载上。 在这里，我们从 Power Platform 的角度并没有做太多，只是意识到该应用程序存在于 Azure IaaS 上，并且在构建任何新应用程序时，我们可能会更轻松地连接到 Azure 云上的现有应用程序。 更容易。

• 最后一个部分涉及实际的现代化，其中部分代码得到现代化，或者整个应用程序从零开始构建。 这是我们回到项目规划阶段的部分，收集所有需求，构建架构设计，并开始利用 Power Platform 服务开展新项目。 当我们完成应用程序的现代化后，我们应在组织中安排团队负责培训和推广，鼓励用户开始使用 新应用程序。

目前，市面上有一些工具可以评估遗留应用程序，并根据评估结果将其映射到合适的迁移策略。 然而，使用工具只是实际评估的一小部分。 评估的大部分工作是通过分析工具的结果来完成的。 这一步骤是为了验证结果，并将其与手动评估过程中的发现进行对比，手动评估过程可能还包括与应用程序用户和管理员的访谈。 工具可能会根据评估的源代码或提供给工具的输入，决定采用一种迁移策略。 然而，在进行深入分析和访谈后，可能会选择另一种迁移策略。 所有这些输入对于我们在开始实际的应用开发工作之前，决定迁移策略至关重要。 开发工作。

数据库现代化

数据库现代化 不仅仅是更新现有的数据库系统，还涉及如何改进存储、处理和管理 应用程序数据的过程。

通常，我们会在进行应用评估的同时，也进行数据库评估，因为这两者是密切相关的。 许多时候，应用逻辑是以存储过程的形式写在数据库中的，因此在评估并决定应用现代化方法时，我们也应该考虑这部分内容，并决定如何将这部分逻辑从数据库系统中提取出来，并转移到处理该逻辑的服务上。 话虽如此，进行数据库评估仍然非常重要。 这将帮助我们创建数据库、表格及其关系的清单。 我们还应该关注性能指标，并了解 瓶颈所在。

与应用程序现代化战略类似，数据库现代化时，我们也必须决定不同的现代化战略。 这些策略可以与应用程序现代化的策略相同，只是适用于 数据库的上下文：

• 退休: 我们 决定淘汰该数据库。 如果我们要这么做，应该研究现有数据库的归档选项以及停用数据库对 其他系统的影响。

• 保留：有时，由于特定的限制或需求，我们可能无法迁移到更新的数据库系统，这时保留现有系统成为我们的选择。 在这种情况下，Power Platform 可以通过许多连接器和本地数据网关支持我们，通过这些方式，我们可以将应用程序与 数据库系统连接。

• 重新托管：我们可以在不改变数据结构的情况下，将数据库迁移到新平台。 这可以是运行在 IaaS 上的解决方案，比如 Azure 虚拟机上的 SQL Server，或者其他开源 SQL 和 NoSQL 数据库解决方案，例如运行在虚拟机上的 MySQL 或 PostgreSQL，具体取决于 所使用的解决方案。

• 重构：这 将涉及修改或扩展现有的数据结构，以通过性能、可扩展性和可靠性等方面改善与数据库系统的体验，或改善其他方面。 在这里，我们 旨在利用更新的技术，例如为某些部分使用云数据库服务，同时将其余部分保留在现有的基础数据库技术上。 在这种情况下，某些部分我们可能会使用 Microsoft Dataverse，或者切换到 PaaS 服务，如 Azure SQL 数据库。

• 替换与重建：这两个 选项放在一起，因为在支持 Power Platform 服务的情况下，Dataverse 可用作使用 Power Platform 服务开发的新应用程序的数据库。

无论我们选择哪种 现代化战略，我们都应该致力于实施和采纳支持组织内部 DevOps 的流程。 应用程序现代化不是一次性的过程，而是一个迭代过程。 组织应该在现代化过程中跟踪进展和经验教训，并在有需要时进行改进。 这为组织提供了灵活性，使其能够在必要时改变战略。 拥有敏捷开发团队，并配备 DevOps 工具，能够在一个中心位置共同工作并跟踪项目进度，这使我们在 执行时更加高效。

然而，这不仅仅是关于 DevOps 工具。 在一个对大多数组织来说可能是新的平台上构建的应用程序，将需要我们在内部进行工作，增加组织对新构建应用程序的采用度。 这就是 Power Platform 采纳成熟度模型可以 帮助我们的地方。

构建 Power Platform 采纳之旅

在前一节中，我们提到过，应用现代化不是一次性的过程，且它将需要对进展和潜在改进进行持续评估。 为了充分发挥 Power Platform 的潜力，组织应探索引入增加 Power Platform 采纳率的战略的方法。 这可能涉及授权新的应用程序开发者或提供全面的培训，以及实施有助于开发人员在受控环境中工作的防护措施、流程和工具。 本节将讨论 Power Platform 采纳成熟度模型，并强调其对组织的重要性。

Power Platform 采纳成熟度模型帮助组织了解它们在成熟度量表上的位置，并确保采纳与业务目标和关键绩效指标（KPI）对齐，同时推动数字化转型。 对于那些在 Power Platform 上较为成熟的组织来说，使用 Power Platform 构建新应用或现代化现有遗留应用会与刚刚接触 Power Platform 的组织不同。 公司应了解当前的成熟度水平，并实施有助于提高成熟度的战略，这将使公司成为更具弹性、更有经验和更具适应性的组织。 这样做还可能使应用现代化过程更加顺畅。

Power Platform 采纳成熟度模型

Power Platform 采纳成熟度模型的目的是帮助组织评估当前的成熟度水平，并利用一套最佳实践、模式和工具指导组织如何提升其能力。 通过持续改进的过程，组织可以不断评估并提升其在最关键领域的成熟度。

Power Platform 采纳成熟度模型与变更管理过程密切相关，这基本上是组织为实现从当前状态到期望状态的转变，通过实施控制变更的战略并帮助人们适应变化而采取的一种结构化方法。 正如我们所提到的，这也是采纳成熟度模型的目的——帮助定义 Power Platform 服务采纳的战略或计划。 该计划应与组织的业务部门对齐并获得批准，因为改进目标应基于 业务目标。

Power Platform 采用成熟度模型基于 能力成熟度模型 (CMM)。像 CMM 一样，在这个模型中，我们也遵循五个成熟度层级，从级别 100 到 级别 500：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_03_3.jpg

图 3.3 – Power Platform 采用成熟度模型层级

每个层级 涵盖多个学科，这些学科为组织在各个领域的成熟度提供了见解。 这些学科如下：

• 战略 与愿景

• 业务价值

• 培育

• 管理 与治理

• 支持

• 自动化

• 融合团队

在 ALM 和 DevOps 方面，很多改进可以在自动化领域完成。 组织的自动化状态从级别 100 开始，ALM 流程大多是手动且非常个性化的，发展到级别 300，部署可能仍然是手动完成，但组织已经开始使用解决方案，一直到级别 500，ALM 流程已集中实施并由融合团队负责。 稍后，在 第六章中，我们还将看看 ALM 加速器，它帮助组织加速为 Power Platform 设置 ALM。

与 DevOps 和采用之旅紧密相关的，还有组织中融合团队的状态。 成熟度层级展示了融合开发团队在组织中的不同参与度。 级别 100 是融合团队尚未出现，专业开发人员没有参与 Power Platform 项目开发，工作主要由应用制作人员完成。 随着向级别 300 发展，我们可以看到团队开始形成。 融合团队成员了解并使用版本控制系统，甚至开始实施 ALM；然而，这些团队所做的工作仍然大多是分散的，尚未完全集中。 进入级别 500，形成了跨领域的融合团队，融入了跨职能的技能。 在级别 5，制定了统一的开发战略，拥有一个支持组织协作的集中式源代码管理系统。 第九章 详细解释了融合 开发方法。

各阶段的采纳成熟度模型

Power Platform 的采纳成熟度模型涵盖了五个成熟度级别。 接下来，我们将通过 一个示例来看每个级别。

级别 100 – 初始

在这个阶段，我们 可以看到，组织可能会有一些成功的案例，它们是通过使用 Power Platform 开发的。 用户可能会自行访问 Power Platform，通常通过 Microsoft 365，使用他们的预置许可证。 他们在 Office 365 服务上构建应用程序，通常使用 Excel 或 SharePoint 作为数据源。 由于这些应用程序是由个人开发的，个人也负责维护它们，而且这些应用程序大多不可重复使用。 没有集中式的治理或 ALM 策略。 用户主要在默认环境中工作；然而，由于没有保护措施，用户甚至可能会打开新的环境并使用任何连接器。 尽管通过这些成功的案例，组织可能会发现 Power Platform 的潜力，但尚未制定向组织范围推广的策略，也没有计划建立 一个 CoE。

为了达到下一个成熟度水平，在培养和提升未来应用开发者方面还有很多工作要做。 组织可以组织培训课程或黑客马拉松活动，在这些活动中，人们可以学习 并共同合作，构建解决特定业务问题的方案。 识别出在技术上早期采用的应用开发者对组织来说是有益的。 通过他们，我们可以将这些工作的经验 推广给其他人。

级别 200 – 可重复

组织 已经迈出了第一步，开始发现组织内用户所做的工作。 他们可能已经实施了 CoE 启动工具包，该工具包提供了一系列工具，帮助组织洞察 Power Platform 的采纳情况。 已开发的业务应用程序已经有一些文档，使其在需要时可以重复使用。 组织在 IT 和业务之间建立了共同的愿景，但新项目仍然是单独管理的。 一些政策已经开始实施，包括 DLP 政策，但仍然没有环境战略。 应用开发者可以组成团队或社区，通过这些团队和社区彼此支持，共同推进 开发过程。

为了晋升到下一个层级，组织可以在默认环境中实施 DLP（数据丢失防护）策略，访问 Power Platform 管理中心的分析功能，获得跨租户的洞察，改善与应用开发者的沟通，并继续建设内部培训资源。 后者可以通过集中式的内部 SharePoint 网站或其他 学习管理系统 (LMS) 工具来完成。

级别 300 – 已定义

在这个 层级，LCNC 开发方法成为标准业务流程的一部分。 组织通常会有一位代表或整个团队，担任 Power Platform 产品负责人。 应用程序可以由个人用户、业务单元或部门开发，因此创新既可以从下往上，也可以从上往下进行。 已经有更多使用 Power Platform 的成功案例，这些案例甚至可以进行量化。 已经建立了 CoE 团队，尝试自动化许多流程，如环境创建请求。 团队已经开始实施源代码控制系统，以便开始进行 ALM（应用生命周期管理）；然而，部署仍然主要是手动完成的。 应用开发者理解可重用性的重要性，并开始构建和 利用组件。

为了提升 成熟度，组织可以实施环境策略并配置 Power Platform 中的各种安全和治理控制。 我们应该继续通过他们开发的成功案例，培养和推广我们的应用开发者和团队。 这些案例是他们已经开发的。

级别 400 – 能力成熟

处于这个阶段的组织 已经非常先进。 他们已经建立了衡量 Power Platform 影响力的流程。 一个完善的 CoE 团队能够管理和监控 Power Platform 租户。 组织已经有了与融合团队合作的经验，这些团队具备跨职能的技能。 这使得开发过程中能够更好地合作。 ALM 流程已被定义，组织使用工具来集中管理 ALM 和 DevOps 流程。 部署流水线已实施并自动完成。 管理员能够通过分析识别未使用的应用，并采取自动化措施来管理环境。 在组织内，可能存在一个独立的支持团队，负责支持最终用户和 应用开发者。

为了推进到下一个成熟度水平，组织可以更加关注可重用性，实施应用程序目录，以确保可重用组件能够被访问，从而在应用程序之间提供一致性。 CoE 团队与 IT 运维团队之间的工作可以通过聊天机器人 实现自动化。

级别 500 – 高效

这是最 先进的阶段，在这个阶段，Power Platform 已成为数字化转型战略的一部分。 处于这个阶段的组织已经标准化和自动化了流程，能够快速开发项目以支持业务需求。 大型应用程序被构建以供整个组织使用。 在设计新项目的架构时，会包含 Power Platform 服务。 仪表板和报告已经实施，用于支持业务决策并验证 Power Platform 在每个项目中的影响。 组织内部对 Power Platform 的使用提供高层支持。 行政任务已实现自动化，尽可能利用自动化技术，包括带有审批流程的聊天机器人来执行租户管理操作。 融合团队已到位，并且拥有共同的开发战略，配备了完全自动化的 ALM 管道。 支持任务大多已自动化，包括用于内部支持的聊天机器人 或常见问题解答。

提升成熟度水平的方法

尽管 我们已经定义了每个级别，并提到组织应该努力提高成熟度水平，但常常会出现每个级别中的学科各自独立发展的情况。 这意味着，组织内部的级别提升并非在所有领域内系统地进行，而是专注于 特定领域。

我们可能会遇到刚刚开始采用 Power Platform 且处于初始阶段的公司，这些公司面临一个重要的应用程序现代化项目，这推动它们在非常具体的领域内适应并提升成熟度水平，以支持该项目。 这些公司会围绕它们希望在每个学科中达到的级别，制定自己的计划和战略，并创建一个有时间表的聚焦计划，帮助它们 实现目标。

为了更快地实现目标，他们可以遵循 Power Platform 采纳 最佳实践。

采纳最佳实践

提高 采用成熟度有助于组织更有效地使用技术，使他们能够建立支持数字化转型的流程。 为了支持这一采用过程，微软提供了一套最佳实践和指南，对任何人都有帮助：无论是刚开始使用 Power Platform 的人员，还是希望提高采用成熟度的人员，甚至是那些经验丰富但在推动组织服务采纳时遇到一些挑战的人。 组织中的人员。

采用最佳实践分为四个领域，涵盖了采用成熟度模型中的大多数学科：

• 战略 与愿景

• 管理员 与治理

• 培养 与教育

• 支持

Power Platform 着陆区

此 Power Platform 着陆区 参考文档作为一个模块化架构参考 指南，帮助组织按照设计原则和关键设计领域实施所需的 Power Platform 租户状态。 它帮助我们创建符合已达成治理政策的 Power Platform 环境。 正如我们所看到的，采用成熟度模型强调了自动化环境管理方法如何区分不同成熟度水平的组织。

Power Platform 架构良好的框架

该 Power Platform 架构良好的框架 (WAF) 是一个框架，它汇集了最佳实践和建议，帮助各类组织实现 Power Platform 应用工作负载的最优架构设计。 组织可以确保，通过遵循 Power Platform WAF，他们的环境将准备好应对未来的扩展，并设置必要的控制措施，确保环境和数据的合规性与安全性。 以及数据。

我们将在第十一章中深入探讨这些主题，届时将讨论更多关于 IT 操作的内容。 在那里，我们还将讨论这些最佳实践的安全方面以及可用于集中管理环境的工具 和自动化工具。

摘要

本章介绍了 为什么 以及 如何 使用 ALM 和 DevOps 与 Microsoft Power Platform 的相关内容。 理解 ALM 和 DevOps 对组织带来的价值非常重要，因为我们需要向组织展示，这不是一项不可能完成的任务，而是每个组织都可以并且应该实现的目标。 我们在本章中学习了这一点。 这就是为什么学习 ALM/DevOps 流程如何实现以及有哪些工具可用如此重要，正如我们在本章中所做的那样。 由于这是一个持续学习和改进的过程，组织不必担心第一次尝试时可能无法完全做到。 通过不断迭代改进和适应过程，使其量身定制以适应组织，是实现 卓越的正确方法。

我们讨论了应用现代化的话题，以及为什么组织需要审视其现有的遗留应用，并探讨了应用现代化战略的选项。 我们看到，DevOps 和采纳是数字化转型和应用现代化的核心。 这就是为什么我们要了解 Power Platform 采用成熟度模型是什么，以及组织如何确定自己在每个领域的成熟度水平。 很可能，组织在某些领域的成熟度较高，而在其他领域则较低，正如我们在本章中学到的那样。 我们还了解到，组织制定如何改善这些差距的战略、实现平台潜力，并看到 Power Platform 的投资回报是非常重要的。 下一章将深入探讨解决方案和环境。 我们将了解这些概念在 Power Platform 中的含义、可用的类型是什么，以及它们之间的差异。 这将帮助我们熟悉托管环境和解决方案，以及如何使用管道并开始构建我们的第一个 CD，使用 托管管道。

进一步阅读

• Azure DevOps： https://azure.microsoft.com/en-us/products/devops

• GitHub: https://github.com/

• Power Platform 采用成熟度 模型： https://learn.microsoft.com/en-us/power-platform/guidance/adoption/maturity-model

• Power Platform 采用 指南： https://learn.microsoft.com/en-us/power-platform/guidance/adoption/methodology

第二部分：在 Microsoft Power Platform 上实施 DevOps

在本部分中，我们将探讨 Microsoft Power Platform 的环境和解决方案，以及它们如何集成到 DevOps 相关流程中。 通过实际操作，我们将熟悉 PAC CLI、Git 版本控制系统、Azure DevOps Services 管道和 GitHub 工作流。 我们还将发现 Power Platform 管道和托管环境的最新功能。 此外，我们将深入了解 Power Platform 上的 DevSecOps，利用 GitHub 的高级安全功能，针对 GitHub 和 Azure DevOps 进行深入探讨。 最后，我们将把所学知识应用到一个实际案例中，进一步巩固对 这些概念的理解。

本部分包含以下章节：

• 第四章， 理解 Power Platform 环境和解决方案

• 第五章， 通过 DevOps 工具简化 Power Platform 开发

• 第六章， 深入了解持续集成/持续部署（CI/CD）管道

• 第七章， Power Platform 中的 DevSecOps 概述

• 第八章， 展示 ALM 和 DevOps 实施

第四章：了解 Power Platform 环境和解决方案

现在我们已经了解了 Power Platform 产品，以及 应用生命周期管理 (ALM) 和 DevOps 方法，在前几章中，接下来是探索成功的 ALM 基础构建模块，介绍 环境 和 解决方案的概念。我们将从解释 Power Platform 中构成解决方案的内容开始，然后讨论 Dataverse 以及在该框架下的数据建模。 我们还将涵盖平台中解决方案和包的版本控制，以了解如何管理不同版本的解决方案。 我们将学习 托管环境 和 托管管道的概念，还将发现如何使用它们来自动化和简化软件开发过程。 我们将以一个逐步指南结束本节，介绍我们在 Power Platform 中的第一个 持续集成和持续部署 (CI/CD) 管道，帮助我们实践理解在此特定环境下 CI/CD 过程的工作原理。 具体情况。

在本章结束时，我们将能够使用内置的 Power Platform 管道设置 CI/CD 管道，将解决方案部署到不同的环境，并使用 Copilot 生成部署说明 在管道中。

在本章中，我们将讨论以下 主要主题：

• 解决方案涉及的内容？

• 解决方案和包的版本控制 和包

• 数据相关内容——Dataverse 和数据 建模方面

• 环境——托管环境和 环境策略

• 托管管道——我们的 第一个 CI/CD

技术要求

为了能够使用 Power Platform 管道创建我们的第一个 CD 管道，我们需要拥有一个 Power Platform 订阅。 如果我们已经拥有 Microsoft Entra ID 工作账户，可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free）；或者我们也可以加入 Microsoft 365 开发者 计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。

此外，我们需要安装 PAC CLI 工具和 PowerShell 管理员模块。 请参见 第二章 以获取设置和 安装信息。

什么是解决方案？

正如我们在前几章中所学，Power Platform 包含多个产品，包括 Power Apps、Power Automate、Power Pages、Microsoft Copilot Studio、Dataverse、AI Builder 等。 我们通常将这些产品中可以创建的构建块称为资产或解决方案组件。 一个资产可以是一个画布应用、连接引用、云流、自定义 Copilot，甚至是为 Dataverse 或 Dataverse 表 架构定义而开发的插件。

解决方案 是 构建 Power Platform 应用程序的资产容器。 它们可以包含一个或多个应用程序，以及其他组件，如流、定制 Copilot、Power Pages 网站、站点地图、实体、流程、Web 资源、选项集、专业开发组件（如插件、PCF 组件等）。 一些组件嵌套在其他组件中；例如，Dataverse 表包含表单、视图、图表、列、表关系、消息和业务规则。 这些组件中的每一个都需要一个表才能存在，并且不能存在于表之外。 另一方面，解决方案需要安装了 Dataverse 的环境。

我们需要解决方案，因为 Power Platform 解决方案是将应用和组件从一个环境传输到另一个环境或将一组自定义应用于现有应用的方式。 这是 Power Platform 中 ALM 流程的关键基础之一。 要实现这些发布并且 让 持续部署 （CD）顺利工作，平台定义了两种类型 的解决方案：

• 托管解决方案 是 通过将一个非托管解决方案导出为托管解决方案包来创建的。 一旦将托管解决方案导入目标环境，解决方案中的组件将被锁定，并且只能由解决方案的发布者进行修改。 这使得 发布者能够控制如何在目标环境中使用和更新该解决方案。 托管解决方案就像生成的二进制文件；它们在 目标环境中是不可变的。

• 非托管解决方案 通常用于开发环境，其中会对应用程序进行更改和定制。 与托管解决方案不同，非托管解决方案中的组件没有被锁定，任何具有适当权限的人都可以进行修改。 这些解决方案类似于应用程序的源代码 在定制开发项目中。 非托管解决方案作为非托管解决方案包进行导出，并可以导入到其他环境中进行进一步的开发或测试。 然而，值得注意的是，非托管解决方案不应在生产环境中使用，因为任何有权限访问其定义组件的人都可以对其进行更改。

每个开发项目都从非托管解决方案开始，开发人员通过添加组件来扩展，以实现原始客户需求。 在完成开发并通过测试阶段后，非托管解决方案会转换为 托管解决方案。

我们还可以手动导出解决方案，这会生成 ZIP 文件。 对于托管解决方案，ZIP 文件只包含少数几个文件。 其中之一是一个 .msapp 文件。 另一方面，非托管解决方案的 ZIP 文件包含大量描述 Power Platform 资产配置的 JSON 和 XML 文件，这些资产包含在解决方案中。 如果需要，我们也可以编辑后者。 如果需要的话。

考虑到传统的开发术语和方法论，创建托管解决方案等同于生成二进制文件，因此它正是 一个 持续集成 (CI) 构建所做的。 将托管解决方案移至不同环境对应于 CD 步骤。

解决方案作为起点

强烈建议通过创建一个解决方案来开始对任何 Power Platform 组件或资产进行定制。 然后我们应当在解决方案内创建组件，而不是在相应的编辑器中创建。 当我们使用这种方法时，平台会立即将所有依赖项添加到 Power Platform 解决方案中。

解决方案分层 是 Power Platform 中的一项功能，允许我们管理解决方案内组件的依赖关系和行为。 当我们将一个解决方案导入到环境中时，解决方案内的组件会根据其依赖关系被组织成多个层。 每一层代表一个特定的解决方案，该解决方案扩展或更改了组件的行为。 解决方案层允许我们控制不同解决方案之间的交互方式，以及一个解决方案的更改如何影响其他解决方案。 当我们有多个解决方案修改同一组件时，这尤其有用，因为它允许我们管理冲突，并确保组件的行为在所有解决方案中保持一致。 下图展示了解决方案分层如何在实际中工作：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_1.jpg

图 4.1 – 解决方案层

在 系统解决方案 和 系统层的基础上，每个 托管解决方案会创建自己的托管解决方案层。 如果多个解决方案更改同一底层组件（资产），则最后的自定义会生效（最后的更改有效）。 为了避免与其他解决方案的合并冲突，最佳做法是使用唯一的资产名称，例如在常见 Dataverse 表中使用唯一的表单和视图名称。 由于自动化部署管道在后台运行，我们也需要关注此类冲突 情况。

为了支持现代的 ALM 和 DevOps 流程，除了拥有不可变的二进制文件（解决方案）外，我们还 需要版本号。 版本号 帮助开发人员和运维团队识别生产环境中运行的软件。 Power Platform 解决方案也提供版本管理功能，我们将在 下一节中讨论。

解决方案和包的版本管理

每个 解决方案都有一个版本号，遵循以下 知名 模式：

 Major.Minor.Build.Revision

版本号的每个部分都有一个 特定的含义：

• 主要：当软件发生重大变化时，如添加新功能或不兼容的更改时，这个数字会增加。

• 小版本：当软件进行小幅更改时，例如添加新功能或改进现有功能，且这些更改 向后兼容时，版本号会增加。

• 构建：当软件发生变化但不影响其功能时，例如修复漏洞或 性能改进时，构建号会增加。

• 修订：当软件进行小幅更改时，例如修补程序或 安全更新时，修订号会增加。

Power Platform 解决方案的生命周期涉及多个阶段，包括创建、更新、升级、修补和升级准备。 以下是各个操作的适用时机概述： 这些操作：

• 更新：此选项用新版本替换我们的解决方案。 不属于新版本的资产不会被删除，仍然可以在环境中使用。 此选项通常比升级方法完成的时间更短，性能最好。 我们可以为托管解决方案创建更新，这些更新会部署到父托管解决方案下。 我们不能通过更新删除组件。

• 升级：升级将所有补丁合并到解决方案的新版本中。 在升级过程中，任何不再包含在新版本中的组件将被删除。 升级可以立即进行 或分阶段进行。

• 升级准备：此操作用于在部署解决方案之前准备目标环境。 升级准备不会删除解决方案的先前版本；旧版本和新版本会并排安装。 如果我们需要在完成解决方案升级之前进行数据迁移，可以使用此场景。 解决方案升级。

• 补丁：补丁仅包括对父托管解决方案所做的修改，例如添加或修改组件和资产。 补丁用于进行小的更新，如热修复。 导入补丁后，它将应用于父解决方案之上。 无法通过补丁删除组件。

下图显示了 Power Platform 解决方案的生命周期，突出了应用程序的主要阶段： 一个应用程序：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_2.jpg

图 4.2 – 一个解决方案的生命周期

每个解决方案 都从 创建 阶段开始其生命周期。 在 开发和发布 阶段，多个更新、升级和补丁作为托管解决方案发布。 在应用程序生命周期结束时，托管解决方案将被删除，进而从 Dataverse 中移除所有自定义对象。

在托管解决方案的情况下， 升级 操作是默认选项，介于 更新、 升级、 升级阶段和 补丁 操作之间，而未托管解决方案只能进行 更新。

Power Platform 解决方案补丁是一种仅更新解决方案中已更改的组件，而不是重新部署整个解决方案的方法。 它们有助于减少部署时间并避免与其他解决方案的冲突。 补丁仅包含父级托管解决方案的更改，如添加或编辑组件和资源。 使用补丁的典型例子包括在画布应用上添加新按钮或扩展自定义或系统表的列定义。 补丁的版本号在 1 上递增，反映在 构建 号中：

 {major}.{minor}.{build+1}.{version}

只有未托管解决方案可以有一个或多个补丁，我们可以将它们导出为托管补丁，部署到其他环境中。 创建补丁的解决方案被锁定，直到补丁被合并并且新版本的解决方案被克隆。 这个版本将获得 {major}.{minor+1}.{build}.{version} 版本号，正如我们在 下图中所见：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_3.jpg

图 4.3 – 补丁和版本

父级 解决方案是版本为 1.2.0.0 的未托管解决方案。 补丁分别获得递增的版本号 1.2.1.0 和 1.2.2.0。 在汇总补丁后，未托管解决方案的新版本将 为 1.3.0.0。

我们建议尽量少使用补丁，因为迟早我们需要将补丁汇总起来，并发布一个 解决方案更新。

如果我们的解决方案包含太多自定义内容，那么在同步导入过程中可能会遇到超时问题。 解决方案分阶段 将导入过程拆分成更可控的阶段，并异步执行这些步骤。 此选项在 Dataverse SDK for .NET 中、通过 Web API、在 Azure DevOps 和 GitHub 的构建工具中，以及在 PAC CLI 中均可使用。

有两个高级的专业开发工具，我们可以用来深入自定义解决方案的导入和导出过程：

• SolutionPackager 是用来解包解决方案 ZIP 文件到解决方案文件夹，或者将解决方案文件夹打包成解决方案 ZIP 文件的工具。 我们还可以配置 是否将生成的 ZIP 文件设置为托管解决方案或 非托管解决方案。

• Package Deployer 工具 是 Power Platform 中的一个强大工具，允许管理员在 Microsoft Dataverse 实例上部署包。 一个 Package Deployer 包可以包含以下任意内容： 或全部内容：

  • 一个或多个 Dataverse 解决方案文件

  • 纯文本文件或从配置迁移工具导出的配置数据文件 。

Package Deployer 是一个出色的工具，可以将多个解决方案打包为一个整体包，部署到我们的 Power Platform 环境中。 我们只需要在 Visual Studio 2019 或更高版本中创建一个 MSBuild 项目文件，或者使用 Visual Studio Code。 然后，我们可以将解决方案、附加的配置文件、HTML 内容，甚至自定义代码添加到该 MSBuild 项目中。 构建完包后，管理员可以将其安装到目标环境中。 我们的自定义代码会在导入过程中执行，而 HTML 内容会显示给管理员，以便他们了解我们的包究竟做了什么。 我们在 第二章 中学习的企业模板也是以这种方式创建的。

现在我们已经了解了 Power Platform 的解决方案概念，接下来让我们来看看 Dataverse，这些解决方案（以及其他内容） 就存储在这里。

那数据呢——Dataverse 和数据建模方面

我们都知道，没有数据，应用程序是无法正常工作的。 它们要么使用数据来改变自身行为（比如数据驱动的应用程序），要么通过众所周知的 创建-读取-更新-删除 (CRUD) 操作来处理数据。

Microsoft Dataverse 是一个 基于云的数据平台，是 Microsoft Power Platform 的一层强大的数据库服务，不仅存储关系数据（类似 SQL 表格），还存储文件、日志以及 NoSQL 物联网数据。 在其背后，Dataverse 无缝地使用了许多 Azure 服务，作为 多语言持久层。下图展示了 Dataverse 及其使用的 Microsoft Azure 服务的高级架构：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_4.jpg

图 4.4 – Dataverse 多语言概念内部结构

正如我们在 图中所见，Azure 负载均衡器将请求分发到多个 计算服务：

• Web 用于处理 OData API 请求

• Azure 作业 用于处理 异步处理

• 用于运行客户 C# 代码的沙箱，代码将在 处理流水线中执行

• 报告服务器处理 分页报告

我们使用多种存储服务，以最有效和高性能的方式持久化我们的数据。 关系数据 存储在 Azure SQL 托管实例，文件和附件写入 Azure Blob 存储，由 DataFlows 生成的分析 数据存储在 Azure 数据湖存储。我们还使用 弹性表 ，一个用于存储 物联网 (IoT) 数据 的全新概念，支持数千万条记录 ，由 Azure Cosmos DB提供支持。

Dataverse 管理 所有这些 Azure 数据服务，提供 99.9% 的可用性、企业级可扩展性、备份、审计日志和灾难恢复管理。 Dataverse 也是 Dynamics 365 产品系列背后的主要数据存储解决方案。

数据库服务的一个关键特点是内置的安全解决方案，采用严格的基于角色的访问模型，以及行级和列级的安全配置。 Dataverse 安全性基于基于角色的安全模型，保护数据的完整性和隐私，同时支持高效的数据访问和协作。 可以访问 Dataverse 的用户是 Microsoft Entra ID 账户，也就是 Azure AD 用户。 每个用户可以被分配一组预定义的安全角色，这些角色决定了用户可以访问的记录类型、用户可以管理的数据范围以及他们可以执行的具体任务。 该模型被称为行级安全性，它仅提供用户进行工作所需的适当级别的信息访问。 例如，用户可以查看和编辑他们创建的记录。 他们的主管可以查看和编辑他们下属创建的所有记录。 常见的 安全角色 如下：

• 系统管理员：此 角色可以访问所有数据，并执行所有任务，包括定制 系统

• 系统定制员：此 角色可以定制系统，但无法访问 所有数据

• 环境管理员：此 角色可以访问环境中的所有资源 包括 Dataverse

• 环境创建者：此 角色可以创建新的环境资源，例如应用、流程和 API，但不能访问 环境中的数据（Dataverse）

• 基础用户：此 角色对数据的访问有限，并且只能执行 基本任务

Dataverse 还 提供 薪资 列，位于 这些记录中。

此外，Dataverse 提供 数据丢失预防 (DLP) 功能，以强制执行跨连接器的策略。 策略可以在租户或环境级别定义。 稍后我们将看到，每个环境可以创建一个或零个 Dataverse。 环境级别的策略适用于环境级别，仅在该级别适用，而租户级别的策略适用于整个租户，并优先于环境级别的策略。 DLP 的管理和治理涉及事件警报和报告，为管理员提供关于策略匹配的详细信息，使其能够有效监视和保护敏感数据。 这些报告帮助管理员了解随时间变化的 DLP 策略和规则匹配次数，通过动作和位置过滤这些匹配，并确定规则匹配是上升还是下降。

零信任安全原则 是 基于的理念，即信任是一种漏洞，安全必须设计为 从不信任，始终验证的策略。这意味着，与其假设企业防火墙后的所有内容都是安全的，零信任模型假定存在入侵，并像来自不受控网络的请求一样验证每个请求。 在 Dataverse 和 Power Platform 的背景下，可以通过使用基于角色的访问控制、字段级安全性和 DLP 功能来应用零信任安全原则，以强制执行策略和保护数据。 通过在设计安全角色时实施 最低特权策略，我们可以确保用户只能访问他们工作所需的资源。 此外，我们可以使用 Microsoft Entra ID 管理用户身份和访问，并实施 即时访问 (JIT) 和 仅够访问 (JEA) 策略，以确保用户只在需要时访问所需内容。 遵循零信任安全原则，我们可以最大限度地减少数据泄露风险，并保护组织的数据，同时仍能实现高效的数据访问和协作。

除了这些全面的功能外，Dataverse 还有一个通用的数据库架构。 该 通用数据模型 （CDM）是由微软及其合作伙伴发布给开源社区的，存储在 GitHub 上的一组共享、标准化的数据架构。 它将数据统一为已知的形式，并在多个应用程序和部署中应用结构化和语义一致性，使数据管理和应用开发更加简便。 CDM 受到 Dynamics 365 中数据架构的影响，涵盖了广泛的业务领域。 它带来了包括 账户， 客户， 产品， 机会， 销售， 采购订单，等等，通用数据表定义已加入 Dataverse。 CDM 定义是开放的，任何希望使用这些定义的服务或应用程序都可以访问。 通过使用 CDM，我们可以轻松地与 Dataverse 和其他服务集成，并可以构建使用我们可用的实体定义的自定义应用程序。 这可以节省我们的时间和精力，因为我们不需要从头开始构建新的数据模型 。

Dataverse 架构定义，如 表格， 列， 关系， 业务规则， 视图， 表单， 仪表盘， 图表， 消息， 键，和 命令，是解决方案定义的一部分，这意味着数据库级别的更改是开发人员可以包含在他们的解决方案中的资产之一。 另一方面，解决方案本身存储在 Dataverse 中。 当我们将解决方案导入到 Dataverse 时，它的元数据和依赖配置会被导入到各种系统表中，例如 解决方案， 解决方案组件属性配置， 解决方案历史， 解决方案组件历史，等等。 在元数据导入后，底层系统流会安装解决方案并应用 这些更改。

Dataverse 和解决方案中的数据

要向 Power Platform 解决方案中的 Dataverse 表添加数据，我们可以使用 导入数据 选项，该选项位于 Power Apps 的 表格 页面顶部的命令栏中。 （故意）没有方法将数据包含在 Power Platform 解决方案中。 但是，我们可以将数据导出，然后将其导入到新环境中。 另外，如果当前生产环境中没有内容，我们可以在 Power Platform 管理中心复制整个开发环境。 推荐的工具和方法包括使用配置迁移工具、包部署工具、Power Platform 数据流，或在 Dataverse SDK for .NET 中编写代码以在目标环境中创建实体，这些都是导入数据 到环境中的推荐工具和方法。

Dataverse 实例存在于环境中，这是一个用于在租户范围内组织我们的应用和解决方案的附加概念。 在下一部分中，我们将了解如何从 专业开发者的角度考虑这些环境。

环境、托管环境和环境策略

环境 是我们的应用、流程、连接和其他组件的容器，同时还具备安全性和数据访问管理功能。 借用云计算世界的类比，我们可以将 Microsoft Azure 订阅看作是环境，它们作为逻辑容器，能够托管一个或多个应用。 也许 工作负载 这个术语在这里更为合适，因为我们的 Power Platform 应用可能包括 Power Apps、Flows、自定义 Copilots、Power Pages 网站等。 强烈推荐使用解决方案将工作负载 部署到环境中。

Microsoft Power Platform 租户可以拥有数千个环境。 Microsoft Entra ID 是提供安全控制、治理和环绕 Power Platform 每个产品的保护框架的粘合剂。 如前所述，Power Platform 运行在 Microsoft Azure 之上。 环境是隔离的关键概念，用于在不同的地理位置定义系统边界。 我们可以创建没有 Dataverse 的环境，但这些环境仅提供非常 有限的功能。

没有 Dataverse 的环境

没有 Dataverse 的环境仅支持 Power Apps 画布应用和 Power Automate 云流。

如果我们使用 Dataverse 创建环境，我们将获得 Power Platform 安全功能的整个范围 。 这意味着我们可以在环境内部的不同层级上分配基于角色的安全角色来 划分安全性。

在 Power Platform 中， 业务单元 代表了一个组织中的单位，该单位执行一个或多个可以在管理层级中汇总的业务职能。 业务单元可以用于镜像公司的组织结构，并控制数据访问。 每个业务单元都有自己的安全角色，这些角色定义了业务单元内用户的访问权限。 有内置的安全角色，如基本用户、系统管理员等，我们也可以创建自己的安全角色。 例如，如果我们引入一个自定义表格来存储审核记录，我们可以创建一个自定义安全角色（例如审核员），使其成员可以读取自定义表格中的所有记录，而其他人只能看到自己的记录。 我们还可以将这些安全角色添加到 解决方案中。

团队 是 一群一起工作并共享共同访问权限的用户。 Power Platform 中有两种类型的团队： 所有者团队 和 访问团队。所有者团队 拥有记录，并且有安全角色分配给它们，而 访问团队用于授予记录访问权限，但不拥有它们。 一个团队可以由同一组织（在同一环境下）内的一个或多个业务单元的用户组成。 一个用户可以被分配到一个或 多个团队。

业务单元、团队和用户之间的关系对于控制数据访问和确保用户对记录具有适当的访问权限非常重要。 通过正确设置业务单元和团队，管理员可以确保用户能够有效地协作和共享信息，同时维护 数据安全。

Microsoft Entra ID 和 Power Platform 环境

由于 Microsoft Entra ID 和 Power Platform 之间的连接，通常的做法是使用 Microsoft Entra ID 组来授予对 Power Platform 环境以及其中的业务单元和团队的访问权限。 这些环境中的访问权限。

环境有不同类型 ：

• 生产环境：这是 创建和运行应用、流程及其他资源的默认环境类型。 它具有完整的功能，且可以连接到任何数据源。 只有生产环境才有服务级别协议（SLA）保障，所有生产数据都会备份到配对或辅助的 Azure 区域（启用了地理复制）。

• 试用环境：这是一个 临时环境，可以用于测试或学习目的。 它具有与生产环境相同的功能，但在 30 天后到期且无法延长或转换。

• 沙盒环境：这是一个 隔离的环境，可以用于开发、测试或培训目的。 它具有有限的功能，无法连接到生产数据源。 可以根据需要重置、复制或转换回生产环境。

• 开发者环境：这是一个 特别的环境类型，个人开发者可以使用它来创建和测试应用、流程以及其他资源。 它具有与沙盒环境相同的功能，但容量较小，只能由一个用户使用。 开发者环境不需要许可证，且每个开发者最多可以拥有三个不同的开发者环境。 管理员可以根据 组织的需求，允许或禁止创建开发者环境。

环境绑定 到一个 地理位置 ，该地理位置在环境创建后无法更改。 微软 Power Platform 保证数据将保留在选定的地区（数据驻留），且数据永远不会被转移到 其他位置。

环境还用于 分配 容量附加组件 ，这些是我们可以购买的，额外添加到我们的 Power Platform 订阅中的。 容量附加组件包括微软 Copilot Studio 消息、Power Pages 容量层级、AI Builder 积分、Power Automate 托管的 RPA、Power Automate 流程或流程挖掘的容量附加组件。 我们可以将其中一些或所有这些容量分配到 Power Platform 管理中心中的不同环境。

最后，环境可以与 Microsoft Azure 订阅绑定。 Power Platform 的 按需付费 (PAYGO) 服务 例如每个应用的 Power Apps 计量器、Power Pages 认证用户计量器、Power Pages 匿名用户计量器、Dataverse 数据库容量计量器、Dataverse 文件容量计量器以及 Dataverse 日志容量计量器，均通过现有的 Microsoft Azure 订阅进行交叉计费。

还有一个更加受控的环境，我们建议在生产中使用。 让我们来了解一下 托管环境。

托管环境

托管环境 是一套帮助管理员大规模管理 Power Platform 的功能。 它提供了多项好处，包括使用 Microsoft Defender 进行的风险评估和威胁警报、具有多年度历史的丰富分析、合规报告以及推荐。 它还允许你审计用户行为。 它通过根据我们组织的需求定制权限、政策和自动化，或仅需单击一下即可激活最佳的开箱即用设置，提供更多的控制。 以下列表详细介绍了 这些功能：

• 限制共享 允许管理员控制其组织内数据和资源的共享。 管理员可以阻止与安全组的共享，并限制可以共享的个人数量。

• 每周使用情况洞察 提供关于我们最热门应用、最具影响力的创建者以及可以安全清理的非活动资源的分析。 这些洞察每周发送到我们的邮箱。

• 数据策略：Power Platform 中的数据策略允许我们在 Power Apps 和 Power Automate 内使用数据连接器时控制数据流。 DLP 策略使管理员能够通过将 Power Platform 连接器分为业务和非业务组，来隔离业务数据和个人使用数据。 我们还可以选择阻止某些连接器的使用。

• Power Platform 中的管道 旨在为 Power Platform 客户普及应用生命周期管理（ALM）。 管道为所有创建者、管理员和开发者提供了一个简单易用的方法来进行 ALM 自动化、持续集成（CI）和持续交付（CD）工作流。 我们将在 接下来的章节中介绍这个话题。

• Maker 欢迎内容 允许管理员为新加入的 Maker 添加欢迎信息。 此信息可以包括经过验证的资源、公司特定的资源以及即将举行的内部活动链接，以帮助新 Maker 启动 Power Platform。 欢迎内容可以添加到托管环境中，并且可以包括纯文本 或 Markdown。

• 解决方案检查器 工具允许我们检查解决方案的最佳实践和常见问题。 它分析我们的代码和定制，并提供详细报告，包含问题信息以及如何修复。 这有助于提高我们在托管环境中的解决方案的性能、可维护性和可靠性。 管理员可以在部署过程中强制执行解决方案检查器的执行。

• IP 防火墙 允许我们根据来访请求的 IP 地址限制对我们的数据和资源的访问。 这有助于防止外部未经授权的访问我们组织的数据和资源。

• IP Cookie 绑定 是一项安全功能，将用户的会话 Cookie 绑定到其 IP 地址。 这有助于防止会话劫持攻击，其中攻击者窃取用户的会话 Cookie 并用它来 冒充用户身份。

• 客户管理密钥 （CMK）允许我们使用自己的加密密钥对静态数据进行加密。 这使我们对数据安全性有更多控制，并帮助我们满足 合规要求。

• Lockbox 为我们的数据提供额外的安全层。 它允许我们控制微软支持工程师是否可以访问我们的数据来解决支持案例。 我们可以批准或拒绝每一个访问请求，所有访问都将记录和审计 以确保合规。

• 扩展备份 允许我们保留更长时间的数据备份。 这可以帮助我们在数据意外删除 或损坏的情况下恢复数据。

• 桌面流 DLP 是 Power Platform 中的一项功能，允许我们对桌面流（机器人流程自动化流）应用 DLP 策略。 这有助于防止在不同系统 和应用程序之间意外或故意共享敏感数据。

• 将数据导出到 Azure Application Insights 使我们能够将应用和流程的遥测数据发送到 Azure Application Insights。 这使我们能够监控 应用和流程的性能和使用情况，并进行诊断和 故障排除。

• Power Platform 中的目录 是我们在组织中存储资产的中央仓库。 它是一个私有市场，我们可以通过它与 其他开发者共享自定义连接器、PAC 框架控件、Power Automate 流程、Canvas 应用和基于模型的应用，以及各种其他模板。

• 默认环境路由 允许我们控制哪个环境作为组织中新用户的默认环境。 这有助于确保新用户自动加入适合其角色 和职责的环境。

• 通过 Copilot 创建应用描述 是一个由 AI 驱动的功能，帮助我们创建应用描述。 它使用自然语言处理技术理解我们的需求以及我们所做的更改，从而为 我们的应用提供类似人类的描述（变更日志）。

托管环境

我们强烈建议在生产工作负载中使用托管环境。 一般来说，所有环境类型为 生产 的环境都应为托管环境。 微软在托管环境方面投入巨大，越来越多的功能正在发布。 我们可以通过发布计划跟踪即将发布的功能； 请见 https://releaseplans.microsoft.com。

在讨论环境之后，让我们探索一下为什么 环境策略 对在企业层面维护和管理成百上千的环境至关重要。

环境策略

这是我们需要决定的最关键问题之一，不仅在首次注册我们的 Power Platform 租户时需要考虑，每次启动新项目时也必须做出此决定。 环境策略定义了如何创建环境，针对每个工作负载和项目我们需要多少环境，如何应用我们组织的安全策略，如何建立基于角色的访问管理，以及环境如何与其他产品相关联，例如 Microsoft Azure 订阅、Azure DevOps 项目或 GitHub 企业存储库。

以下是最 常见的策略：

• 临时：顾名思义，这里完全没有策略。 环境是随机创建的；即使是默认环境也用于托管 生产工作负载。

• 部门级：组织中的每个部门都有自己的环境。 人力资源、财务、销售、运营及所有其他部门都有专用的生产环境，在其中托管和执行多个解决方案。 这些部门环境还可以有开发和测试环境，有时这些环境是与更多的 业务单元共享的。

• 基于项目：大型 工作负载有专用的开发、测试和生产环境。 这些项目会有开发、测试、生产环境，但较小的解决方案仍然存在于 部门环境中。

• 多租户：开发人员 在不同的租户中工作，以创建和开发 Power Platform 解决方案。 高级自动化的管道和工作流将解决方案部署到 生产租户的测试和生产环境。

下图展示了结合部门级和基于项目策略的典型部门环境策略，基于 项目需求：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_5.jpg

图 4.5 – 一个业务单元的环境策略

这里有 共享的开发、共享的测试和共享的生产环境，用于在业务单元内部共享的工作负载。 小型工作负载和/或部门广泛使用的应用程序在这里托管。 复杂的解决方案将获得专用的基于项目的环境，包括开发、测试和生产环境类型（参见 Proj (n) Dev – Proj (n) Test 和 Proj (n) Prod，其中 n 表示唯一项目的数量）。

还有专门的环境用于培训和 Power Platform 的高级用户，他们会试验新功能。 例如，这是唯一一个启用了过程挖掘附加组件供测试的环境。 个人生产力为业务用户提供一个沙箱环境，供他们进行个人实验 用例的测试。

需要特别注意的是，这个概念为每个业务单元提供了隔离的环境，确保这些环境在部门内的治理、合规性和安全控制。 其他业务单元完全无法访问这些环境。

为了在全球拥有多个站点的全球组织中扩展这一概念，我们建议采用以下方法：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_6.jpg

图 4.6 – 全球组织的环境策略

办公室 A/部门 A 代表 一个在区域/国家 A 内部的业务单元，使用一个共同的租户。 每个地区和办公室（业务单元或部门）都拥有相同的结构，并根据性能（靠近最终用户）和合规性要求（数据驻留要求）共享和专用环境。 解决方案的开发可以在这个租户中进行，但该概念允许我们使用更多租户进行开发。 自动化在这里是不可避免的。 ALM 和 DevOps 工具帮助我们根据项目需求自动创建环境，并将解决方案自动部署到不同的地理位置，甚至是 不同的租户。

Power Automate 流程

Power Automate 流程 与 Power Platform for Admins V2 连接器结合，在平台内提供类似 ALM 和 DevOps 的功能。 我们可以使用一些活动来创建环境、分配安全角色，并设置 DLP 策略。 这个连接器还支持跨租户集成，这是一种先前描述的多租户概念，属于 环境策略之一。

环境策略不仅仅关注 Power Platform 中的环境，它还描述了与其他周围服务的交互。 它定义了是否需要为任何新环境或新项目创建一个新的 Azure 订阅 ，或者仅在现有的 Azure 订阅中创建一个资源组。 它还为 ALM 过程提供了指导方针，例如 Proj (n) 应将其工件（托管和非托管解决方案）存储在 一个新的 Azure DevOps Services 项目中，或者存储在该 GitHub Enterprise 代码库中。 最后 但同样重要的是，该策略涵盖了安全性考虑因素，例如在环境创建过程中为管理员、开发者、制造者和用户创建 Microsoft Entra ID 安全组。 当我们完全 定义这些围绕环境策略的领域时，我们部分地解决了 DevSecOps 原则。

在熟悉环境策略的概念后，让我们深入了解第一个 Power Platform 管道，它可以在 一个部门内部部分管理这种方法。

托管管道 – 我们的第一个 CI/CD

现在我们已经 具备了一切 创建我们第一个 Power Platform CI/CD 管道的条件，借助平台内置的功能。

Power Platform 管道

Power Platform 管道 是由平台管理的 CI/CD 管道。 它们提供 ALM 功能，可以以完全自动化的方式构建和部署我们的解决方案，而无需深入了解 DevOps 工具，如 Azure DevOps Services 或 GitHub Enterprise。 当然，我们可以将这些工具集成到我们的托管管道中，将托管和非托管解决方案存储在 Git 仓库中，但这不是强制性的。 Power Platform 管道的理念是让构建和发布过程民主化，并为管理员 和开发者提供一个易于配置和使用的体验。

平台管道是一个 Dynamics 365 应用，我们需要在我们的环境之一中安装它。 对于内置的管道管理，我们只需拥有托管环境；无需 Dynamics 365 许可证。 强烈建议为安装此应用创建一个专用环境。 该环境被称为 主机环境 ，因为 它托管着管道定义、管道运行历史、安全设置以及部署工件历史，正如以下 图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_7.jpg

图 4.7 – Power Platform 管道中的环境

开发者环境 是开发者或创作者创建和修改解决方案的环境。 测试和生产环境代表 那些 目标环境 ，这些环境通过我们定义的管道部署已托管版本的解决方案。 测试和生产环境必须是托管环境，而开发者环境和主机环境可以是普通环境。 每个管道从一个开发者环境开始，并继续在一个或多个链式的 目标环境中运行。

Azure DevOps 服务管道

Power Platform 管道 Dynamics 365 应用 采用底层 Azure DevOps 服务管道和 Azure DevOps 服务部署组的完全托管方式。 这一切对我们是完全隐藏的，作为 Azure DevOps 服务上的一个 SaaS 功能提供。

作为托管环境的高级功能之一，名为 Power Platform 管道的 Dynamics 365 应用将以下 Dataverse 表带到 主机环境中：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_8.jpg

图 4.8 – Power Platform 管道在主机环境中的 Dataverse 表

部署工件， 部署环境， 部署管道， 部署阶段， 部署阶段运行，和 部署阶段运行子操作 是标准的 Dataverse 表，我们也可以使用它们基于不同的触发条件创建审批流程。 该 部署工件 表格回溯存储了由管道创建的托管和非托管解决方案。 托管和非托管解决方案的最大大小为 128 MB。

除了这些表，Power Platform Pipeline 在 主机环境中引入了两个额外的安全角色：

• 部署管道管理员：此角色的所有者可以在 部署管道 配置中创建部署 配置。 这是一个由 Power Platform Pipelines D365 应用安装的模型驱动应用，帮助管理员配置存储在上述 Dataverse 表中的环境、阶段和管道。

• 部署管道用户：此角色的所有者可以在相应的环境中使用在部署管道配置应用中创建的管道。 如果该用户有权访问该环境，并且来自 部署管道 表格的管道记录与他们共享，那么他们有资格在该环境中的任何解决方案中使用该管道。

在解决方案视图中， Pipelines 选项卡的用户（开发者）体验如下：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_9.jpg

图 4.9 – 解决方案中的 Pipelines 用户体验

我们处于一个解决方案中（编辑一个非托管解决方案），当配置了管道时，左侧将显示一个额外的 管道 选项卡。 在我们的示例中，下拉框中有一个管道，目标是两个环境：首先是测试环境，然后是生产环境。 由于该用户通过共享的 Dataverse 部署管道表的行访问更多的管道，下拉框提供了 更多选择。

为了能够从源环境执行在部署管道配置工具中配置的管道，必须满足以下条件：

• 我们需要与制造者共享管道记录（读取权限）。 我们应该使用适当的 Microsoft Entra 组来赋予他们这个权限。

• 我们需要具有从源环境导出解决方案的权限，并且需要具有将解决方案导入到目标环境的适当权限。 内置的 系统自定义者 和 环境制造者 安全角色具有 这些权限。

然后，管道默认会代表触发操作的用户部署管理解决方案。 如果我们希望使用服务帐户而不是用户，则支持使用服务主体。 在这种情况下，解决方案导入到目标环境是由分配的服务主体代表进行的，主要的安全优势是只有服务主体能够访问 生产环境。

部署管道的真正优势在于，我们可以在 CD 管道中引入那些额外的 质量门 ，正如我们在 第一章 中讨论的那样，通过在新版本解决方案部署到目标环境之前构建我们自己的部署审批逻辑（发布审批）。 这些质量门可以从非常简单的发布经理审批到高级自动化测试执行不等。 在每个 部署阶段 都有一个 预部署步骤要求 选项，我们可以使用该选项通过 Power Automate Cloud Flow 触发基于自定义逻辑的审批流程。 部署请求将处于待审批状态，直到获得批准。 下图显示了在部署管道配置工具中 预部署步骤要求 和 预导出步骤要求 选项：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_10.jpg

图 4.10 – 在部署管道配置工具中创建新的部署

借助 导出前步骤要求，我们可以引入在解决方案首次从开发环境导出为托管和未托管解决方案之前执行的自定义验证逻辑。

质量门控中涉及的 云流应在主机环境中创建，其触发条件为 Dataverse 操作。 我们可以创建多个云流来响应同一个 管道事件。

目前，使用 托管管道存在一些限制：

• 多个开发者在专用的开发环境中协作同一解决方案时，需要更谨慎的流程以避免覆盖彼此的更改。 目前，管道只支持从开发环境到生产环境的单向流动。 这意味着将解决方案的最新版本拉取并部署到不同的开发环境中需要谨慎且 手动干预。

• 回滚功能部分支持。 我们已经可以在 Power Platform 管道中将解决方案的早期版本重新部署到目标环境，但我们无法像 一个步骤一样回滚整个多阶段管道。

逐步操作指南 – 创建我们的第一个 CI/CD 管道

让我们使用 Power Platform 管道创建我们的 第一个端到端的 CI/CD 管道 。 我们将做的是从 GitHub 仓库中选取一个环境模板和一个可用的解决方案。 我们将使用这些设置一个管道，将解决方案的托管版本从未托管版本中构建出来，并将其从开发环境部署到 生产环境：

1. 安装 PAC CLI（假设.NET 6.0 已安装在 我们的环境中）：

   dotnet tool install --global Microsoft.PowerApps.CLI.Tool

2. 安装 PowerShell 模块：

   Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

3. 为托管托管管道创建一个环境。 此环境将代表管道的主机环境。 我们应选择与我们开发、测试和生产环境相同的区域创建环境：

   #Authentication – in both toolsAdd-PowerAppsAccountpac auth create#Create Host Environment - Pipelinehost$result=New-AdminPowerAppEnvironment -Location europe -DisplayName \'Pipelinehost\' -ProvisionDatabase -EnvironmentSku Production

4. 安装 Power Platform Pipelines Dynamics 365 应用。 PAC CLI 提供了一种简便的方式将 Dynamics 365 应用安装到环境中 （截至本书写作时没有 PowerShell cmdlet）：

   #Install Power Platform Pipelines to \"Pipelinehost\"#It takes approx. 5 minutespac application install ` --environment $resultNewEnvironment.EnvironmentName ` --application-name \"msdyn_AppDeploymentAnchor\"

5. 创建一个 开发环境：

   pac admin create ` --name \"DevelopmentEnvironment\" ` --currency EUR ` --region europe ` --type Sandbox

6. 创建目标环境（托管 和生产）：

   #Create a production environment$resultProductionEnvironment=New-AdminPowerAppEnvironment -DisplayName \'Production\' ` -ProvisionDatabase ` -Location europe ` -EnvironmentSku Production#Turn on Managed Environmentpac admin set-governance-config ` --environment $resultProductionEnvironment.EnvironmentName `Pipelinehost environment:1. Start the application.2. Go to **Environments** under **Pipeline Setup**, open it, and click on the **New** button at the top.3. Fill out it with the data of your developer environment as the following figure shows:

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_11.jpg

图 4.11 – 创建新的部署环境

1. 创建 另一个 部署环境 ，并使用您最近创建的生产环境的配置数据 以及 环境类型 目标环境，请参阅之前的图示以获取详细信息。

提示

使用 pac admin list 命令获取您最近创建的环境的环境 ID。

1. 前往 PipelineToProd 名称并保存表单，以便能够完全配置它。 如果我们希望获取 AI 部署笔记，可以在这里启用： 同样：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_12.jpg

图 4.12 – 新的部署管道详细信息

1. 添加 开发环境（开发环境）到 已链接的开发 环境 部分。

2. 点击 新建部署 阶段 按钮，创建一个新的部署阶段。

3. 设置 名称 和 目标部署环境 ID 字段。

4. 保存 记录。

5. 设置 安全性：

   1. 将此新的部署管道 Dataverse 记录共享给开发环境中将使用此管道的用户或用户组，即 开发环境 ，在我们的例子中。

   2. 将 系统定制器 或 环境创建者 内建安全角色添加到这两个成员的 生产 和 开发环境 环境中。

   3. 将 部署管道用户 安全角色添加到 管道主机 环境中的这些成员。

6. 前往 开发者环境并导入 未管理的解决方案 从 Power Platform 企业模板中导入 IT 基础包。 你可以在 以下位置找到它： https://github.com/microsoft/Templates-for-Power-Platform/blob/main/Solution%20Packages%20For%20Manual%20Install/IT/IT%20Base%20Pack/mpa_ITBase_managed.zip。

7. 打开解决方案并寻找左侧的流水线图标（看起来像火箭）。 打开流水线并选择 PipelineToProd 流水线：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_13.jpg

图 4.13 – 选择 PipelineToProd

1. 点击 pac pipeline deploy 命令。

2. 检查 生产环境中的部署结果。

恭喜，我们已经创建了我们的第一个 CI/CD Power 平台流水线。

为了让这个 流水线更加专业和安全，我们 可以在 Microsoft Entra ID （在 Microsoft Azure 门户内）创建一个服务主体和企业应用，并将其分配给部署阶段，如下图所示： 。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_14.jpg

图 4.14 – 在流水线中使用服务主体

这就是 委托部署 过程 ，我们通过它将 我们的 服务主体名称 （SPN）客户端 ID 分配给流水线引擎，以便它在解决方案导入阶段使用。 创建此分配后，我们需要做最后一件事。 这就是创建一个委托的审批流程，通过使用服务主体及其客户端密钥连接到 Power Platform 流水线 Dataverse 表格，以批准部署。 下一个图将展示最简单的审批流程，通过响应 OnApprovalStarted Dataverse 动作，等待五秒钟，然后将审批状态设置为 20（20 表示已批准；30 表示 拒绝状态）：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_04_15.jpg

图 4.15 – 使用服务主体的委托部署

底层 Power Platform 流水线引擎使用 此流程代表定义的服务主体而非用户执行。 通过这些额外的步骤，我们显著提高了 我们流水线的弹性和安全性。

总结

在本章中，我们了解了 Power Platform 解决方案，这些现代可执行文件可以在环境之间移动，了解了它们的升级选项，以及如何实现解决方案分层和版本管理的不同方法。 之后，我们讨论了 Dataverse，这是一款具备高级安全性和治理能力的企业级数据平台。 我们还了解了 CDM，这是一个行业广泛接受的用于建模数据的数据库模式。 我们还花时间了解了环境，它是我们解决方案的执行主机，了解了托管环境的高级功能，并详细阐述了大规模全球企业的环境策略。 在本章的最后，我们学习了 Power Platform 流水线——作为托管环境的最大特色之一——如何在幕后工作。 我们还成功创建了我们的第一个 CI/CD 流水线。

在下一章中，我们将探索用于创建这些 CI/CD 流水线和其他 ALM 自动化的专业开发者工具，部分内容我们已经在 Power Platform 流水线中看到过。

进一步阅读

• 解决方案 层： https://learn.microsoft.com/en-us/power-apps/maker/data-platform/solution-layers

• 常见数据 模型 (CDM):

  • https://learn.microsoft.com/en-us/common-data-model/use

  • https://github.com/microsoft/CDM

• 解决方案 修补： https://learn.microsoft.com/en-us/power-platform/alm/create-patches-simplify-solution-updates

• 托管 环境： https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview

• 环境 策略： https://learn.microsoft.com/en-us/power-platform/guidance/adoption/environment-strategy

• 企业 模板： https://github.com/microsoft/Templates-for-Power-Platform

• Power Platform 管道： https://learn.microsoft.com/en-us/power-platform/alm/pipelines

• Microsoft Entra ID 服务 主体： https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals

• 管道中的 服务主体： https://learn.microsoft.com/en-us/power-platform/alm/delegated-deployments-setup

第五章：通过 DevOps 工具简化 Power Platform 开发

在上一章中，我们使用服务主体创建了第一个 Power Platform 管道，将我们的解决方案从一个环境部署到另一个环境。 本章介绍了可以帮助我们简化 Power Platform 开发过程的专业开发 DevOps 工具。 第一个工具是 clone， push， pull， checkout等。 我们还将探索如何在 Git 仓库中管理 Power Platform 解决方案的纯文件和文件夹，以及如何通过命令行进行拉取请求和合并。 然后，我们将学习如何将 Power Platform 管道连接到这些 Git 仓库。 我们将花时间介绍 Power Platform CLI (PAC CLI)，它 允许我们在任何脚本语言中与 Power Platform 解决方案进行交互。 我们还将学习如何在 YAML (即 Yet Another Markup Language) 格式中创建 Azure DevOps 服务管道，并 理解 YAML 规范及相关方法，如变量、参数和任务。 我们还将了解 Microsoft 为 Power Platform 解决方案提供的构建任务。 最后，我们将学习 如何使用 GitHub Copilot，一个 AI 驱动的代码补全工具，可以帮助我们更高效地编写代码 。

本章结束时，我们将深入理解并掌握如何通过专业开发的 DevOps 工具（如 Azure DevOps pipelines 和 GitHub Actions）来设置端到端的 CI/CD 管道，这些工具将我们的解决方案交付到不同的 Power Platform 环境中。

在本章中，我们将涵盖以下 主要内容：

• Git – 单一的真实来源 真理之源

• Power Platform CLI

• Power Platform 构建工具用于 Azure DevOps

• GitHub Actions for Power Platform

• 托管管道 – 源 控制集成

• Power Platform 中的 Copilot 管道开发

技术要求

要使用专业开发的 DevOps 工具创建我们的第一个 CI/CD 管道，我们需要具备 以下条件：

• 一个 Power Platform 订阅。 如果我们已经拥有 Microsoft Entra ID 工作帐户，我们可以注册 Power Apps 开发者计划（https://www.microsoft.com/en-us/power-platform/products/power-apps/free）。 或者，我们可以加入 Microsoft 365 开发者 计划（https://developer.microsoft.com/en-us/microsoft-365/dev-program）。。

• 一个 Azure DevOps Services 组织：我们可以随时创建一个 DevOps 组织 免费 （https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates）。 如果我们在 Azure DevOps 中创建一个公共项目，我们将获得多个免费管道并免费访问该服务的所有功能 – 请参见 Azure DevOps for Open Source 优惠。

• GitHub 用户名和公共仓库（https://github.com/signup），该仓库也 免费 提供给 公共仓库。

• GitHub Copilot 免费试用（https://github.com/login?return_to=%2Fgithub-copilot%2Fsignup）或访问 Microsoft Copilot（https://copilot.microsoft.com）。

• Visual Studio Code – 强烈建议使用这个免费的代码编辑器来创建、编辑和更新本章节中的 YAML 文件。 我们可以通过 https://code.visualstudio.com/download在任何平台上下载 Visual Studio Code，并借助 Power Platform、Git、Azure DevOps 管道和 GitHub 工作流的 VS Code 插件，我们可以对更改进行语法高亮和语义检查。 通过 Git 插件，我们还可以管理 Git 仓库。 有关更多信息，请参见 进一步阅读 部分，了解 Visual Studio Code 的更多内容。 另外，我们可以直接访问 https://vscode.dev 在我们喜欢的浏览器中在线使用 Visual Studio Code 编辑器，编辑任何文件并打开一个 远程仓库。

• 本章节的代码文件可以从我们的 GitHub 仓库下载 ，链接为 https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform/tree/main/Chapter05。

Git——单一的真理来源

在定制开发项目中，源代码保存在 版本控制系统中。这些 系统允许开发人员在同一个代码库上协作工作，以便他们可以不断引入新功能和/或修复 bug，而不会与他人的更改冲突。 我们使用此类代码库（版本控制系统）的原因之一是提供生产环境中的代码（运行中的应用程序）与在推送版本到生产环境之前所做的源代码更改之间的端到端前后追溯性。 在现代的 DevOps 工具中，项目管理部分，开发工作项直接与开发人员所做的代码更改相链接。 版本控制系统提供了项的历史，并支持跨多个文件和文件夹的事务性更改，这些更改存在于代码库中。 这些更改 通常以 作为 版本或 历史树的形式表示。

为了让开发人员以最有效和高效的方式工作 并行，版本控制系统提供了分支功能。 一个 分支，顾名思义，是代码行的快照——一个分支，它随后 管理自己的历史。 我们提交（回放）到此分支的更改在我们创建分支时的原始分支中不可见。 主线或根——主分支本身——在这种方法中也被表示为一个分支。 在子分支中完成待办事项后，我们 合并 这些更改回父分支。 分支可以在任何深度上创建，但一般来说，我们建议保持分支层次结构的深度尽可能平坦，以避免后续的集成债务。 分支将进行中的工作与稳定且 已测试的代码分开。

为了维护和控制一个健康的开发环境，我们需要定义我们的分支策略。 一个 分支策略 是管理版本控制系统中分支的一组指南和最佳实践。 它帮助团队组织代码库、简化开发流程，并在合并代码时尽量减少冲突。 有几种流行的分支策略。 团队需要选择适合他们开发流程的分支策略，并且要始终如一地遵循它，以确保顺畅的协作和高效的代码管理。 让我们来看一下最流行的两种 分支策略：

• 基于主干的开发 是一种 版本控制管理实践，开发人员将小的、频繁的更新合并到一个核心分支 叫做 主干 或 主分支。这种方法的主要特点是，唯一长期存在的分支是主分支，且始终可部署。 开发人员不能直接将更改提交到主分支，而是他们在短期分支上工作，并将更改频繁地合并到主分支。

• Git Flow / GitHub flow 最初是 Git Flow 定义了几个长期存在的分支，比如 发布、热修复和补丁分支，旁边还有主分支。 在过去十年里，软件行业发生了很大的变化，软件开发团队通常只维护一个版本的软件——即最新版本。 这意味着不再需要维护这么复杂的分支层次结构，这也是从 Git Flow 转向 GitHub flow 的原因。 GitHub flow 是一种 轻量级、基于分支的工作流，支持定期进行部署的团队和项目。 这个工作流在开发人员中非常受欢迎，因为它允许他们在不影响主代码库的情况下，进行新特性的开发、修复 bug 或进行实验。 一旦某个分支上的工作完成，就可以通过拉取请求将其合并回主代码库。 GitHub flow 与基于主干的开发非常相似，但它包含了 GitHub 特有的功能，如 拉取请求。

Git 是 最广泛使用的版本控制系统。 它是一个 分布式版本控制系统，这意味着我们可以将一个代码库下载到自己的开发机器上，并且在没有互联网连接的情况下，我们可以通过分支和修改来工作。 当然，如果我们想要将我们的更改传播回团队，我们需要连接互联网并 上传 我们的更改。 市场上也有 集中式版本控制系统。 这些系统需要持续的互联网连接，这通常会减慢与此类代码库的交互速度。 一般来说。

Git 是一个 快速、可扩展、分布式的版本控制系统，并且是开源的。 有很多 DevOps 工具提供了开源 Git 引擎，比如 GitHub Enterprise、Azure DevOps Services 和 GitLab。 当然，这些引擎是经过定制的，服务提供商可以实现 他们自己的操作方式，并将 Git 提供为 软件即服务 （SaaS）产品，但客户端 API 与任何这些分发版本兼容。 这些分发版。

通常，版本控制系统 管理纯文本文件，因为这些文件在发生冲突时可以被开发者合并（冲突是可读的）。 随着软件历史的发展，越来越多的二进制文件，如图像、视频、音频文件、3D 对象和媒体文件，已成为软件解决方案的一部分。 在软件开发的早期，这些文件与代码库并行维护，尽管它们也是由开发者修改/分支的版本的一部分。 Git 已经支持大文件 （Git 大文件存储）和大规模单体代码库，简化了从其他版本控制系统的迁移。 控制系统的迁移。

单体大规模代码库

例如，Microsoft Windows 的代码库，大小为 250 GB，维护在一个大型的 Git 单体代码库中，并托管在 Azure DevOps 服务项目中。

Git 命令行界面 (CLI) 是一个 强大的工具，允许开发人员使用命令行终端与 Git 仓库进行交互。 Git CLI 可在所有主要操作系统上使用，包括 Windows、macOS 和 Linux。 一些常用的 Git 命令有： 以下是一些：

• git clone: 这个 命令 用于在你的 本地机器上创建远程仓库的副本。

• git pull: 这个 命令用于从远程仓库获取并合并更改到你的 本地仓库。

• git push: 这个 命令用于将本地仓库的更改（提交和分支）上传到 远程仓库。

• git commit: 这个 命令用于将更改保存到本地仓库。 它会在仓库历史中创建一个新的 提交 对象，记录仓库的当前状态。

• git branch: 这个 命令用于管理 Git 仓库中的分支。 它可以用于列出、创建、删除以及 重命名分支。

• git checkout: 这个 命令用于在分支之间切换，或者从 版本库中恢复工作目录中的文件。

• git merge: 这个 命令用于将一个分支的更改合并到另一个分支。 它将指定提交的更改集成到 当前分支。

通常，我们克隆一个仓库，创建一个本地分支，提交更改，将分支推送回远程源，最后将更改合并回主分支。 这个最后的操作是一个特殊操作，根据不同的 Git 发行版，可能被称为拉取请求，如 GitHub 或 GitLab。 我们也可以在没有拉取请求的情况下合并分支。

拉取请求 是一个 开发人员通知团队成员他们已完成一个功能的机制。 一旦他们的功能分支准备好，开发人员就会通过在线代码库提交拉取请求。 然后，其他团队成员会审查代码并提出意见和建议。 一旦团队达成一致，认为代码已经准备好，就可以将其合并到主代码库中。 拉取请求是一个促进代码审查 和团队协作的方式 在 开发团队中。

拉取请求

拉取请求 不仅仅是一个 git merge 操作。 像 GitHub 或 Azure DevOps 服务这样的 DevOps 工具提供了网页 UI 支持以及自己的 CLI 工具来发起拉取请求 在分支上。

理解了 Git 的关键概念后，我们来看一下它是如何与我们的 Power Platform 解决方案结合的。 正如我们之前讨论过的，在 第四章中，Power Platform 解决方案 有托管和非托管两种格式。 根据解决方案的内容，托管和非托管解决方案之间的区别可能会有很大差异。 例如，如果一个解决方案包含 PowerApps 应用程序，那么托管的解决方案会包含几个文件，其中一个是 msapp 文档，其中包括 PowerApps 画布应用的所有资产，以压缩格式保存。 另一方面，非托管解决方案将由 XML 和 JSON 文件组成，按照一个定义明确的文件夹结构来描述解决方案及其所有资产，如应用程序、流程、机器人、连接引用等，以纯文本 格式表示。

而这正是版本控制系统发挥重要作用的地方，正如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_1.jpg

图 5.1 – 开发者环境及其相应的子分支

应用开发者和开发人员（DevA 和 DevB 在我们的案例中）使用专门的开发环境来构建解决方案。 当他们创建应用程序的第一个版本时，他们将托管和非托管的 Power Platform 解决方案——后者作为解包形式——提交到自己从主分支创建的子分支中。 之后，他们在这些分支上工作，并在相应的环境中进行工作，通过不断同步环境与分支之间的变化。 当他们准备好时，他们提交拉取请求，将子分支中的更改合并回主分支。 理想情况下，没有合并冲突，变更会顺利地集成到主分支中。 合并冲突 是 冲突的更改——即在父分支和子分支中相同位置的文件发生了变更。 如果发生合并冲突，拉取请求将被拒绝，开发人员需要将主分支的更改合并回开发分支，并在那里解决冲突。 在 Power Platform 中，这不仅仅意味着解决代码层面的冲突，还需要将非托管解决方案加载回开发环境，检查一切是否按预期工作，然后发布更改。 之后，我们需要将解决方案导出回开发分支，并重新提交 拉取请求。

总体而言，分支和子分支使得开发人员即使在同一个 Power Platform 解决方案中也能并行工作，但我们需要特别注意，让开发人员处理不同的资产 在解决方案中。

了解了 Git 的功能后，让我们来了解一下我们可以用来导出和导入解决方案的工具 Power Platform。

Power Platform CLI

我们在前几章中已经见过一些 PAC CLI 命令，例如登录到不同的环境或将 Power Platform 管道作为 Dynamics 365 应用程序安装到我们的环境中。 除了这些命令，PAC CLI 还支持许多其他命令和功能，我们可以代表服务主体进行身份验证，并管理我们的解决方案、环境、部署、管道等。 PAC CLI 的最大优势之一是它可以在任何平台上运行，并可以与任何 DevOps 工具集成。

PAC CLI 最常用的命令之一是 以下这些：

• The pac admin 命令 组提供一组命令，用于与您的 Power Platform 管理员帐户一起工作，例如创建环境、创建服务 主体、将 Microsoft Entra ID 组分配给环境等。

• The pac application 命令 组用于列出并安装来自 AppSource 的可用 Dataverse 应用程序。 我们使用了 pac application install 将 Power Platform 管道作为 Dynamics 365 应用程序部署到我们的生产环境中， 第四章。

• The pac auth 命令 组提供一组命令，用于在不同的服务中进行身份验证，例如环境或整个租户。 我们可以使用服务帐户以及服务主体。 我们的凭证会被本地存储 （如有需要）。

• The pac canvas 命令 与 Power Apps .msapp 文件 一起使用。这些文件是在我们直接从 Power Apps Studio 导出画布应用程序时创建的，或者作为我们 Power 平台解决方案。

• The pac catalog 命令 组提供用于管理 pac catalog 命令组的命令，包括 pac catalog install ，它将在目标环境中安装目录项，以及 pac catalog list ，它列出当前 Dataverse 组织中的所有已发布目录项。

• The pac copilot 命令 组提供用于管理聊天机器人和 AI Builder 模型的命令（包括新型大语言模型等）。 一些可用的命令包括 pac copilot predict ，该命令将文本或提示发送到 AI 模型， pac copilot create 用于使用现有模板文件作为参考创建新机器人， pac copilot list 用于列出当前或目标 Dataverse 环境中的虚拟代理。

• The pac package 命令组是一组用于管理包的工具和实用程序。它包括一些命令，比如pac package add-external-package用于将一个外部的包添加到 Dataverse 解决方案系统中，pac package add-reference用于向 Dataverse 解决方案项目中添加引用，以及pac package add-solution用于将一个预构建的 Dataverse 解决方案文件添加到 Package Deployer 项目中。请注意，我们在第四章中也讨论了 Power Platform 企业模板中的 Package Deployer。

• The pac pcf 命令组用于与pac pcf init一起初始化当前目录中的新 Power Apps 组件框架项目，并且与pac pcf push一起将组件推送到 Power Apps 组件框架开发环境中。

• The pac pipeline 命令组用于与 Power Platform 管道一起工作。举例来说，pac pipeline deploy 用于启动管道部署，而pac pipeline list 用于列出给定环境中的管道。此命令组为管理员和操作团队提供了以完全自动化的方式启动部署的选项，正如我们在第四章中讨论的那样。

• The pac plugin 命令组用于与pac plugin init一起初始化一个新的 Dataverse 插件类库目录，而pac plugin push则用于将插件导入到 Dataverse 中。我们可以使用基于.NET Framework 的插件，在 Dataverse 引擎的上下文中响应服务器端的 Dataverse 事件。

• pac powerpages 命令组 用于 管理 pac powerpages list 用于列出当前 Dataverse 环境中的所有 Power Pages 网站，而 pac powerpages download 用于从当前 Dataverse 环境下载 Power Pages 网站内容，以便将其迁移到另一个环境，配合 pac powerpages upload。

• pac solution 命令组 用于操作 与 pac solution 命令组包括 pac solution init，用于初始化一个基于 MSBuild 的 cdsproj 文件，适用于组件框架组件； pac solution add-reference，用于将当前目录中的项目引用添加到指定路径下的项目；以及 pac solution add-solution-component，用于将一个或多个解决方案组件添加到 Dataverse 中的目标非托管解决方案。 解决方案的导入和导出也通过相应的 pac solution 命令进行支持。

PAC CLI 和 Power Platform PowerShell 模块

PAC CLI 是 Power Platform 的下一代命令行工具，能够在任何操作系统平台上运行。 PowerShell 管理功能正在不断迁移到 PAC CLI，以便在未来达到功能上的一致性。 PAC CLI 和 PowerShell 模块是对 Power Platform 的底层 REST API 端点的封装。

要安装 PAC CLI，我们需要先确保机器上已部署 .NET Core 3.1 或更高版本（推荐使用 .NET 6）。 然后，我们可以在喜爱的终端（Windows 上使用 CMD，Linux 上使用 Bash，macOS 上使用 Terminal）中执行以下命令：

 dotnet tool install --global Microsoft.PowerApps.CLI.Tool

现在我们已经了解了 PAC CLI 中命令的广度和深度，在接下来的章节中，我们将了解该 CLI 工具如何被 Azure DevOps Services 和 GitHub Enterprise 使用。

Power Platform 构建工具用于 Azure DevOps

Azure Pipelines 作为 Azure DevOps Services 中的一个强大功能脱颖而出，提供 全面的 持续集成 （CI）和 持续交付 （CD）服务。 它兼容您选择的 Git 提供商（GitHub 或 Azure DevOps），并支持跨多个主要云提供商进行部署，包括微软 Azure。 此服务简化了构建、测试和部署代码库的过程。 它支持广泛的编程 语言和平台，例如 .NET、Java、Node.js、Android、Xcode 和 C++，并支持使用各种测试框架和服务。 此外，Azure Pipelines 还支持在命令行、PowerShell、Bash 或 Shell 中执行脚本，作为自动化工作流的一部分。

Azure Pipelines 还提供了运行脚本和流水线任务所需的基础设施。 Azure Pipelines 代理 是 容器（虚拟机规模集中的虚拟机），执行我们的作业（流水线任务）。 代理被安装在这些机器中，并通过 HTTP 出站连接到 Azure DevOps 端点，拉取它们需要执行的活动。

代理有不同类型，包括微软托管代理、自托管代理和 Azure 虚拟机规模集 代理：

• 微软托管代理 提供了一个 无忧的解决方案，用于执行您的作业。 这些代理由微软全面管理，确保始终使用您 YAML 流水线中指定的最新虚拟机映像，而无需我们进行任何维护或升级。

• 自托管代理 是 我们在自己的虚拟机上设置并维护的代理。 此选项使我们能够更好地控制代理使用的机器规格和操作系统映像。

• Azure 虚拟机规模集代理 是 一种自托管代理，充分利用虚拟机规模集的自动扩展功能。 Azure DevOps 根据 流水线队列的大小扩展或缩减虚拟机。

在 Azure Pipelines 中， 作业 是一系列按顺序运行的步骤，作为一个单元执行。 每个管道至少有一个作业，作业是可以调度运行的最小工作单元。 作业可以组织成阶段，并且你可以指定条件和依赖关系来控制作业的运行时机。 作业可以在 Microsoft 托管的代理、自托管的代理或 Azure 虚拟机规模集代理上运行，并且可以直接在代理的主机机器上或在容器中运行。 Azure Pipelines 支持在 Linux、macOS 和 Windows 上并行运行作业。 你可以在 Azure DevOps Web 门户中创建和配置管道，使用经典的用户界面编辑器，也可以使用最新的基于 YAML 的脚本编辑器。 我们更倾向于后者，因为这种情况下，YAML 文件的版本控制管理也是可用的。

Azure Pipelines 的高级功能，如 Microsoft 托管和自托管构建代理的基础设施和 拓扑，超出了本书的范围，但你可以在 进一步 阅读 部分找到更多信息和学习模块。

在 Azure Pipelines 之上， Microsoft Power Platform Build Tools（Microsoft Power Platform Build Tools for Azure DevOps） 提供了 Azure DevOps 中的附加任务，可用于自动化与 Microsoft Power Platform 上构建的解决方案相关的常见构建和部署任务。 其中一些可用任务包括 Power Platform 工具安装程序，该程序安装 Power Platform 工具（包括 PAC CLI 在代理中的安装）。 这是每个构建和发布管道开始时的必选步骤，尤其是当我们希望使用其他 Power Platform 构建任务时。 这些构建工具适用于画布应用、模型驱动应用、Microsoft Copilot Studio、云端和桌面流程、Power Pages 网站、AI Builder 模型、自定义连接器以及数据流，适用于所有可以添加到 解决方案中的内容。

每个构建任务都在后台使用 PAC CLI，Power Platform 包装器为 Azure DevOps Pipelines 和 GitHub Actions 提供了一个通用接口：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_2.jpg

图 5.2 – Power Platform 构建工具和 GitHub Actions 架构

这意味着，当我们 使用类似 PowerPlatformExportSolution@2 的任务时， 该管道任务会通过包装器执行相应的 PAC CLI 命令， 并使用适当的参数。 让我们来看一个导出受管解决方案的管道，它解压并发布到构建工件中（请参见 .pipelines/powerlatform-exportsolution.yml 文件，位于 Chapter05 文件夹中， GitHub 仓库中）：

 trigger:- nonepool: vmImage: ubuntu-lateststeps: - task: PowerPlatformToolInstaller@2 inputs: DefaultVersion: true - task: PowerPlatformExportSolution@2 inputs: authenticationType: \'PowerPlatformSPN\' PowerPlatformSPN: \'[Service_Connection_Name]\' SolutionName: \'[Our_Solution_Name]\' SolutionOutputFile: \'$(Build.ArtifactStagingDirectory)/Solution/[Our_Solution_Name].zip\' Managed: true AsyncOperation: false MaxAsyncWaitTime: \'60\' - task: PowerPlatformUnpackSolution@2 inputs: SolutionInputFile: \'$(Build.ArtifactStagingDirectory)/Solution/TranslatorSolution.zip\' SolutionTargetFolder: \'$(Build.ArtifactStagingDirectory)/Solution/out\' SolutionType: \'Managed\'- task: PowerPlatformChecker@2 inputs: PowerPlatformSPN: [Service_Connection_Name]\' FilesToAnalyze: \'$(Build.ArtifactStagingDirectory)/Solution/*.zip\' RuleSet: \'0ad12346-e108-40b8-a956-9a8f95ea18c9\'- task: PublishBuildArtifacts@1 enabled: true inputs: PathtoPublish: \'$(Build.ArtifactStagingDirectory)\' ArtifactName: \'Translator\' publishLocation: \'Container\'

The PowerPlatformExportSolution@2 使用服务连接（ PowerPlatformSPN: \'PowerPlatformE5-Default\' ）连接到 Dataverse。 服务连接 允许 您连接到外部和远程服务，以在 您的管道中执行任务。 它们提供了一种方法，能够使用外部服务对 Azure DevOps 进行身份验证和授权， 使 Azure DevOps 能够代表您或代表服务主体访问资源并执行操作。 为 Power Platform 提供了专用的服务连接。

我们刚刚发现，如何使用熟悉的 Azure Pipelines 基于 YAML 的方法来进行 Power Platform CI/CD， 就像我们为其他自定义开发项目所做的那样。

GitHub Actions for Power Platform

GitHub Actions 最初由与创建 Azure Pipelines 相同的工程团队设计和开发， 这是在微软收购 GitHub 后的事情。 在收购时，GitHub 甚至没有支持 Azure Pipelines 提供的任何自动化功能。

因此，GitHub Actions 引擎、基础设施、代理（在 GitHub 中是 runners）和概念与 Azure DevOps 的几乎相同，也不奇怪。 在某些情况下，GitHub Actions 甚至更好。 它可以提供比 Azure Pipelines 更多的触发条件。 例如，GitHub Actions 可以响应 GitHub 问题中的变化——包括拉取请求评论、Wiki 页面上的变化，以及 GitHub 项目相关资产的其他变化。 这些操作是轻量级函数，触发框架可以通过 webhook 轻松扩展。

GitHub 有自己的构建代理，这些代理被称为 GitHub runners。

在幕后，托管 GitHub Actions 的代理运行时、Windows 服务和 Linux/macOS 守护进程与 Azure DevOps 服务中使用的运行时几乎相同。GitHub 运行器是运行 GitHub Actions 工作流的虚拟机。它们有两种类型：GitHub 托管和自托管。对于专业人员，GitHub 提供了一系列托管虚拟机，这些虚拟机具有更多的内存、CPU 和磁盘空间，供 GitHub Team 和 GitHub Enterprise Cloud 计划的客户使用。这些较大的运行器由 GitHub 托管，预装了运行器应用程序和其他工具。GitHub 托管的运行器使 GitHub Enterprise 计划的客户能够轻松、安全地将其 CI/CD 机器连接到云端或本地的其他 DevOps 服务，例如Artifactory、Nexus或任何其他服务，利用保留的静态 IP 范围或通过使用 Azure 虚拟网络来实现。在公共 GitHub 仓库的情况下，每个月前 2,000 分钟的 GitHub 托管运行器执行是免费的。

为了获得更细粒度的控制，您还可以将运行器组与标签结合使用。运行器组只能包含大型运行器或自托管运行器作为成员。这样，专业人员可以灵活选择最适合其特定需求的运行器。GitHub 运行器也可以在 Docker 容器中运行。通过这样做，我们甚至可以轻松地构建基于 Kubernetes 的构建/部署集群。

GitHub 运行器和 Azure DevOps 代理都是开源项目，欢迎来自世界各地的贡献者（请参阅“进一步阅读”下的 GitHub 仓库链接）。

关于工作流定义：YAML 标签和关键字也存在一些差异，但主要设计原则是相同的。

Azure DevOps 服务与 GitHub

在行业中，一个常见的问题是 Azure DevOps Services 还是 GitHub 是未来的趋势。 在撰写本文时，微软的策略是建议绿色场景组织（即刚开始 DevOps 之旅的组织）使用 GitHub。 如果一个组织已经使用了 Azure DevOps，那么微软建议只在能带来显著优势的领域引入 GitHub。 这种显著优势现在体现在 GitHub Copilot。在过去几年中，我们看到对 GitHub 功能的投资比 Azure DevOps Services 大了 5-10 倍。

在下一节中，我们将仔细研究 GitHub 工作流和操作 的实际应用。

管理管道 – 与 Git 的源代码控制集成

在 第四章中，我们创建了第一个 Power Platform 管理的管道，该管道通过服务主体将我们的 mpa_ITBase 解决方案从开发环境部署到生产环境。 在本节中，我们将继续我们的旅程，并基于关于 PAC CLI 的经验，构建针对 Azure DevOps Services 和 GitHub Actions 的工具，为 Power Platform 提供支持，我们将借助 GitHub Actions for Power Platform 和 Power Platform 管道上下文中的 Dataverse 触发事件，将我们的解决方案构件提交到 GitHub 仓库。

让我们来看看在我们的 Power Automate 云流中，可以在 Pipelinehost 环境中使用的事件，以响应部署管道中的某些变化：

• OnApprovalStarted – OnApprovalCompleted：当部署阶段配置了审批流程时，这些事件会在部署解决方案之前触发。 我们通常使用这一步骤通知发布经理或环境拥有者关于 计划部署的情况。

• OnPredeploymentStarted – OnPredeploymentCompleted：这些事件在将我们的解决方案发布到部署阶段之前发生。 我们可以利用这些事件在目标环境中做一些配置，比如在解决方案部署前更新环境变量和导入（静态）数据。

• OnDeploymentRequested – OnDeploymentStarted – OnDeploymentCompleted：这些事件发生在将解决方案部署到 部署阶段的过程中。

Dataverse 管道事件

Dataverse Power Platform 管道相关事件在每个部署阶段触发，无论阶段和管道的数量如何。 管道触发器提供额外的属性来过滤出我们感兴趣的管道和阶段。

借助这些 构建模块，我们可以制定不同的策略，来管理我们的管道以及如何在 Power Platform 环境之外维护我们的解决方案。 我们应该决定 以下事项：

• 我们是否为每个解决方案使用单独的 Git 仓库？ 或者，我们是否计划将多个解决方案存储在同一个 Git 仓库中？ 我们是否计划引入管道模板化以便于 重用？

• 我们是否为每个环境引入一个 Git 仓库？

• 我们是否计划将部署到不同部署阶段的解决方案工件存储在不同的 子分支中？

• 我们是否使用拉取请求将子分支中的最新更改合并回主分支？ 我们是否在管道中使用拉取请求触发器以完成生产环境中的部署？ 这也意味着受管管道不会到达生产环境，仅到达 预生产/测试环境。

• 我们是否计划只存储已经成功部署到生产环境的部署工件在主分支上？ 我们是否应该考虑分支策略 呢？

没有万灵药来回答这些问题，因为所选的策略真正取决于组织的成熟度、项目的复杂性以及内部定义的整体 DevOps 流程。 。

下图展示了一种可能的方法，通过 Power Platform 管道在部署到生产环境后将解决方案提交到主分支：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_3.jpg

图 5.3 – Git 与 Power Platform 管道的集成

我们通过 Power Platform 管道启动的部署过程中， 生成了托管和非托管解决方案。 当托管管道运行时，其他开发人员无法排队执行此管道，从而保证了互斥性。 生成的工件存储在 Dataverse DeploymentArtifacts 表格中，位于 Pipelinehost 环境中。 随着包（托管解决方案）通过管道阶段（测试 和 生产 环境，以我们为例），前述事件会被触发。 我们使用 OnDeploymentCompleted 事件来执行我们的云流，它将通过 HTTP POST调度我们的 GitHub 工作流，并下载部署工件，解压并提交到 主分支。

为了能够从 Dataverse 下载工件，我们创建一个服务主体，并在 GitHub 流程中使用 Bash 脚本直接调用 Dataverse Web API，通过 OData 协议 下载我们的部署工件。

让我们使用 PAC CLI 创建一个服务主体，供我们在 GitHub 工作流中使用：

 # First we need to authenticatepac auth create# List our environments to find the URL of the environment hosting our Power Platform pipelines (HOST)pac admin list# Create the service principalpac admin create-service-principal -env <> -n VersionControlSPN --role \"System Administrator\"

最后的调用 不仅需要在 Power Platform 租户中具有管理员权限，还需要在 Microsoft Entra ID 中具有管理员权限（ Application.ReadWrite.Allpermission 角色）。 该调用的输出包含应用注册的客户端密钥、应用 ID（客户端）和租户 ID，以及相应的企业应用。 此命令还通过将其作为应用用户添加到环境中，将该服务主体注册到 Dataverse。 我们需要保存最后一个命令的输出，以便以后在我们的 GitHub 工作流中使用客户端 ID、客户端密钥和租户 ID：

 pac admin create-service-principal -env https://org48448b9d.crm4.dynamics.com -n VersionControlSPNConnected as XXXXXX@YYYYYYY.onmicrosoft.comCreating Entra ID Application \'VersionControlSPN\'... DoneCreating Entra ID Service Principal... DoneConnected to... pipelinehostRegistering Application \'7be14619-8224-4235-9c6b-2701fb98f203\' with Dataverse... DoneCreating Dataverse system user and assigning role... DoneApplication Name VersionControlSPNTenant Id XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXApplication Id  XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXService Principal Id XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXClient Secret YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYClient Secret Expiration 2025\\. 02\\. 24\\. 16:03:31 +00:00System User Id  XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

创建了带有客户端 ID 和客户端密钥的服务主体后，让我们继续进行使用它们的 GitHub 工作流。

GitHub 工作流

现在是时候在我们的一个 GitHub 仓库中设置 GitHub 流程了。 我们将在接下来的步骤中使用 Visual Studio Code 来创建我们的 YAML 文件。 另外，我们也可以使用 GitHub UI 来创建 我们的工作流：

1. 在选定的 GitHub 仓库中创建名称为 TENANT_ID、CLIENT_ID 和 CLIENT_SECRET 的仓库密钥。

2. 创建一个名为 downloadunpackcommitbash.yml 的 GitHub 流并设置其触发条件为 workflow_dispatch：

    name: DownloadUnpackCommitBashrun-name: VersionControlIntegration-Bashon: workflow_dispatch:

3. 引入由 Power Automate 云流调用的输入参数：

    inputs: artifact_url: description: \"The URL of the Dataverse record ID for the artifact created by the pipelines.\" required: true solution_name: description: \"Name of the solution in Dataverse\" required: true user_name: description: \"User name for the commit\" required: true user_email: description: \"User name email address\" required: true source_branch: description: \"Branch for the solution commit\" default: \"main\" required: true target_branch: description: \"Branch to create for the solution\" required: false commit_message: description: \"Message to provide for the commit\" default: \"test without Dataverse trigger\" required: true

4. 配置标准权限和 GitHub 托管构建代理的操作系统：

    permissions: contents: writejobs: export-unpack-commit: runs-on: ubuntu-latest

5. 在构建代理中检出源分支：

    steps: - uses: actions/checkout@v3 with: ref: ${{ github.event.inputs.source_branch }}

6. 如果指定了目标分支，则创建新分支：

    # Commit changes to the existing or new branch - name: create new branch if specified shell: bash run: | if [ -n \"${{ github.event.inputs.target_branch }}\" ]; then  git checkout -b ${{ github.event.inputs.target_branch }} ${{ github.event.inputs.source_branch }} fi

7. 执行一个 Bash 脚本，从 Microsoft Entra ID 请求具有 Dataverse 范围的访问令牌，使用由 PAC CLI 生成的租户 ID、客户端 ID 和客户端密钥。获取令牌后，我们访问 Dataverse Web API 端点的表（DeploymentArtifacts），并使用 curl 下载由 GUID 标识的工件：

    # Export the solution from the artifact created by pipelines - name: download solution from artifact env:  CLIENT_ID: ${{secrets.CLIENT_ID}}  TENANT_ID: ${{secrets.TENANT_ID}}  CLIENT_SECRET: ${{secrets.CLIENT_SECRET}} shell: bash run: |  aadHost=\"login.microsoftonline.com\"  #adding $value to the end of the artifact url to download binary content  url=\"${{ github.event.inputs.artifact_url }}/\\$value\"  dataverseHost=$(echo $url | cut -d\'/\' -f3)body=\"client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}&grant_type=client_credentials&scope=https://$dataverseHost/.default\"  OAuthReq=$(curl -s -X POST \"https://$aadHost/${TENANT_ID}/oauth2/v2.0/token\" -d $body) spnToken=$(echo $OAuthReq | jq -r .access_token) # Download the managed solution response=$(curl -H \"Authorization: Bearer $spnToken\" \\  -X GET $url \\  -o \"${{ github.event.inputs.solution_name }}_managed.zip\") # Download the unmanaged solution (for now we will need to use string manipulation to get the unmanaged solution URL, until the API provides this value) unmanaged_artifact_url=$(echo \"$url\" | sed \'s/artifactfile/artifactfileunmanaged/g\') response=$(curl -H \"Authorization: Bearer $spnToken\" \\  -X GET $unmanaged_artifact_url \\  -o \"${{ github.event.inputs.solution_name }}.zip\")

8. 使用 GitHub Power Platform 操作（unpack-solution），我们将解决方案的托管版和非托管版解压到构建代理上的仓库：

    # Unpack the solution to a folder named as the solution - name: unpack solution uses: microsoft/powerplatform-actions/unpack-solution@v0 with: solution-file: \"${{ github.event.inputs.solution_name }}.zip\" solution-folder: \"${{ github.event.inputs.solution_name }}\" solution-type: \'Both\' process-canvas-apps: false overwrite-files: true

9. 在构建代理中将更改提交到目标分支或源分支：

    # Commit changes to the existing or new branch - name: commit changes shell: bash run: | rm -rf ${{ github.event.inputs.solution_name }}.zip rm -rf ${{ github.event.inputs.solution_name }}_managed.zip git config user.name ${{ github.event.inputs.user_name }} git config user.email ${{ github.event.inputs.user_email }} git pull git add --all git commit -am \"${{ github.event.inputs.commit_message }}\" --allow-empty

10. 将更改推送到远程源：

     # Push the committed changes to the source branch - name: push to branch shell: bash run: | if [ -n \"${{ github.event.inputs.target_branch }}\" ]; then  git push origin \"${{ github.event.inputs.target_branch }}\" else  git push origin \"${{ github.event.inputs.source_branch }}\" fi

Dataverse Web API – OData 协议

我们使用 Dataverse Web API，通过 OData 协议的 REST API 查询 Dataverse 表和记录。我们 GitHub 工作流的输入参数，artifact_url，期望以下字符串以获取通过其唯一标识符和列 ArtifactFile 标识的记录，https://.$Value，指向二进制内容。由于我们使用的是 Bash，而 Bash 将 $ 符号视为特殊字符，因此我们需要使用转义字符（反斜杠）来将 $value 添加到工件 URL 的末尾。

为了测试我们的 GitHub 流，我们可以通过在 GitHub UI 中提供输入手动使用 run workflow 命令：

![图 5.4 – GitHub – 手动运行工作流

图 5.4 – GitHub – 手动运行工作流

现在，我们有一个 GitHub 工作流，它可以下载部署工件并将其提交到子分支或主分支，具体取决于输入的参数。 查看 .github/downloadunpackcommitbash.yml 文件，它位于书籍 GitHub 仓库的 Chapter05 文件夹中，包含整个 GitHub 工作流。 同样的工作流也可以通过 PowerShell 命令实现。 查看 .github/ downloadunpackcommit.yml 文件，它位于 Chapter05 文件夹中，了解更多细节。

良好的做法是先将更改提交到功能分支，然后再提交拉取请求，因为我们从不直接在主分支上工作。 通常还会有分支策略，禁止开发人员直接在主分支上工作。 另一方面，GitHub 工作流可以在创建并提交更改到 功能分支后立即启动拉取请求。

我们可以使用完全相同的方法，结合 Azure DevOps 服务 的仓库、管道以及 Power Platform 管理管道 同时 考虑以下几点 ：

• 机密作为变量或在 YAML 管道中的变量组中存储。

• GitHub 输入映射到 Azure DevOps 管道变量（而不是参数）。

• 我们可以使用与 GitHub 工作流相同的 Bash 脚本。 无需更改任何内容。 微软托管的构建代理支持 Ubuntu Linux 发行版。

• 我们需要通过 Power Platform构建工具任务（PowerPlatformToolInstaller@2）在构建代理中安装 PowerPlatform 工具。

• 我们需要使用PowerPlatformUnpackSolution@2任务来解包解决方案。

Dataverse 与 Power Automate 云流

在创建了 DevOps 部分后，让我们介绍一个 Power Automate 云流程，它将响应 OnDeploymentCompleted 事件，在 适当的部署阶段。 我们将在 Pipelinehost 环境中创建此云流程：

1. 访问 https://make.powerautomate.com 并选择我们的 Power Platform 管道所在的环境。

2. 然后我们进入 我的流程 面板，打开 新建流程 下拉菜单，并点击 自动化 云流程。

3. 我们可以将流程命名为 ManagedPipelineOnDeploymentCompletedFlow 并选择 当执行某个操作时 作为 Dataverse 的触发条件。

4. 创建流程后，我们需要提供以下值作为触发器操作的参数：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_5.jpg

图 5.5 – Dataverse – 当执行某个操作时

请注意，在这里，我们使用服务主体连接到底层的 Dataverse，这不是 不是 我们在 GitHub 工作流中使用的服务主体。 这是我们在 第四章中创建的服务主体，用于 代表 管道部署。

1. 我们可以使用触发器操作的输出数据（ActionOutputs ArtifactName, ActionOutputs DeploymentPipeIineName, ActionOutputs DeploymentStageName）来引入多个条件，只对我们的管道（PipelineToProd）以及最终部署阶段（Production）做出反应。

2. 在 引入这些条件来限制我们的云流执行仅限于此受管管道后，我们需要从 DeploymentStageRun Dataverse 表中获取一些额外的数据，这些数据与本次运行相关（通过 StageRunId来标识）。 我们使用 按 ID 获取一行数据 操作，并结合触发器活动中的 行 ID 参数来获取 这些信息：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_6.jpg

图 5.6 – 按 ID 获取一行数据操作

1. 最后，我们需要调用 GitHub 工作流的 REST API 端点。 由于这些端点是 受保护的，我们需要创建一个 https://api.github.com/repos/[org-name]/[repository]/actions/workflows/downloadunpackcommitbash.yml/dispatches

2. HTTP 方法：POST

3. 头部

我们仅 定义 Authorization 头部，使用与我们的 GitHub 个人访问令牌完全相同的承载令牌，如下图所示： 图所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_7.jpg

图 5.7 – 带 GitHub 访问令牌的授权头

请注意，我们应该将承载令牌存储在一个由 Azure Key Vault 服务支持的环境变量中。

HTTP 负载（正文）包含 GitHub 工作流的 输入参数：

 { \"ref\": \"main\", \"inputs\": { \"artifact_url\": \"https://[your-env-id].api.crm4.dynamics.com/api/data/v9.0/deploymentartifacts(@{body(\'Get_a_row_by_ID\')?[\'_artifactid_value\']})/artifactfile\", \"solution_name\": \"mpa_ITBase\", \"user_name\": \"jovadker\", \"user_email\": \"jozsef.vadkerti@hotmail.com\", \"source_branch\": \"main\", \"commit_message\": \"new version deployed to prod\" }}

下图显示了我们如何在 HTTP 操作中应用这些参数：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_8.jpg

图 5.8 – 用于调度 GitHub 工作流的 HTTP 操作

当一切 整合在一起时，我们的 Power Automate 云流应该包含以下操作和 条件情况：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/ms-dop-ms-pwr-plat/img/B22208_05_9.jpg

图 5.9 – 端到端云流

通过最后一步，我们已经完成了最初的计划，将我们的 Power Platform 管道的部署工件保存到 GitHub 仓库。

为了完成循环，我们可以引入另一个 Power Automate 云流程，该流程由 提交到主分支 或 拉取请求提交 的 GitHub 事件触发，通过 webhooks 跟踪 GitHub 工作流调度 REST API 的结果，回传到我们的 Power Platform Pipelinehost 环境。 Webhooks 提供了一种机制，用于在 其他服务上注册 HTTP 端点作为事件处理程序。 在我们的案例中，我们可以在 GitHub 侧将 Power Automate 云流程注册为 webhook。 如果 GitHub 中发生了一个定义良好的事件，GitHub 将执行所有已注册的 webhook。 已经有可用的 GitHub 连接器，用于这些类型的触发器，比如 Power Automate 中的 当拉取请求被创建或修改时 webhook。

最后但同样重要的是，值得看一下当我们在 Dataverse 触发的 云流程中使用 Azure DevOps Services 而非 GitHub 时的差异：

• 我们需要启用 通过 OAuth 的第三方应用程序访问 复选框，位于组织级别的 组织设置 | 安全 | 策略 | 应用程序访问策略 在 Azure DevOps Services 中，以便能够在我们的 Power Automate 云流程中使用可用的 Azure DevOps Services 操作。

• 然后，我们使用 排队一个新的构建 操作，通过 Azure DevOps 连接器执行 该管道

• 如前所述，我们的 Azure DevOps 管道期望输入参数作为在 变量 面板中定义的变量

• 排队一个新的构建 操作将参数传递为以下格式：

   {\"artifact_url\": \"https://[your-env-id].api.crm4.dynamics.com/api/data/v9.0/deploymentartifacts(@{body(\'Get_a_row_by_ID\')?[\'_artifactid_value\']})/artifactfile\",\"solution_name\": \"mpa_ITBase\",\"user_name\": \"jovadker\",\"user_email\": \"jozsef.vadkerti@hotmail.com\",\"source_branch\": \"main\",\"commit_message\": \"new version deployed to prod\"}

做得好！ 我们刚刚学会了如何让两个工作流引擎协作，以便使用我们在自定义软件 开发项目中每天应用的相同 DevOps 原则。

Power Platform 管道开发中的协同工作者

为了显著减少在 GitHub 或 Azure DevOps Services 中开发管道的工作量，我们可以利用 大型语言模型（LLMs） 的能力 （例如 GPT-4） 以及基于这些模型构建的产品，以支持开发者和 DevOps 工程师。 其中一款产品是 GitHub Copilot，它 作为一名配对程序员助手，通过自然语言提示合成代码。 GitHub Copilot 集成到 Visual Studio Code、Visual Studio、Neovim 和 JetBrains IDE（甚至在 Azure Data Studio 中）中，并且也可以直接在 GitHub 网站上使用。

使用 GitHub Copilot 内联编辑器或 GitHub Copilot Chat 窗口，我们可以提示基础模型创建管道，这些管道使用构建工具与我们的 Power Platform 环境进行交互。 我们的提示越精确，GitHub Copilot 合成 YAML 文件的准确性就越高。 这一概念也被称为 提示工程。以下是我们在本章中执行的活动的一些真实世界提示：

• “通过使用 Microsoft Power Platform 构建工具，任务创建一个 Azure DevOps 管道，导出一个 Power Platform 环境中的解决方案，解包它，并在一个新分支中提交更改 在 main 下。”

• “创建一个 Bash 脚本，从 Dataverse 获取访问令牌，使用 AAD 应用注册并查询一个 Dataverse 表 DeploymentArtifacts 行，提供其 GUID。”名为“artifactfile”的列应当 随后下载。”

• “通过使用 Power Platform GitHub actions，创建一个 GitHub 工作流，其中包含触发条件调度，导出一个 Power Platform 环境中的解决方案，解包它，并在一个新分支中提交更改 在 main 下。”

如果我们无法访问 GitHub Copilot，我们可以 使用 Microsoft Copilot (https://copilot.microsoft.com)，使用我们的个人账户或其他 LLM 来获取一些模板和逐步说明，帮助我们了解如何构建 YAML 管道。

Copilot 也可在 Power Platform 中使用，通过自然语言帮助我们更直观地创建应用、流程、网站、聊天机器人和报告。 在之前 Dataverse 触发的工作流示例中，我们可以在 Power Automate UI 中使用以下提示 在 Copilot for Power Automate中：

“创建一个由 Power Platform 管道中的“When an action is performed”Dataverse 操作触发的工作流，并通过 OnDeploymentCompleted 事件进行触发。 如果管道是“PipelineToProd”且部署阶段为生产，则调用 HTTP 操作。”

Copilot 将很快成为我们日常工作不可或缺的一部分。 我们需要发展这些技能，获得新能力，才能保持在技术的前沿 。

总结

在本章中，我们探索了分布式版本控制系统 Git 的世界，并发现如何使用 PAC CLI 在 Git 仓库中导出/导入和解压 Power Platform 解决方案。 我们还深入了解了专业 DevOps 管道的内部工作原理，了解了 Azure DevOps 任务和 GitHub actions 等构建工具如何使用底层的 PAC CLI 在提供商托管或 自托管代理中执行操作。

在本章的下半部分，我们将 Power Platform 托管管道的结果与 第四章 中的专业 DevOps 工具结合，实现了直接从托管管道进行版本控制集成。 更重要的是，我们还使用了 GitHub Copilot 和 Power Automate 的 Copilot 来生成我们之前 手动创建的 YAML 管道和 Power Automate 云流。

但请准备好，因为在下一章中，我们将更进一步，深入探讨 YAML 技术，通过管道模板做一些真正的魔法，GitHub 工作流模板和 ALM 加速器 为 Power Platform。

进一步阅读

• 了解 Visual Studio 代码： https://code.visualstudio.com/learn

• Git 开源项目 – Git 的代码库： https://github.com/git/git

• GitHub 流程： https://docs.github.com/en/get-started/using-github/github-flow

• PAC CLI 参考： https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/

• Azure Pipelines 学习 模块： https://learn.microsoft.com/en-us/training/modules/explore-azure-pipelines/

• 集成 Azure 管道： https://learn.microsoft.com/en-us/training/modules/integrate-azure-pipelines/

• Azure DevOps 演示 生成器： https://azuredevopsdemogenerator.azurewebsites.net

• GitHub Actions 学习 模块： https://learn.microsoft.com/en-us/training/modules/introduction-to-github-actions/

• 使用 Azure DevOps 和 GitHub 实现 CI 管道 Actions： https://learn.microsoft.com/en-us/training/paths/az-400-implement-ci-azure-pipelines-github-actions/

• 使用 GitHub 构建持续集成（CI）工作流 Actions： https://learn.microsoft.com/en-us/training/modules/github-actions-ci/

• Microsoft Power Platform 构建工具 for Azure DevOps 服务： https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools

• GitHub Actions for Microsoft Power Platform： https://learn.microsoft.com/en-us/power-platform/alm/devops-github-actions

• Power Platform 构建工具的 GitHub 仓库 工具： https://github.com/microsoft/powerplatform-build-tools

• Azure Pipelines 代理源代码 代码： https://github.com/microsoft/azure-pipelines-agent

• GitHub 运行器源代码 代码： https://github.com/actions/runner/tree/main/src

• 与 GitHub 的管道集成： https://learn.microsoft.com/zh-cn/power-platform/alm/extend-pipelines-github-export

• Dataverse Web API： https://learn.microsoft.com/zh-cn/power-apps/developer/data-platform/webapi/overview

• GitHub 调用 REST API： https://docs.github.com/zh-cn/rest/actions/workflows?apiVersion=2022-11-28#create-a-workflow-dispatch-event

• GitHub 秘密 管理： https://docs.github.com/zh-cn/actions/security-guides/using-secrets-in-github-actions

• GitHub 个人访问 令牌： https://docs.github.com/zh-cn/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

• Power Platform GitHub 连接器： https://learn.microsoft.com/zh-cn/connectors/github/

• Azure DevOps 服务中的应用连接策略： https://learn.microsoft.com/zh-cn/azure/devops/organizations/accounts/change-application-access-policies?view=azure-devops

• 使用 GitHub Copilot 进行提示工程： https://learn.microsoft.com/zh-cn/training/modules/introduction-prompt-engineering-with-github-copilot/

• OpenAI 提示 工程： https://platform.openai.com/docs/guides/prompt-engineering