In every delivery pipeline, there are critical practices that you might want to implement when you're adopting a DevOps culture. These practices include infrastructure as code, continuous integration, release management, and product management. If you're going to start working with Microsoft's cloud, it's going to be critical to know that there's more than the right-click publish in Visual Studio to deploy applications to Azure.
If you're reading this, you're probably already aware that DevOps is not just about tools. And you probably also know you can't entirely change an organization by simply adopting a new process or methodology. Culture change, in this case, is going to be critical. But if you're able to create a proof of concept that proves the benefits of DevOps, it's going to be a good starting point.
There are a lot of tools and services you can use to deploy applications to Azure. Therefore, I'm just going to mention a few options that will help you implement essential DevOps practices.
Let's get on it.
Infrastructure as Code
Azure has its own implementation for treating your infrastructure as code. You define the state with a JSON template—which you can't consider code—and include it in a Git repository. That way, you'll have the same benefits you would with code. I'm talking about benefits like versioning, visibility, branches, and pull requests. The Azure Resource Management (ARM) template is the deployment and management mechanism in Azure for your cloud infrastructure. You can create reusable templates, either to provision environments on-demand or to recover from a failure in a different region.
If you have no experience creating ARM templates, you can start creating the desired architecture in the Azure portal, as in the image below. Then, you export the template from the resource group (as shown by callout 1 in the image) and start from there. You can later work on creating reusable templates (as callout 2 illustrates) with parameters, use variables, use outputs, links with other templates, and more.
But Microsoft is aware that there are other popular tools in the market, like Terraform. So you can also provide infrastructure using Terraform if the team has the experience. And if you're still going to use infrastructure as a service, Packer has support to create repeatable VMs in Azure.
If you want to practice continuous integration, you can start by using Azure Pipelines.
After you've created your infrastructure templates, you can orchestrate them in Azure Pipelines. You'd use Git as the source and decide if you want to use the source from the master or any other branch. Run the build every time a pull request is created to preview the changes. And you can even automate the build job execution after every push. Of course, in this case, you have to depend on an automated test battery, in accordance with continuous integration principles.
But it's not just about provisioning infrastructure from templates. You can also include application compilation, testing, and packaging (as shown in the image below). Azure Pipelines has a variety of integrations with different programming languages, platforms, and tools (like Jenkins, for example). Moreover, you can manage your building agents with the tools you need, isolate the agent, and use the security policies from your organization. You'd be able to roll back when the build is broken. Or you can implement feature flags and work with variables when defining the build job.
What's compelling about Azure Pipelines is that you can also create your build pipeline definition using YAML and apply the same principles from infrastructure as code. You'd make any change from the template in Git, and everyone on the team will know the complete workflow of the build pipeline.
After you have the infrastructure and the application ready to be deployed, it's time to release it.
You can still use Azure Pipelines to create the release definition, but at the time of writing this post, you can't use YAML to define the pipeline. Nonetheless, you still have the support for a variety of tools, services, platforms, and even cloud providers. Azure is better integrated, and you can easily create and configure the set of tasks to deploy the application to something like Azure App Service. You can also use variables, conditions, gates, triggers after the build pipeline, schedules, and a lot more. You have the freedom to configure the pipeline according to your needs, with any existing tool or service you use.
The way the build and release pipelines communicate with each other is through artifacts. An artifact usually contains the application compiled and any other type of configuration you'd need when deploying the application. With this separation, you can apply the principle of build only once and then deploy many times. For each environment (or stage), there might be specific variables that could be replaced at the deployment time. When you need to configure the application, you can use other tools like Ansible or Chef, which are also supported.
Here's what a release pipeline that the deploys the same artifact to three different environments looks like:
As I said before, you have freedom of creating the release pipeline however you wish. You can include fewer tests for the development environment and include more tests in production. It's possible to automate the transition from stage to stage, but you can also add reviewers or gates for compliance reasons.
Lastly—but not because it's less critical—you can integrate product management into your delivery pipeline.
When you work with Azure DevOps, every time you create a new project, you can choose from Agile, Basic, CMMI, and Scrum as the process to manage work assignments. And you can have team assignments in one place. Depending on the methodology you choose, you can create work items to report bugs or new features. You can also create a backlog, a sprint, or reports that you can use later to create dashboards.
But the purpose of having your product management and delivery pipelines in one place is that you can measure how work is progressing. For example, you can keep track of every time a developer commits code or a branch is merged to master. Or you can include a reference to a work item. The takeaway? Anyone will be able to track how much time a work item took the team to finish it and how it was progressing throughout the entire delivery pipeline.
Remember, it's not just about improving the process of shipping software. It's also about the value of the feedback you get after you deliver features or bug fixes. With Azure DevOps, you'll always know the current status of the project, and you'll know where there are opportunities to improve the process.
Azure DevOps Services
Microsoft has an excellent offering to help you implement DevOps practices in Azure DevOps—even though the name isn't perfect because DevOps is not a tool. This suite integrates natively with Azure, and you can have everything in one place: the code, the delivery pipelines, and product management.
As a bonus, you don't have to migrate from any existing tools. That's because there are a lot of integrations for platforms and services in Azure DevOps. A tool has to adapt to your needs, not the other way around.
And as a final note, just let me remind you that having useful tools and practices in place is only a portion of what makes DevOps great. The most challenging part is going to always be shifting the culture. But at least you can build your proof of concept with the tools and practices listed in this post. This proof of concept can be the entry point to start a transformation with Azure in your organization.