This is the second of 2 posts on the subject of jumping into Azure DevOps for the first time! Click here to view the previous post on Continuous Integration Pipelines. Continuous Integration/Continuous Delivery, often abbreviated CI/CD, has become a hot button topic in the last few years alongside the rise of "DevOps" methodologies and practices. Today we will focus on the Continuous Delivery aspect of the Azure DevOps Pipelines tools. Once again, we'll be mainly focused on this through the eyes of an IT professional, rather than from a business standpoint. There are many great reasons for a business to buy-in to Azure DevOps, and more specifically pipelines, but we will discuss those in a future post. Go to https://devops.azure.com to get started with Azure DevOps and Pipelines!
Azure Release Pipelines facilitate the concept of Continuous Delivery. Continuous Delivery is the practice of automating the deployment of your software builds to a "production" or "release" environment as features are completed and deemed suitable for deploying to that environment. Please note that as we go through this post, we will be consuming the output from the Continuous Integration pipeline that we created in our first post! So let's go ahead and get started setting this second part up.
When you go to create your first "Release Pipeline", click on the "Pipelines" blade on the left, and the "Releases" sub-item to get started. You'll get a nice, friendly screen that should be fairly obvious of what to do next.
Let's go ahead and click the "New Pipeline" button in the middle to start configuring our new release pipeline! On the next screen, we're prompted to choose our deployment target or "template". There are a host of options available from on-site IIS (remember that Azure DevOps' codebase is shared with the on-premise version) to Azure App Services to Kubernetes. AWS isn't an option by default, but I would guess that there are community deployment tasks that could facilitate this, whether in an Azure context or on-premise. For our purposes today, however, we'll be deploying our .NET Core Web Application to an Azure App Service. Creating an Azure App Service is beyond the scope of this post, but to summarize, I created a windows-based, Free Tier App Service targeting a .NET Core 3.1 application.
Once we have our template selected, you are presented with a screen that represents the workflow of your new pipeline. This is quite a bit different than the YAML-based configuration we saw in our CI pipeline! Instead of a code-like script, we now have a workflow-based layout. While I think this screen is trying to be more user-friendly, I find it a little confusing on what you're supposed to do next.
The 3 highlighted items in the image above are actually what we need to be focused on. Again, I don't think it's very intuitive, but if you actually click "New release pipeline", you can rename it to something more suitable. I chose "Staging Release Pipeline" for this demo. Next, we need to add an Artifact. An Artifact is a broad term for referring to pieces of the Software Development Lifecycle, but in this context, we are referring to deployable item. Most often, and indeed in our case, we'll be deploying the output of a Pipeline build. Specifically, the built output from our previous post! So let's click that Add button hightlighted above and see what happens.
When I chose the "Build" tile at the top, the Project, Source, Default Version and Source alias all auto-loaded from the CI Pipeline that we already configured! While mentioned in the previous post, it's worth pointing out that the "artifact" generated by the CI build is actually created by the msbuildArgs line item that actually "Publishes" our build output. Recall also that we added a "PublishPipelineArtifacts" custom build item to set that output aside for future use (which is now)! Let's connect up to our pre-configured Azure App Service.
Since I am logged into Azure DevOps with my Microsoft Account (and you will be too), DevOps was able to auto-populate my Azure Subscriptions, and subsequently, my App type and App Service names based on that selection. You might have to Authorize DevOps to access your Azure account if you've not set any release pipelines up yet.
In most cases, you should be able to just click "Authorize" and it will be done! Now that all of that is set up, we're ready to actually create a release! We're just going to fire it off manually here this first time. You'll do so by clicking the "Create Release" button at the top.
Go ahead and take the default settings and move on! Hopefully, everything went smoothly, and you are presented with a nice graphic indicating that all is well and the published output is now deployed to Azure!
The most common issues you'll run into are going to be that the publish output was not staged, or improperly staged in your original Continuous Integration Pipeline. Again, pay attention to ensuring that VSBuild is executing the publish with the proper msbuildArgs set up and that your YAML includes that "PublishPipelineArtifacts" task at the very end of the build. I spent a lot of time tracking those 2 settings down and putting them together, so I'm hoping that this post alleviates that pain for at least one person and saves he or she some time!
Next, let's set it up so we can have a 100% hands-off experience by configuring the continuous part of Continuous Delivery! Go to the main edit page of your Release Pipeline and click the lightning bolt attached to your Artifact tile.
Simply enable the continuous deployment trigger, save and now your pipelines will all run in sequence, whenever anyone checks in code! To break it down, when a developer checks into the master branch, it will fire the Continuous Integration pipeline. Since that Pipeline serves as the input to this new Continuous Delivery "Release" Pipeline, its successful completion will subsequently trigger the Release Pipeline to execute as well.
This represents a very simple, fully automated CI/CD pipeline that will execute start to finish every time someone pushes code to the master branch of your source code repository! While there are many useful benefits to this kind of automation for a business, from a software developer's perspective, it should be clear that the time spent tracking down broken builds, planning for deployments and deployment downtime should be cut down to a minimum if this kind of a workflow is implemented early, and kept up to date! Azure DevOps also has more advanced capabilities like forcing management approvals on builds and more! We'll save those details for a later post when we discuss the business side of the Azure DevOps tools.
I hope this set of posts helped you get started in the Azure DevOps or even in the broader world of automation! Need more help getting started? Call the experts at Software Design Partners to help you get your team and projects started on this journey!
Let SDP create a competitive edge for your business with an individualized assessment of how to utilize and implement Azure DevOps or the broader world of automation! Contact the experts at Software Design Partners to help you get your team and projects started on this journey!
Steve Danner is the Director of Technology at Software Design Partners. He specializes in software development implementations, but also manages the company network infrastructure, provides technology and application architecture direction for the development team, engages clients to provide technology solutions for their business challenges.
