Journey to enlightenment: Transferring from Azure Portal/PowerShell to Azure DevOps

On this second article in our three-part collection on Azure DevOps, we’re going to work and optimize our present ARM template and add some intelligence to our launch pipeline and automate as a lot as doable. You may check out Part 1 of the series here.

The high-level overview of this text collection is depicted within the diagram under. We’re going to use Azure DevOps to work on the ARM template that we outline, and after that, deploy the DEV atmosphere positioned in Canada East after which PROD atmosphere positioned in Canada Central.

Azure DevOps

There isn’t any want to make use of two areas for various environments, however we’re going to use it on this article to indicate the pliability of the method. Additionally, in an everyday state of affairs, we’d be utilizing two separate subscriptions, and the one change required is to pick out a unique subscription within the duties of every atmosphere inside the Azure pipeline.

Cleansing up the code

The exported template from the useful resource is purposeful. Nonetheless, it has lengthy and sophisticated variables, and it’s not optimized in any respect. It helps to construct the atmosphere because it was, however nothing else.

The very first thing was to scrub up the parameters.json file. We created two variables: pVirtualNetworkName (we renamed this one), which we’re going to assign for now TEMPLATE-Identify worth. The second variable launched was pLocation, which we’re associating for now with Canada East.


Within the template.json file, we cleaned up pointless strains of code, and the result’s proven under. We matched the parameters coming from the earlier file, and use these parameters all through the ARM template.

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": 
    "pVirtualNetworkName": 
        "type": "string"
    ,
    "pLocation":
        "type": "String"
        
,
"variables": ,
"resources": [
    
        "type": "Microsoft.Network/virtualNetworks",
        "apiVersion": "2019-09-01",
        "name": "[parameters(‘pVirtualNetworkName’)]",
        "location": "[parameters(‘pLocation’)]",
        "properties": 
            "addressSpace": ,
            "subnets": [
                
            ],
            "virtualNetworkPeerings": [],
            "enableDdosProtection": false,
            "enableVmProtection": false
        
    
]
}

After saving and committing the adjustments to the grasp, a brand new launch is mechanically created and a brand new digital community (we’re utilizing a unique title than we had within the earlier article) was created. For now, that’s anticipated, and we are going to accommodate the adjustments to match the manufacturing atmosphere and create the DEV atmosphere as nicely.

Azure DevOps

Enhancing the discharge pipeline: First wave of adjustments

Now that we have now a viable product that means the ARM template recordsdata can create a digital community with the identical configuration of the manufacturing digital community. Nonetheless, we have to enhance and make it extra dynamic.

Within the Azure DevOps venture, click on on Pipelines, after which on Releases. Choose the launch that we created within the earlier article and click on on Edit. Step one is renaming the present launch (Merchandise 1). Click on on the pencil icon, and we’re going to use the title of the Service/Software-Launch as naming conference. The second step is to use the identical naming conference on the discharge names, which helps to determine the workload anyplace in Azure DevOps.

Final however not least, click on on Save (Merchandise 3) to avoid wasting our present progress. Once we wish to create a brand new launch with out adjustments within the set off (in our case, a decide to the grasp department), we will at all times click on on Create launch (Merchandise 4). Word: They’re mutually unique when the Save is grayed out, then Create launch will likely be out there.

Azure DevOps

Our subsequent cease is to create variables that will likely be used to manage our pipeline. Click on on the Variables tab, and we’re going to use the next naming conference var-<EnvironmentCode>-<Parameter>. We’re going to begin with Location and Useful resource Group Identify. Click on on Add, specify the variable title and its worth, then click on on Save when full.

Time to start out eradicating static code. We are going to begin by introducing the brand new variables within the pipeline.

Click on on Duties. (Proper now, we have now simply DEV, however when having extra levels, we have to choose which stage we wish to see the duties), and we’re going to carry out some updates on the appropriate aspect.

The primary merchandise to vary is the Show Identify. We are going to use the DEV-Useful resource Supervisor Replace (Merchandise 1) to discuss with our DEV atmosphere. Within the Useful resource Group subject (Merchandise 2), we are going to use $(var-DEV-ResourceGroupName), and that’s how we use variables within the pipeline. The worth outlined within the variable will likely be consumed on this subject.

We’re going to use the opposite variable within the location subject (Merchandise 3). Click on on Save after which Create launch to see the adjustments within the atmosphere. The result’s a brand new useful resource group title utilizing the worth of the variable, positioned within the Canada East area.

Variable or parameters.json?

We are able to at all times use a parameters.json file to offer the data that we wish to be deployed in any given atmosphere, and it really works nice when implementing a single atmosphere. Nonetheless, how can we remedy the issue of deploying the PROD, UAT, and DEV utilizing a single file? Remember the fact that the digital community can have a unique title on every atmosphere.

A doable resolution is to create three separate parameters.json recordsdata and use each in a unique activity inside the launch pipeline. It does work, however it’s not elegant as a result of we should handle three separate recordsdata.

We are going to remedy this dilemma by creating a brand new variable known as var-DEV-VirtualNetworkName and assign a price of DEV-CanE-VirtualNetwork within the pipeline utilizing the identical course of that we have now simply accomplished within the earlier part.

We’re going to use the sector Override template parameters, and we’re going to click on on the ellipsis beside of it. A brand new window will present up with all of the parameters outlined within the file, and we will present values. We’re going to add a variable that we have now simply created for the digital community title and the identical variable that we used earlier than to outline the placement.

We’re going to save the adjustments and create a brand new launch. The outcomes are a useful resource group and digital community in the appropriate area (Canada East), and the title of all sources is right, and they’re coming from the variables. The precise information within the parameter recordsdata are being overwritten as a part of the pipeline.

When must you use variables? We should always use for settings which are frequent in all environments, comparable to IP ranges, subnet info, options to be enabled, and so forth. Every thing that’s distinctive in any given atmosphere must be managed on the pipeline degree.

Azure DevOps: Another cease on our journey

At this level, we have now a launch pipeline that’s triggered when the grasp department of our repo receives an replace. The digital community title and area are outlined on the pipeline as a substitute of the predefined values of the parameters.json file. In our subsequent article, we’re going to add a second atmosphere and test a few of the benefits of utilizing DevOps to audit adjustments.

Featured picture: Shutterstock


Put up Views:
64

Extra Azure DevOps articles






Learn Subsequent


About the Author

Leave a Reply

Your email address will not be published. Required fields are marked *