Skip to main content

Azure ARM Infrastructure as code deployment using VSTS - Part 2

In Part 1 of the blog series , we created the build configuration for CI/CD pipeline of ARM template deployment. In this blog, we will create the release pipeline and deploy the VMs across dev and test environments in Azure when a commit is triggered

Create the release pipeline by clicking on the release option once the build is completed

In the Release definition, select a blank template to start with

And provide name of your first environment

Now we have our first environment ready, lets add the tasks. Select the created environment.

Start adding tasks from Tasks->Deploy->Resource Group deployment

Edit the settings of the added task. You need to add your Azure subscription to VSTS as a service endpoint

Click on Manage and it will open the service end point configuration in a different tab. Add your Azure subscription here.Click on New Service Endpoint->Azure Resource manager

Add Subscription name , when you click ok you will be ask to login to your Azure subscription to authenticate.

Once that is done, Your subscription will be listed in the release task drop down list and you can select it

Select action as "Create or update resource group".Select the target resource group and the location, which is essentially the target Azure region, from the drop down list. Select template location as linked Artifact.

Browse and select  the ARM JSON file from the linked artifact

Depending on the Target environment select the parameters JSON file as well.Select deployment mode as incremental.

Save settings once done

Now you can add the next environment to the pipeline. Click on the plus sign below the existing environment

Provide a differentiating name

Add the deployment tasks like it was done for the first environment. You can change the subscription/resource group/location etc to differentiate it from the dev environment. Also the parameter file should be selected as per the target environment.

Save the changes and with that the release configuration is completed. This is how the continuous deployment pipeline will look like

If you click on the pre-deployment condition for the environments, it will be configured to be auto triggered. For eg, the test environment deployment will be triggered once the dev environment deployment is completed. You can also choose to change it as per your release process requirement

Every time the code is committed in the source repository, the Continuous integration trigger in the build config will start a build. The artifacts of this build includes the JSON file and the target environment parameter files. The continuous deployment process is defined in the release process, which will be auto triggered after the build is completed.

Depending on the target environment settings, the template will be deployed in multiple Azure environments.

PS: If you are interested in Cloud Automation, do check out my book on Azure Automation available in Amazon :


Popular posts from this blog

Cloud Security - Risk factors

Cloud security is a major consideration for enterprise wide cloud adoption, especially public cloud. This is part 1 of a serious of blog posts , where I am planning to pen down the different dimensions of Cloud security, starting with the risk factors of cloud adoption. The various attributes of security risks  involved in the process can be summed up as follows: ENISA* recommends the following  risk areas to be taken into account, while embarking on a cloud adoption journey

Windows server 2012: where is my start button??

If you have been using Windows Server OS for a while, the one thing that will strike you most when you login to a Windows server 2012 is that there is no start button!!.. What??..How am I going to manage it?? Microsoft feels that you really dont need a start button, since you can do almost everything from your server  manager or even remotely from your desktop. After all the initial configurations are done, you could also do away with the GUI and go back to server core option.(In server 2012, there is an option to add and remove GUI). So does that mean, you need to learn to live without a start button. Actually no, the start button is very much there .Lets start looking for it. Option 1: There is "charms" bar on the side of your deskop, where you will find a "start" option. You can use the "Windows +C" shortcut to pop out the charms bar Option 2: There is a hidden "start area"in  the bottom left corner of your desktop

Install nested KVM in VMware ESXi 5.1

In this blog, I will explain the steps required to run a nested KVM hypervisor on  Vmware ESXi. The installation of KVM is done on Ubuntu 13.10(64 bit). Note: It is assumed that you have already installed your Ubuntu 13.10 VM in ESXi, and hence we will not look into the Ubuntu installation part. 1) Upgrade VM Hardware version to 9. In my ESXi server, the default VM hardware version was 8. So I had to shutdown my VM and upgrade the Hardware version to 9 to get the KVM hypervisor working. You can right click the VM and select the Upgrade hardware option to do this. 2)In the ESXi host In /etc/vmware edit the 'config' file and add the following setting vhv.enable = "TRUE" 3)Edit the VM settings and go to VM settings > Options  > CPU/MMU Virtualization . Select the Intel EPT option 4) Go to Options->CPUID mask> Advanced-> Level 1, add the following CPU mask level ECX  ---- ---- ---- ---- ---- ---- --H- ---- 5) Open the vmx