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
andstaging
branch - Running a few build commands to build the artifact (notably
Angular
andNode.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 inweb-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:
- Slack / Microsoft Teams chat integration. (You can set up a channel to receive specific alerts and notifications from Azure DevOps)
- Azure Pipelines (there’s many more features to explore here)
- Azure DevOps Artifacts (keep track of software artifacts and published libraries)
- Azure DevOps Test Plans (produce better software with automated, comprehensive testing)
- 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.