Craig Porteous

After publishing the first few posts in my series on CI/CD for Azure Data Factory, I got stuck into the next installment, released yesterday, on how to handle Integration runtimes (which argueably should have come first🤫).

This is part of a series of blog posts where I’ll build out Continuous Integration and Delivery (CI/CD) pipelines using Azure DevOps, to test, document, and deploy Azure Data Factory.

Azure Data Factory - Delivery components

This week has been a good mix of working on a custom python library, building pipelines and planning further CI/CD pipelines for tech beyond Data Factory.

This is the first in a series of blog posts where I’ll walk through the steps to build out Continuous Integration and Delivery (CI/CD) pipelines using Azure DevOps, to test, document, and deploy an Azure Data Factory.

There was no break time browsing list last week, you may have noticed.

This week saw the end of Hacktoberfest, so I hope you managed to get your four pull requests in before Sunday (assuming you were participating).

This week’s list is a little late as I wanted to make a last-minute addition of Shane’s post at the top there, just published yesterday.

Whether you are changing naming conventions, migrating to a new tenant or handing over development resources to a customer, there are several scenarios where you may want or need to create a new data factory to develop in, or change the source of your data factory content to a new repo.