Title: CI/CD Github and Azure DevOps
Completion Date: September 2022
Demo Project Overview
We set up a CICD pipeline for infrastructure deployment onto a Maolte Technical Solution's demo subscription in Microsoft Azure. This is the very first official project of Maolte Technical Solutions Limited just 2 months after our incorporation as a limited company. We set out to design and build a manual CICD pipeline in Azure DevOps so we can deploy 1x V-Net and 2x subnets onto Azure using ARM template automation for IaC reusability, GitHub for version control and Azure key vault for secrets management.
This project is the first in a series of Azure-based projects to build out the infrastructure for typical Azure V-Net architecture designed to support modern applications deployed into the cloud. We will use Azure DevOps for this series of demo projects showcasing the DevOps tool as much as Azure itself. Our workflow design is simplified for demo purposes so the pull request and approval checks found in production release pipelines are not implemented in this first out-of-the-box demo project for Maolte as a limited company.
The project workflow is as follows:
- GitHub Account - Source Repo is publically available at https://github.com/johnmlhll/azure-provision-vnet.
- Azure key vault updated with key vault secrets based on code variables used in the ARM IaC JSON.
- Repo coded up creating ARM template file, parameter file and azure-pipelines.yaml file to manage this deployment.
- Code pushed direct from local main to remote main in the GitHub repository. Do note that in production a pull request would be set up in the GitHub workflow for a peer review.
- Azure DevOps project called V-NET Demo set up as Maolte Technical Solution's very first Azure DevOps Organizations project.
- ARM Service connection was created to connect to the Azure subscription management group. It is then validated ensuring the IAM role assigned to the service principal permission was a 'Contributor' role.
- Repo in `V-Net Demo`on Azure DevOps was used to import the GitHub repo. It was when used to authorise the API interaction between the GitHub Repo and the Azure DevOps project based on the main (remote) branch updates. This is due to the pull request control (trigger) not being implemented for demo purposes. Such implementation is regarded as best practice in production projects.
- On the Azure portal, the Bash CLI command line was spun up to check that`Microsoft.Network` is 'Registered'. It was not so `az provider register --namespace "Microsoft.Network"` was used to register the provider.
- Azure Project 'Pipeline' is selected and 'Create Pipeline' using the imported repo for the initial commit and then 'Run Pipeline' when created.
- Monitored to completion or failure. If it's a failure, debug and fix it. Then re-push from the local branch or rerun if the issue is pipeline related.
- When completed successfully, confirm new V-Net and Subnets as named in the IaC templated deployed are actually running normally on the target resource group in the Azure subscription.
- Record outcome of deployment on Kanban card and close
There were three problems on the project, which failed pipeline deployments. Two were related to the project on Azure DevOps being the very first project and the third was syntax related. The problems were as follows:
- Parallelism - This setting on Azure DevOps with the free tier account subscription meant parallelism was not enabled by default. I had to apply for it via a supplied link in the Azure DevOps error output and it was enabled a few days later by Azure support allowing the project to run.
- Networking on Azure - `Microsoft.Network` on a new Azure subscription has to be `Registered`. As this subscription was not even a week old, I had to spin up a limited scope storage account and log in via Bash CLI to register the provider `Microsoft.Network`.
- Syntax - Coding syntax for Azure Resource Management templates was never done in great detail by myself in times past as Cloud Formation in AWS was my go-to for projects that I worked on. Despite this, the cross-overs, training and experience kicked in allowing me to overcome my inherent issues around reading JSON's finer points. A large number of typos were due to me being JSON rusty as YAML has been my go-to in the recent past. Comfort levels did increase with repetition but I honestly still favour YAML.
The project story as described above can be told in this short video: Project V-Net Story
The next project will be using ARM IaC to build out a V-Net, but this time fleshing out the V-Net and deploying a CosmosDB-managed database in a highly available configuration.