你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于：
Azure Data Factory 
Azure Synapse Analytics
提示
Microsoft Fabric 中的 Data Factory 是下一代 Azure Data Factory，具有更加简化的架构、内置人工智能和新功能。 如果不熟悉数据集成，请从Fabric数据工厂开始。 现有 ADF 工作负载可以升级到 Fabric，以跨数据科学、实时分析和报告访问新功能。
持续集成是这样一种做法：自动尽早测试对代码库所做的每项更改。 在测试之后进行的持续交付可将更改推送到过渡或生产系统，而测试发生在持续集成期间。
在Azure Data Factory中，持续集成和交付（CI/CD）意味着将数据工厂管道从一个环境（开发、测试、生产）移到另一个环境。 Azure Data Factory利用 Azure Resource Manager 模板来存储各种 ADF 实体（管道、数据集、数据流等）的配置。 可通过两种建议的方式将数据工厂提升到另一个环境：
- 使用数据工厂与 Azure Pipelines 的集成进行自动部署
- 手动上传资源管理器模板，使用数据工厂 UX 与 Azure 资源管理器集成。
注意
建议使用 Azure Az PowerShell 模块与Azure交互。 若要开始，请参阅 Install Azure PowerShell。 若要了解如何迁移到 Az PowerShell 模块，请参阅 Migrate Azure PowerShell从 AzureRM 迁移到 Az。
CI/CD 生命周期
注意
有关详细信息，请参阅持续部署改进。
下面是使用 Azure Repos Git 配置的Azure数据工厂中 CI/CD 生命周期的示例概述。 有关配置 Git 存储库的详细信息，请参阅 Azure Data Factory 中的源代码管理。
使用 Azure Repos Git 创建和配置开发数据工厂。 所有开发人员都应有权创作数据工厂资源，例如管道和数据集。
开发人员创建功能分支以进行更改。 数据工厂不支持签名提交。 他们使用最近的更改来调试其管道运行。 有关如何调试管道运行的详细信息，请参阅
使用 Azure Data Factory0 进行迭代开发和调试。 对所做的更改满意以后，开发人员可以创建一个拉取请求，将请求从其功能分支拉取到主分支或协作分支，让同行来评审他们的更改。
在拉取请求获得批准并已将更改合并到主分支后，更改将发布到开发工厂。
当团队准备好将更改部署到测试或 UAT（用户验收测试）环境时，团队会进入 Azure Pipelines 发布管道，并将所需的开发环境版本部署到 UAT。 此部署作为Azure Pipelines任务的一部分进行，并使用Resource Manager模板参数应用适当的配置。
在测试工厂中验证更改后，将使用下一个管道发布任务部署到生产工厂。
注意
只有开发工厂才与 git 存储库相关联。 测试和生产工厂不应具有与其关联的 git 存储库，并且只能通过Azure DevOps管道或通过资源管理模板进行更新。
下图突出显示了此生命周期的各个步骤。
CI/CD 最佳做法
如果你使用数据工厂的 Git 集成，并且某个 CI/CD 管道会将更改从开发环境依次转移到测试和生产环境，则我们建议采用以下最佳做法：
Git 集成。 仅配置具有 Git 集成的开发数据工厂。 对测试和生产环境所做的更改将通过 CI/CD 进行部署，不需要 Git 集成。
部署前和部署后脚本。 在 CI/CD 中的资源管理器部署步骤之前，你需要完成某些任务，例如停止和重启触发器，以及执行清理工作。 我们建议在执行部署任务之前和之后使用 PowerShell 脚本。 有关详细信息，请参阅更新活动触发器。 数据工厂团队已在本网页的末尾提供了一个可用的脚本。
注意
如果只想在 CI/CD 期间关闭/打开已修改的触发器，而不是关闭/打开所有触发器，可以使用 PrePostDeploymentScript.Ver2.ps1。
警告
确保在 ADO 任务中使用 PowerShell Core 来运行脚本。
警告
如果不使用最新版的 PowerShell 和数据工厂模块，可能会在运行命令时遇到反序列化错误。
集成运行时和共享。 集成运行时不经常更改，在 CI/CD 的所有阶段中都是类似的。 因此，数据工厂预期在 CI/CD 的所有阶段使用相同的集成运行时名称、类型和子类型。 若要在所有阶段中共享集成运行时，请考虑使用三元工厂，这只是为了包含共享的集成运行时。 可以在所有环境中将此共享工厂用作链接的集成运行时类型。
注意
集成运行时共享仅适用于自承载集成运行时。 Azure-SSIS 集成运行时不支持共享。
托管的专用终结点部署。 如果工厂中已经存在一个专用终结点，而你尝试部署的 ARM 模板包含一个名称相同但属性已修改的专用终结点，则部署将失败。 换句话说，只要专用终结点与工厂中已经存在的专用终结点具有相同的属性，就可以成功部署该终结点。 如果任何属性在不同的环境中是不同的，你可以通过参数化该属性并在部署期间提供相应的值来替代它。
Key Vault。 使用连接信息存储在Azure Key Vault中的链接服务时，建议为不同的环境保留单独的密钥保管库。 此外，可为每个密钥保管库单独配置权限级别。 例如，你可能不希望团队成员有权访问生产机密。 如果采用此方法，我们建议在所有阶段中保留相同的机密名称。 如果保留相同的机密名称，则无需跨 CI/CD 环境参数化每个connection string，因为唯一更改的是密钥保管库名称，这是一个单独的参数。
资源命名。 由于 ARM 模板的约束，如果资源在名称中包含空格，部署中可能会出现问题。 Azure Data Factory团队建议使用“_”或“-”字符，而不是资源空间。 例如，“Pipeline_1”比“Pipeline 1”更可取。
更改存储库。 ADF 可自动管理 GIT 存储库内容。 在 ADF Git 存储库数据文件夹的任意位置更改或手动添加不相关的文件或文件夹可能会导致资源加载错误。 例如，如果存在 .bak 文件，则可能会导致 ADF CI/CD 错误，因此应将其移除，以便加载 ADF。
公开控制和功能标志。 在团队合作时，有些情况下你可能会合并更改，但不希望这些更改在高级环境中（例如 PROD 和 QA）运行。 为了应对这种情况，ADF 团队推荐有关使用功能标志的 DevOps 概念。 在 ADF 中，可以结合全局参数和 if 条件活动，以根据这些环境标志隐藏逻辑集合。
若要了解如何设置功能标志，请参阅以下视频教程：
不支持的功能
按照设计，数据工厂不允许挑拣提交内容或选择性地发布资源。 发布将会包含在数据工厂中发生的所有更改。
- 数据工厂实体相互依赖。 例如，触发器依赖于管道，而管道又依赖于数据集和其他管道。 选择性发布资源子集可能会导致意外的行为和错误。
- 如果需要进行选择性发布（这种情况很少见），请考虑使用修补程序。 有关详细信息，请参阅热修复生产环境。
Azure Data Factory团队不建议在数据工厂中将Azure RBAC 控件分配给各个实体（管道、数据集等）。 例如，如果开发人员可以访问管道或数据集，则他们应该能够访问数据工厂中的所有管道或数据集。 如果你觉得需要在数据工厂中实现许多Azure角色，请查看部署第二个数据工厂。
无法从专用分支发布。
目前无法在 Bitbucket 上托管项目。
当前无法以参数的形式导出和导入警报和矩阵。
自 2021 年 11 月 1 日起，不再支持在发布分支中使用局部 ARM 模板。 如果你的项目使用了此功能，请使用
ARMTemplateForFactory.json或linkedTemplates文件切换到受支持的部署机制。