Introduction
Even though a lot of organization have adopted Agile/Scrum, their priority is focusing on delivering features of the software product. CI/CD automation is often become their technical debt, which may or may not be repaid.
This series of blog posts provide recipes for CI/CD automation that based on different architecture scenarios, such as ‘Public Web App’, ‘Internal Function App’, etc., using Azure DevOps and deploying to Microsoft Azure. The goal is to help the adaption of using automation and provide a booster for you to implement CI/CD.
On the other hand, these series are not demonstrating writing C# or Python code, the application sample is just used to test the CI/CD automation.
The Basic
Each recipe is based on a specific application usage scenario with matching criteria / characteristics so that you can understand if the recipe fits your needs. The plan is to add more complex recipes, but still, you may need to combine two or more recipes to fulfill your actual requirements. The intend is let you copying and modifying the provided artifacts to bootstrap your CI/CD using Azure DevOps. Each recipe includes:
- A post to describe the usage scenario with lesson learnt
- Bicep modules for the Azure Services used in scenario
- Bicep template for provisioning the scenario
- YAML code and template for CI and CD pipelines
- Skeleton application for testing CI/CD automation
A little bit more details
Bicep Modules
In Bicep, you could build bicep module (MS Doc link) so that you can reuse them for other applications. Since your main goal is implementing your application and releasing it to production, it would be great to consider the reuse scenarios for your next application or for another application team sit next to you; however, don’t over engineer your module to satisfy every scenario in your organization. I would suggest to parameterize your modules to allow flexibility and enhance reusability, such as:
- Name of the resource, so that you can provision multiple of them
- Sizing of the resource, so that you can use different sizing in different environment
- Runtime engine in App Service, so that you can use different programming language
Bicep Template
We need a Bicep template to describe the infrastructure platform for the application (i.e. all the Azure services required), I usually call it ‘main.bicep’, but you can call it whatever you like.
This file is for your application and your application only, in my opinion, it is acceptable to hard-coded values that are specific to the application to minimize additional configuration somewhere else as long as it is flexible enough to support multiple environments, which rely on the parameter file: ‘main-param-dev.json’. For testing the bicep modules and template, you could use Azure CLI as follow:
az deployment group create --resource-group $rgName --template-file './main.bicep' --parameters './main-param-dev.json'Naming Convention
Naming is one of the frequently asked questions and usually generates a lot of debate. Most organizations have their own standards and some even use Azure Policy to enforce them. I am not here to debate what the naming convention should be, or which one is better, the most important rule is consistency. I would suggest don’t waste your time to reinvent the wheel, check out the following links to Microsoft Documentation:
- Define your naming convention (MS Doc link)
- Recommended abbreviations for Azure resource types (MS Doc link)
In addition, you should ensure the name include Environment, such as dev, test, prod for handling multiple environments, and Resource Type for bettering maintainability of your IaC.
Pipeline Design
Your pipeline design should align with your team rhythm and branch strategy. Here is one of the approaches I used in my previous projects that has pretty good outcome.
For development in DEV environment, perform Continuous Integration (CI) as part of Pull Request, and perform Continuous Delivery (CD) sourcing from the ‘develop’ branch for both infrastructure provisioning and application deployment. I would suggest starting with once a week and then twice a week at a minimum.
For testing and production, perform Continuous Delivery (CD) sourcing from the ‘main’ branch with gated approval. Some organizations have policy to control provisioning of Azure Services, so I would split the infrastructure provisioning and application deployment into two pipelines to provide the flexibility:
There are multiple schools of thoughts on how to slice and dice the CD pipelines, and I don’t believe there is one size fits all. Even though your team starts with one approach, it is possible to change the approach to better fit your team’s rhythm. The goal is maximizing your productivity and improving the quality of your product.
Tools & Technologies
Here is a list of tools and technologies used for the automation, I include links in case you need to learn it or a refresher.
| Azure DevOps | Get started with Azure DevOps (MS Learn link) Deploy applications with Azure DevOps (MS Learn link) |
| Azure Pipelines (YAML) | Key concepts for new Azure Pipelines users (MS Doc link) |
| Azure Bicep | Deploy Azure resources by using Bicep and Azure Pipelines (MS Learn link) |
| Azure CLI | Get started with Azure CLI (MS Doc link) |
| Visual Studio Code | Set up Visual Studio Code (MS Doc link) |
| Visual Studio | Getting started with Visual Studio (MS Doc link) |
Series continue at: CI/CD Automation Get Ready
Azure Recipes 