In this first of a three-part article series, we are going over the process of moving a service/application already deployed in Microsoft Azure to the DevOps side by using Azure DevOps. There are several Azure deployments that are performed using Azure Portal or PowerShell scripts. There is nothing wrong with that, but when you start getting more complex where audit, version control, consistency, validation, and rollback become hot topics, then it is time to start your journey on the Azure DevOps path.
We will be looking at a virtual network deployed in production, and the goal for this article is to reproduce the current virtual network in production to another resource group. Keep in mind that although we are using resource groups, we could be using different subscriptions, which is the norm in corporate environments.
We are going to start simple, having a virtual network in our production resource group, which in this article we are calling Prod-CanC-Hub-CoreNetwork. In the beginning, this virtual network has a single subnet named Servers.
Creating the Azure DevOps organization and first project
If you already have an organization, you can skip this task and create a project for your infrastructure-as-a-code (IaaC). In case you need to create your very first organization, search for DevOps in the search field located in the top middle of the Azure Portal. Click on Azure DevOps, and that will bring a new blade welcoming you to Azure DevOps. Click on My Azure DevOps Organizations.
A new page containing all existing organizations and even deleted ones, which you can still restore, will be listed. To create a new one, click on Create new Organization.
A welcome dialogue box will be displayed. Make sure that you are logged in with the correct account, then click on Continue. Define a name for your organization and location to host it in the cloud and click Continue.
Now that we have a new organization, we are going to create our first project. We are going to call this project AP6Industries, and our goal is to manage the entire infrastructure using this project. For every application/service, we will create a separate Repository and Pipelines, but the project is the boundary for us. Select the visibility of the project. We selected Private, which is the default option. Click on the +Create Project and wait for the process to complete.
Our first objective is to move the current virtual network, and that virtual network is on the Hub-CoreNetwork resource group, and it is a service by itself. Let’s create a repo just for that service. Click on Repos (Item 1), click on AP6Industries (Item 2. By default, the first repo is the name of the current project). Then click on New Repository (Item 3). In the new blade, assign the desired name, we are going to label it as Hub-CoreNetwork, and click on Create.
In the new page, select Add a README and click on Initialize, which will create a sample README file in the newly created repo. In the new page, the current repo will be displayed (just a single file), click on Clone, and on the new blade, click on Clone in VS Code.
Important: If you don’t have Visual Studio Code, this is the time to download it. I wrote an article here at TechGenix that goes over the installation and integration with source control and can be used to complete this task. The article can be found here.
At this point, we have a new Azure DevOps organization, project, and we have a place to store the upcoming changes in our virtual network.
Gathering the existing virtual network ARM templates
Using ARM templates requires two files for a regular deployment: the template.json and the parameters.json. The names are not a requirement, but it’s a common practice to use those because most of the ecosystem around ARM deployment is going to ask for those file names.
The template.json contains all the code to create the resources. The parameters.json file is used to supply dynamic information such as the name of your resources, locations, and so forth.
We can go to the production environment. Select the resource that we want to see the ARM template, which is the virtual network in our scenario. Click on Export Template (Item 1). A new blade with the code required to deploy using the Azure Resource Manager will be displayed. That is going to be our initial code.
We need to move that content to new files in our VS Code. The first step is to copy the content of the template tab (located on Item 2) to a new file in our VS Code and save it as template.json. Next, click on Parameters (Item 2) and copy the entire content, and create another new file. Paste the content (Item 3) and save it as parameters.json.
The result on your VS Code should be similar to the image below. We have cleaned them up slightly to remove unnecessary code and renamed the variables to be easier on the eye.
In theory, we can save and push the changes from our machine using Visual Studio Code to the repo in Azure DevOps.
Creating a release pipeline
Logged in the Azure DevOps, click on Pipelines, and then Releases. Click on New Pipeline. A new Select a template blade will be displayed. Click on Empty Job. After that, a Stage blade will be displayed. Type in DEV in the Stage Name and close it.
The first step is to click on Add an artifact (Item 1), select Azure Repos Git (Item 2), and then select the project (Item 3), source (Item 4), and Default Branch (Item 4) and click on Add. Any update to the master branch of the repo will trigger a new release automatically.
Click on Tasks located inside of the DEV box that we have just defined in our first steps. A new page with the Agent Job will be listed, click on the + button to add a task, select Azure resource group deployment from the list and click on Add.
In the Azure resource group deployment blade, we are going to select (and authorize) the current subscription, resource group name (you can assign a new name), location, and our new acquaintance: template and parameter files (as depicted in the image below). You can click Save at any time to save your current progress.
Note 1: In this article, we are using DEV-CanC-Hub-CoreNetwork as Resource Group because we want to validate the ARM template and the deployment process first.
We can create Service Connections to manage from a global perspective, instead of doing per pipeline. However, we will tackle that in a future article.
To configure this Release Pipeline to run when a commit is made to the master in the repo, we need to click on the Lightning icon located in the Artifacts box and enable the option Continuous deployment trigger.
Testing the new process
In this article, as soon as we do any updates on the master branch of the repo, a new release will be triggered automatically in Azure DevOps. It is a beautiful thing!
If we click on In progress, we can see step-by-step the tasks being performed by the Agent job. We can also click on them on the right side to see the output of the actual task. That helps during the troubleshooting process.
The result will be a brand-new subnet using the name that we defined in the ARM template (parameters.json) in the resource group that we set in the pipeline. The configuration data (address space, subnets, and settings) are the same from the production network.
Journey to Azure DevOps: Just getting started
We started our journey to Azure DevOps by moving an existing virtual network deployed through the Azure Portal into an Azure Repo, and from there, we created a Release Pipeline that deploys automatically in our DEV environment. In the second article, we are going to optimize the pipeline and introduce variables to remove most of the complexity from the code and improve the deployment process without manual intervention. The files that we cleaned up and used in this article can be found at my GitHub. The template can be found here, and the parameters can be found here.
Featured image: Shutterstock