Accelerating DevOps in Microsoft Azure

Introduction

DevOps has been breaking into the engineering world and culture at an alarming rate. Enabling efficiencies by combining development and operations teams has cut costs across the board for thousands of companies, regardless of size. Whether you are a QA engineer for a Fortune 500 corporation or the visionary and product lead for a small startup, chances are that you have been exposed to the culture of DevOps.

A cursory lookup of DevOps on Wikipedia gives DevOps the following definition:

DevOps is a set of software development practices that combine software development (Dev) and information-technology operations (Ops) to shorten the systems-development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.

I will digest that lengthy definition from the perspective of a member of a team who has donned on the hats of Developer, Operations, QA, and Business Analyst. We will be using Microsoft Azure DevOps to showcase parts of the DevOps culture.

For those interested in diving into Azure DevOps, please understand that some services shown cost money to run or maintain.

Azure Boards

Azure Boards allows your team, whether it is small or numerous, to effectively track, manage, and coordinate progress on Work Items (tickets). Using a very intuitive interface, a team trained in Agile development methodologies could quickly get started with little overhead project management. There are several different view types within Azure Boards, but my favorite is the Board view:

It allows you to see at a quick glance where your team’s progress stands. If all members of your development team stay on-top of their tickets, the Board can stay clean and readable. Another view provided is the Sprint View:

For agile teams, this feature is a must. In the top-right corner, you can specify your sprint timeframe. If you have enough sprints recorded or planned, Microsoft Azure DevOps will figure out how long your standard sprint is when you try to create future sprints. Separated into three simple columns of To Do, Doing, and Done, Azure DevOps provides you several different view types to ensure you do not get lost in the minutiae of project management.

However, if you are a fan of project management metrics, Azure DevOps has several features that can enable productivity for DevOps. One of the views I use the most from a project management perspective and business analyst perspective is the customizable Dashboard view:

With the Dashboard view, you can configure a plethora of custom and pre-set widgets. For example, for business continuity and disaster recovery purposes, I need to know if a deployment to the Production Pipeline failed. Furthermore, as a project manager, it is extremely helpful to see the team’s progress over a period of time, as it allows me to act on any roadblocks that are slowing down the team.

Azure Repos

Support for integration with the code repository is, possibly, one of the unsung heroes for the DevOps culture movement. Azure DevOps Repos supports several different types of version control system software, notably Git and Github. You can securely connect to remote repositories hosted by Azure DevOps, and you can even import an existing repository!

Much like Github and other Graphical User Interfaces for Git, you can see active pull requests, assign reviewers, and, one of my favorites, attribute work items from Azure Boards with Pull requests. These features sync up well with common team development paradigms like code reviews, pair programming, and quality assurance.

There are a few ways to get your work tickets from Azure Boards integrated with Azure Repos. My preference is helpful from the perspective of a Project Manager—go to the Board view, click on a ticket, and under the Development section you can link the ticket to Azure Repos!

These areas of integration across DevOps and Boards allow for greater efficiency in your development and operations team.

CI/CD

Another concept you may have heard about is Continuous Integration (CI) and Continuous Deployment (CD). An important distinction here to make is that there are some technicalities and semantics at-play here. When HR, Marketing, and Engineering combine to form these phrases, sometimes there’s misunderstandings and overlap.

CI/CD can:

• include both CI and CD;
• be a combination of tools that enable a “CI/CD Pipeline,” where developed software artifacts can follow a process to be automatically pushed through to a production environment; and,
• incorporate Continuous Delivery, where code changes and software patches can be produced in quicker development cycles (often leveraging CI/CD Pipelines and agile teams)

CI/CD is NOT

• CI or CD. The two terms are NOT interchangeable.

One of the reasons for the confusion is that it is possible to have CI without CD and vice versa—it is all dependent upon the use case! Some software applications may not require active updates, making a full CI/CD pipeline an over-engineering effort. Additionally, some customers may prefer limited interactions with the product team and longer development cycles. However, in the modern DevOps culture, it is commonplace to find many development teams incorporating CI/CD into their software.

Azure Pipelines

Azure DevOps can accelerate the CI/CD process using Azure Pipelines. In just a few minutes of configuration, you can get an automated pipeline set-up to deploy your code to an Azure Virtual Machine or Azure App Service. To start off the Azure Pipelines process, you will have to specify an azure-pipelines.yml file. This file will configure your build artifacts that you will be using throughout the pipeline. Here’s an example of that file:

# Node.js with Angular
# Build a Node.js project that uses Angular.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

# Only trigger builds for commits that change something in the console.
trigger:  
  batch: true
  branches:
    include:
      - master
      - staging
  paths:
    include:
      - web-console/*

pr:  
  branches:
    include:
      - master

pool:  
  vmImage: 'ubuntu-latest'

steps:  
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Install Node.js'

- script: |
    cd web-console/angular/client
    npm install
    npm run production
    cd ../../server
    npm install
    npm run tsc
  displayName: 'Set up Angular and Node App'

- task: CopyFiles@2
  inputs:
    SourceFolder: '$(System.DefaultWorkingDirectory)'
    Contents: |
      web-console/angular/client/dist/**/*
      web-console/server/dist/**/*
    TargetFolder: '$(Build.ArtifactStagingDirectory)'
  displayName: Copying Files for Build Artifact

- task: PublishBuildArtifacts@1
  displayName: Publish Build Artifact

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
    includeRootFolder: false
  displayName: Archive Build Artifact

There’s a lot going on in the script, but here are the notable ones:

• Triggering build artifacts when changes occur on the master and staging branch
• Running a few build commands to build the artifact (notably Angular and Node.js)
• Specifying the build to run on an Ubuntu pool agent
• Copying only the compiled files in the dist directory (also ignoring other parts of the code base not in web-console directory)
• The Publish Build Artifact allows me to use the built artifact in other parts of Azure Pipelines, notably for Releases

After building your artifacts, there’s the concept of a release. This is where your artifact can be deployed to an Azure resource such as a Virtual Machine or App Service. This feature accelerates DevOps teams to production by providing an automated pathway for deployment of artifacts.

Teams are also given the option to include several best practices of security and development through triggers, gates, and configuration management. With triggers and gates, you can manage a set of actions and approvals before and after a step in the deployment pipeline process. For example, if you are deploying to production and need a manual step for approval by manager, this can be done. If you only want the pipeline to fire automatic updates to the environment based on the updated code repository branch, this can also be done. Lastly, if your team has offloaded configuration to a secure location (i.e. Azure Key Vault for secure data-at-rest), this can be achieved through a Variable Group.

As an example, you could have two pipelines for a given application or system: staging and production. Staging could be a branch within your main repository in Azure Repos that your development team primarily works on. QA and Business Analysts could be involved within the staging branch to set requirements and quality check pull requests. Furthermore, the master branch could be locked off to a subset of your development or operations team. Pull requests submitted to master could then trigger a separate production pipeline that requires variable steps of manual approval from management.

However, one of the best things about DevOps is the flexibility the culture can be for your team. Developers can become business analysts, quality assurance, project management, and so much more all in their own rights. Like agile, the benefits of DevOps, and some of the tools used to enable it, come via flexibility within your development team.

Miscellaneous

The number of features that help enable the DevOps culture in development teams is expansive in Azure DevOps. Many of them would do well to have their own article or post written! Here are some other great areas and features that you could explore to accelerate DevOps in your team:

1. Slack / Microsoft Teams chat integration. (You can set up a channel to receive specific alerts and notifications from Azure DevOps)
2. Azure Pipelines (there’s many more features to explore here)
3. Azure DevOps Artifacts (keep track of software artifacts and published libraries)
4. Azure DevOps Test Plans (produce better software with automated, comprehensive testing)
5. Azure Project Wiki (onboard new developers faster)

Conclusion

While the examples provided in Azure DevOps paint a very compelling story for the DevOps culture, the real DevOps culture shift is rarely brought about by software. If you’re a member or stakeholder of a development team, do not be led to believe that any software or tool will increase your team’s ability to delivery software at scale and speed! There are a plethora of different tools out there competing for team adoption, and just because Azure DevOps works for me does not necessarily mean it would work for your team. It starts at the individual, contributor level—whether that’s a project manager who juggles between project delivery and team concerns, or a vocal developer who believes in the vision of the product and wants it to succeed does not matter as far as DevOps is concerned.