Automating code deployments through Azure — In-Place deployment

A guide on carrying out In-Place deployments with the help of Azure DevOps.

Published in

DATA PEACE AI

7 min readOct 2, 2020

Today we are starting a series of blog posts that will talk about how to automate your software deployment journey through Microsoft Azure. If you haven’t already worked on Azure, this is the right time to Get started.

This is the first post of the series where we’re going to discuss how to carry out In-Place deployments using Azure DevOps Service.

Prerequisites

Before we begin, it is assumed that you have:

An existing Azure account or sign up for your Azure free account.
Access to Azure DevOps with appropriate permissions.

and that’s it.

What is Azure DevOps?

Azure DevOps is a Microsoft product that enables DevOps capabilities. It’s an end-to-end DevOps toolkit that provides a version control system, project management, automated builds, testing, and release management capabilities. It offers various services to facilitate the complete software development lifecycle.

Azure Boards: Provides agile tools to plan, track, and discuss work across your teams.
Azure Repos: Provides unlimited, cloud-hosted private Git Repos and collaborate to build better code with pull requests and advanced file management.
Azure Pipelines: Build, test, and deploy with CI/CD which works with any language, platform, and cloud.
Azure Test Plans: Test and ship with confidence using manual and exploratory testing tools.
Azure Artifacts: Create, host, and share packages with your team and add artifacts to your CI/CD pipelines with a single click.

However, in this post, we will utilize only Azure Repos and Azure Pipelines to connect with the Git Repo and carry out the deployment using Azure Pipelines.

In-Place Deployments

Azure doesn’t have a term or any option referred to as In-Place deployment, rather In-Place deployment is a type of deployment in which the running application on each Virtual Machines needs to stop. Post that, the latest application gets installed on Virtual Machines, and then the application is started.

This brings us the advantage of making software deployments smoother and faster but comes with the disadvantage of providing downtime until the newer piece of code is installed and running successfully. Anybody doesn't like the idea of taking down his/her service whenever a new feature is released. It would be a loss of huge potential clients.

That’s where another deployment type— Blue-Green deployment comes into play. This technique mitigates risks associated with deploying software, such as downtime and rollback capability. However, in this post, I will only talk about the In-Place deployments through Azure. In the next part of the series, I will show you how to carry out Blue-Green deployments using Azure.

Target an Environment

An environment is a collection of resources, such as Kubernetes clusters and virtual machines, that can be targeted by deployments from a pipeline. Environments can be helpful in getting Deployment history, Traceability of commits and work items, and Diagnosing resource health.

We need to target an environment to the Azure Virtual Machines by registering them. Navigate to https://dev.azure.com and sign in to your DevOps organization.

In your project, under Pipelines, select Environments.

Click on create a new environment, provide name and description of the environment, and select Virtual Machines as a resource. Next select Linux under the Operating System, since we’re targeting the Linux VM’s.

It will give you a registration script that you can run on your Target VM’s. You can run this script on as many VM’s as you want to target. Once VM is registered, it will start appearing as an environment resource. During the registration it will ask you to assign a tag to your VM’s, you can do it at that time or afterward through the Azure DevOps portal when all the VM’s are successfully registered.

Alongside with the registration script, you can install and configure Azure CLI in order to run Azure CLI commands on the Virtual Machines. This is a one-time setup.

Set up the Deployment Pipeline

Take a look at the below diagram. It will explain to you how we’re going to automate the software deployment to the Linux Virtual Machines with the help of Azure DevOps whenever a new code is being pushed to the version control system.

Let’s say you’re using a version control system maybe GitHub where you push your changes and with that, you want to deploy the newer code to the Azure Virtual Machines. For this, you need to set up a pipeline using GitHub Actions. This lets you create a pipeline where a deploy job can be created that on every push creates a zip archive of the source code and uploads them to the Azure Blob Storage. Once the source code gets uploaded to the Azure Blob Storage, we will run the Azure DevOps pipeline file which will download the source code from Azure Blob Storage and run the setup files (configured by you) on the Azure Virtual Machines in order to make the application up and running.

With that go ahead and create an azure-pipelines.yml file at your project’s root with the following content:

Let’s break it down:

stages:
- stage: Deploy
  displayName: Deploy stage

A pipeline is one or more stages that describe a CI/CD process. Stages can contain many stages. A stage is a collection of related jobs. It can be a build job, test job, or deploy job. Here we have defined a Deploy stage that will eventually be used to deploy the source code from Azure Blob Storage to the Azure VM’s.

jobs:
  - job: Deploy
    displayName: Deploy
  - deployment: VMDeploy
    displayName: dev
    pool:
      vmImage: 'Ubuntu-18.04'
    environment:
      name: Development
      resourceType: VirtualMachine
      tags: dev

A job is a collection of steps run by an agent on a server. We have to define a deployment job in our pipeline. A deployment job is a special type of job that is a collection of steps, which are run sequentially against the environment. Next, we have to target the environment’s name and resource type that we’ve set up earlier. It will identify the target VM’s registered for deployment.

strategy:
      runOnce:
        deploy:
          steps:
          - script: |
              echo "Downloading the source code from Azure blob storage container to the Azure VM..."
              sudo az storage blob download --account-name mydemoaccount001 --container-name application-container --name test-application.zip --file /opt/test-application
              echo "Extracting the source code and setting up the application to the Azure VM..."

Lastly, we are defining the deployment strategy that is used to deliver the updates. For the time being lets use runOnce deployment strategy which is the simplest deployment strategy wherein all the lifecycle hooks, namely preDeploy deploy, routeTraffic, and postRouteTraffic, are executed once. Here we have mentioned inline scripts that will run on the target VM’s which download the source code from Azure Blob Storage Container to the specified location. You can create a shell script that will do all the heavy lifting for you and make your application up and running.

This shell script can be shipped along with your source code to the targeted VM’s and you can define it in the inline script in the deployment job of your CI/CD pipeline once the source code is downloaded and extracted onto the targeted VM’s. Please check here for the complete reference of the deployment job in Azure Pipelines.

Time for the CI/CD

Now that you’ve set up your environment and configured your CI/CD pipeline, it’s time to test the things. In the Azure DevOps portal, navigate to your project, under Pipelines, and create a New pipeline.

It will ask you where is your code located? Select GitHub or any other VCS from the options presented in front of you.

For the first time, it will take you to your GitHub account for authentication. After successful authentication, select your repository where your code is maintained.

Lastly, configure your CI/CD pipeline and Review. Now for every new commit being pushed it will trigger the CI/CD pipeline which will eventually deploy your latest code to the targeted Azure Virtual Machines.

You can view the status of all the Pipelines under the Runs section. It will display all the pipelines whether they have passed, canceled, skipped, or failed.

To summarize, you now have a fully functional CI/CD pipeline to perform In-Place deployments in Azure through Azure DevOps Service. You can now automate your code deployments from your favorite VCS to Azure Virtual Machines with every new commit being pushed.

In the 2nd Part of this series, I will show the complete steps to perform Blue-Green deployments with the help of Azure VMSS, Azure Load Balancers, and Azure Traffic Manager.

If you enjoyed this post, consider spreading by emailing it to a friend or a colleague. Thank you!

References

To learn about workflow syntax for GitHub Actions — Workflow syntax for GitHub Actions.