Events
31 Mar, 23 - 2 Apr, 23
The biggest Fabric, Power BI, and SQL learning event. March 31 – April 2. Use code FABINSIDER to save $400.
Register todayThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
APPLIES TO:
Azure Data Factory
Azure Synapse Analytics
Tip
Try out Data Factory in Microsoft Fabric, an all-in-one analytics solution for enterprises. Microsoft Fabric covers everything from data movement to data science, real-time analytics, business intelligence, and reporting. Learn how to start a new trial for free!
Note
Synapse Analytics also supports CI/CD. Refer to the Synapse Analytics CI/CD documentation for more information.
Continuous integration is the practice of testing each change made to your codebase automatically. As early as possible, continuous delivery follows the testing that happens during continuous integration and pushes changes to a staging or production system.
In Azure Data Factory, CI/CD means moving Data Factory pipelines from one environment, such as development, test, and production, to another. Data Factory uses Azure Resource Manager templates (ARM templates) to store the configuration of your various Data Factory entities, such as pipelines, datasets, and data flows.
There are two suggested methods to promote a data factory to another environment:
For more information, see Continuous integration and delivery in Azure Data Factory.
This article focuses on the continuous deployment improvements and the automated publish feature for CI/CD.
The automated publish feature takes the Validate all and Export ARM template features from the Data Factory user experience and makes the logic consumable via a publicly available npm package @microsoft/azure-data-factory-utilities. For this reason, you can programmatically trigger these actions instead of having to go to the Data Factory UI and select a button manually. This capability will give your CI/CD pipelines a truer continuous integration experience.
Note
Be sure to use the node version 18.x and and its compatible version to avoid errors that can occur due to package incompatibility with older versions.
In the current CI/CD flow, the user experience is the intermediary to create the ARM template. As a result, a user must go to the Data Factory UI and manually select Publish to start the ARM template generation and drop it in the publish branch.
Note
You can continue to use the existing mechanism, which is the adf_publish
branch, or you can use the new flow. Both are supported.
Two commands are currently available in the package:
Run npm run build export <rootFolder> <factoryId> [outputFolder]
to export the ARM template by using the resources of a given folder. This command also runs a validation check prior to generating the ARM template. Here's an example using a resource group named testResourceGroup:
npm run build export C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory ArmTemplateOutput
RootFolder
is a mandatory field that represents where the Data Factory resources are located.FactoryId
is a mandatory field that represents the Data Factory resource ID in the format /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName>
.OutputFolder
is an optional parameter that specifies the relative path to save the generated ARM template.The ability to stop/start only the updated triggers is now generally available and is merged into the command shown above.
Note
The ARM template generated isn't published to the live version of the factory. Deployment should be done by using a CI/CD pipeline.
Run npm run build validate <rootFolder> <factoryId>
to validate all the resources of a given folder. Here's an example:
npm run build validate C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory
RootFolder
is a mandatory field that represents where the Data Factory resources are located.FactoryId
is a mandatory field that represents the Data Factory resource ID in the format /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName>
.While npm packages can be consumed in various ways, one of the primary benefits is being consumed via Azure Pipeline. On each merge into your collaboration branch, a pipeline can be triggered that first validates all of the code and then exports the ARM template into a build artifact that can be consumed by a release pipeline. How it differs from the current CI/CD process is that you will point your release pipeline at this artifact instead of the existing adf_publish
branch.
Follow these steps to get started:
Open an Azure DevOps project, and go to Pipelines. Select New Pipeline.
Select the repository where you want to save your pipeline YAML script. We recommend saving it in a build folder in the same repository of your Data Factory resources. Ensure there's a package.json file in the repository that contains the package name, as shown in the following example:
{
"scripts":{
"build":"node node_modules/@microsoft/azure-data-factory-utilities/lib/index"
},
"dependencies":{
"@microsoft/azure-data-factory-utilities":"^1.0.0"
}
}
Select Starter pipeline. If you've uploaded or merged the YAML file, as shown in the following example, you can also point directly at that and edit it.
# Sample YAML file to validate and export an ARM template into a build artifact
# Requires a package.json file located in the target repository
trigger:
- main #collaboration branch
pool:
vmImage: 'ubuntu-latest'
steps:
# Installs Node and the npm packages saved in your package.json file in the build
- task: UseNode@1
inputs:
version: '18.x'
displayName: 'Install Node.js'
- task: Npm@1
inputs:
command: 'install'
workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
verbose: true
displayName: 'Install npm package'
# Validates all of the Data Factory resources in the repository. You'll get the same validation errors as when "Validate All" is selected.
# Enter the appropriate subscription and name for the source factory. Either of the "Validate" or "Validate and Generate ARM template" options are required to perform validation. Running both is unnecessary.
- task: Npm@1
inputs:
command: 'custom'
workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
customCommand: 'run build validate $(Build.Repository.LocalPath)/<Root-folder-from-Git-configuration-settings-in-ADF> /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<Your-ResourceGroup-Name>/providers/Microsoft.DataFactory/factories/<Your-Factory-Name>'
displayName: 'Validate'
# Validate and then generate the ARM template into the destination folder, which is the same as selecting "Publish" from the UX.
# The ARM template generated isn't published to the live version of the factory. Deployment should be done by using a CI/CD pipeline.
- task: Npm@1
inputs:
command: 'custom'
workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
customCommand: 'run build export $(Build.Repository.LocalPath)/<Root-folder-from-Git-configuration-settings-in-ADF> /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<Your-ResourceGroup-Name>/providers/Microsoft.DataFactory/factories/<Your-Factory-Name> "ArmTemplate"'
#For using preview that allows you to only stop/ start triggers that are modified, please comment out the above line and uncomment the below line. Make sure the package.json contains the build-preview command.
#customCommand: 'run build-preview export $(Build.Repository.LocalPath) /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/GartnerMQ2021/providers/Microsoft.DataFactory/factories/Dev-GartnerMQ2021-DataFactory "ArmTemplate"'
displayName: 'Validate and Generate ARM template'
# Publish the artifact to be used as a source for a release pipeline.
- task: PublishPipelineArtifact@1
inputs:
targetPath: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>/ArmTemplate' #replace with the package.json folder
artifact: 'ArmTemplates'
publishLocation: 'pipeline'
Enter your YAML code. We recommend that you use the YAML file as a starting point.
Save and run. If you used the YAML, it gets triggered every time the main branch is updated.
Note
The generated artifacts already contain pre and post deployment scripts for the triggers so it isn't necessary to add these manually. However, when deploying one would still need to reference the documentation on stopping and starting triggers to execute the provided script.
Learn more information about continuous integration and delivery in Data Factory: Continuous integration and delivery in Azure Data Factory.
Events
31 Mar, 23 - 2 Apr, 23
The biggest Fabric, Power BI, and SQL learning event. March 31 – April 2. Use code FABINSIDER to save $400.
Register todayTraining
Module
Operationalize your Azure Data Factory or Azure Synapse Pipeline - Training
Operationalize your Azure Data Factory or Azure Synapse Pipeline
Certification
Microsoft Certified: Power Automate RPA Developer Associate - Certifications
Demonstrate how to improve and automate workflows with Microsoft Power Automate RPA developer.
Documentation
Automate continuous integration - Azure Data Factory
Learn how to automate continuous integration in Azure Data Factory with Azure Pipelines pipelines releases.
Continuous integration and delivery pre- and post-deployment scripts - Azure Data Factory
Learn how to use a pre- and post-deployment script with continuous integration and delivery in Azure Data Factory from this sample.
Continuous integration and delivery - Azure Data Factory
Learn how to use continuous integration and delivery to move Azure Data Factory pipelines from one environment (development, test, production) to another.