What & Why
In my previous post I showed how to configure Azure DevOps to deploy to an Azure subscription using a release pipeline with ARM templates located in a git repository. In this post I will expand on how I recommend managing branches and controlling new releases.
The branching strategy I am using will be a development branch and a master branch. You could also use a feature style branching style and have a more complex release pipeline with conditions to deploy to a production environment. I will have a release pipeline for each environment.
The desired outcome is having commits trigger a release pipeline for each branch. Emphasizing that point, development will have a branch and a release pipeline. Master will have its own release pipeline. I like this strategy because we are allowed to make changes to a release pipeline and react to undesired effects without impacting a production environment running from master. I have personally learned that there is no one strategy that works for everyone. I invite you to share your strategy with some pros and cons you have experienced.
Before You Start
In my guides I use Azure DevOps to deploy. You can sign up for a free account here: Azure DevOps
You will of course need an Azure Subscription as well: Azure Free Account
I use service connections from Azure DevOps to my Azure Subscription. You can learn more about that in my previous post.
Guide
- Create a Branch
- Edit ARM Templates
- Create & Configure Release Pipeline
- Setup Automatic Triggers
- Add Approval
Create a Branch
First, let’s create a branch. We can do this from Azure DevOps or from VS Code.
Edit ARM Templates
We need to create containers for “deployment” and “production” to store our ARM template in our storage account.
Several items will need to be changed in our ARM templates to allow for variables, as well as changes to the ARM templates in our blob container. I setup a deployment folder per environment in my existing storage account.
We must edit the Master template and the parameter file. The linked template file for the storage container doesn’t need to change, since we aren’t changing the parameters we send to create that resource.
Create & Configure Release Pipeline
I created a clone of my existing release pipeline. I then changed several items:
- Title
- Artifact Branch
- Container Name
- Azure CLI Command
- Pipeline Variables
The main idea in this step is to get rid of static settings so we can deploy to many environments without the need to edit these settings in the future.
Here I show running the release. You will notice I had a few failures. This was due to some of my variables not matching up, for example I had “devl” for my environment instead of “development” for my storage location. Also, I had to add the creation of the resource group in my ARM template as well as the “dependsOn” for the linked deployment.
This shows that the resource was created successfully.
Configure Automatic Triggers
I configured the release to trigger on a push to the development branch. I then cloned the entire release pipeline, renamed the names to production, and also made the edits to the pipeline variables to set “environment” to production.
Add Approval
I leave my development branch to deploy automatically on a push, but for production you will surely want manual approvals.
Conclusion & Next Steps
Configuring a release pipeline with continuous integration and delivery is critical to achieving speed and confidence of delivery. Going forward, you can simply make changes to your Azure ARM templates inside of VS Code, commit the changes, and monitor the deployment. Once everything appears as you wish in DEVL, you have the confidence to push to production.
I’ve tried to clip my videos and make corrections after troubleshooting my own process. If you find yourself getting stuck on a step, please let me know.
