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

预配云规模分析

数据管理登陆区域部署过程

数据平台运营团队负责部署数据管理登陆区域。 数据管理登陆区域应有自己的存储库，并且该数据库应由数据平台运营团队维护。

注意

在部署任何数据登陆区域之前，请先创建并部署数据管理登陆区域。

数据登录区域部署过程

团队可使用数据平台运营团队提供的模板，避免从头开始处理每项资产。 建议使用分支模式自动部署新的登陆区域。

例如，数据登陆区域运营团队使用 IT 管理工具或 Power Apps 请求新的数据登陆区域。 请求得到批准后，使用请求中的参数启动以下工作流：

1. 为新的数据登陆区域部署新订阅。
2. 为数据登陆区域模板的主分支创建分支以创建新的存储库。
3. 在新的存储库中创建服务连接。
4. 基于请求中的参数更新新存储库中的参数。
5. 创建部署管道来部署服务，该管道由更新的参数的签入触发。
6. 通知数据登陆区域运营团队新的登陆区域现已可用。

数据登陆区域运营团队现在可以更改或添加 Azure 资源管理器模板。

可使用 Azure 平台上的多个服务集自动执行此工作流。 使用 CI/CD 管道处理某些步骤，例如重命名参数文件中的参数。 可使用其他工作流业务流程工具（如逻辑应用）执行其他步骤。

通过分支模式，团队可以根据用于创建分支的原始模板更新他们的模板。 此外，如果在模板存储库中实现了改进或新功能，运营团队可将它们拉取到分支中。

采用存储库的最佳做法，例如：

• 保护主分支。
• 使用分支进行更改、更新和改进。
• 定义在将更改合并到主分支之前批准拉取请求的代码所有者。
• 通过自动测试验证分支。
• 限制操作数量和团队中的人员，例如谁可以触发生成和发布管道。

提示

协调团队之间的活动，以确保原始模板中的改进或新功能将复制到所有数据登陆区域实例。 运营团队可以将原始模板更改拉取到其分支中。

加入过程与数据登陆区域部署过程是分离的。 这种分离基于以下假设：大多数组织将标准 Azure 订阅部署过程作为云操作模型的一部分。 加入过程将部署标准企业组件（例如第三方 IT 服务管理工具）。 接下来将部署特定于数据登陆区域的组件。

在建议的自动化解决方案中，没有可用于克隆/更新/提交/推送的 Git API。 因此，我们的方法是使用一个包含 PowerShell Runbook 的 Azure 自动化帐户：

• 设置数据登陆区域
• 为主存储库创建数据平台 Git 存储库分支
• 为数据登陆区域设置子网配置
• 设置 Microsoft Entra ID

Runbook 使用 GitAutomation PowerShell 模块中的 Git 函数来处理 Git 存储库。 通过在 Azure 自动化帐户内安装此模块，用户可以在 Git 存储库中执行创建、克隆、查询、推送、拉取和提交操作。 下图显示了安装在 Azure 自动化帐户内的 GitAutomation 模块：

使用 GitAutomation 模块中的 Copy-GitRepository 函数将 URL 指定的 URL 中的主 Git 存储库克隆到 DestinationPath 指定的数据平台 Git 路径。

这种数据登陆区域部署方法非常灵活，同时确保操作符合组织要求。 生命周期管理是通过应用原始模板中的新功能或优化来启用的。

数据应用程序部署过程

创建数据登陆区域后，数据应用程序团队可以开始加入。 数据平台或数据登陆区域运营团队负责审批部署。

可直接使用 DevOps 工具完成部署，也可通过公开为 API 的管道/工作流进行调用来完成。 与数据登陆区域类似，部署的初始操作是为原始数据应用程序存储库创建分支。

1. 用户请求新的数据应用程序服务。
2. 工作流程请求数据平台或数据登陆区域运营团队批准。
3. 工作流调用 IT 服务管理 API 来创建所需的资源组，并创建 Azure DevOps 服务连接。 工作流向 Azure DevOps 项目分配团队。
4. 工作流为原始数据应用程序存储库创建分支，从而创建目标 Azure DevOps 项目。
5. 工作流创建 Azure 资源管理器模板参数文件和管道。
6. 然后，工作流启动一个 Azure 管道来创建网络要求，并启动另一个 Azure 管道来部署数据应用程序服务。
7. 工作流在完成时通知用户。

提示

如果你不熟悉 DataOps，请查看 Azure 体系结构中心的适用于新式数据仓库的 DataOps 动手实验室。 该实验室场景描述了一个可使用此部署解决方案的虚构城市规划办公室。 该部署解决方案提供一个遵循新式数据仓库体系结构模式的端到端数据管道，以及相应的 DevOps 和 DataOps 流程，用于评估停车位使用情况并做出明智的业务决策。

总结

上述模式提供控制、敏捷性、自助服务和策略的生命周期管理。

在项目开始时，数据平台有一个 Azure DevOps 项目，其中包含一个或多个 Azure Boards。 各 DevOps 团队重点关注以下项：

• 一个用于数据管理登陆区域的存储库、多个管道、一个到云环境的服务连接。
• 一个用于数据登陆区域的模板存储库、多个用于部署数据登陆区域实例的管道、多个到云环境的服务连接。
• 一个用于数据产品服务的模板存储库、多个用于部署数据产品实例的管道、多个到云环境的服务连接。 这些连接来自数据登陆区域 Azure DevOps 项目。

部署数据登陆区域后，云规模分析规定：

• 每个数据登陆区域都有自己的 Azure DevOps 项目，其中具有一个或多个 Azure Boards。
• 对于每个数据应用程序，其数据登陆区域 Azure DevOps 项目分支应在请求获得批准后进行创建。
• 每个数据应用程序包括：
  • 一个服务连接。
  • 一个已注册的管道。
  • 一个有权访问其 Azure Boards 和存储库的 DevOps 团队。
  • 一组用于分支存储库的不同策略。

若要控制数据应用程序的部署，请遵循以下做法：

• 数据登陆区域运营团队拥有并保护主存储库分支。
• 仅主分支用于部署到测试和生产环境。
• 功能分支可以部署到开发环境。
• 功能分支由 DataOps 团队拥有。 它们用于测试新功能或修改的功能。
• DataOps 团队无需批准即可将功能分支合并到其他功能分支。
• DataOps 团队创建拉取请求来将功能分支合并到主分支，数据登陆区域运营团队负责审批。
• 原始模板的新功能或改进将合并到分支存储库中，以使它们保持更新。

后续步骤

• 用于云规模分析部署的部署模板
• Azure 自动化简介