Producing great software is only half the battle--or more like 1/3 of the battle. Software is worthless until it gets in the hands of the people that want to use it. To do that, though, isn’t simple.
Software can be complicated enough but to get that software first compiled in a usable form, tested and then delivered is an orchestration of activities that take some organizations years to master.
Once the software has been packaged up into a usable form from a bunch of text, it then goes to testing. To test that software, it has to be deployed. It is typically deployed in multiple test environments first and then onto production where its end-customers get their hands on it. The task of deploying that software should be automated. In the Microsoft ecosystem of DevOps tooling is the Visual Studio Team Services’ Release Management feature or what I’ll be calling RM.
RM is a feature under the VSTS umbrella that deploys software to many different environments through an automated and on-demand process.
According to the RM site, RM runs through each of the following tasks as part of the release deployment process.
- Pre-deployment approval - Is the deployed approved?
- Queue deployment job - Schedules the deployment.
- Agent selection - Figures out the best agent to use for the job.
- Download artifacts - Compiles together all of the artifacts (files, scripts, whatever) that are part of the deployment job.
- Run the deployment tasks - Executes the deployments tasks like which environment to deploy, scripts to run, etc.
- Generate progress logs - Creates logging activity of all processes during the deployment.
- Post-deployment approval - Was the deployment successful and as expected?
The Release Definition
To know how to execute all of these tasks, RM depends on a concept called a release definition. The release definition is essentially a manifest of instructions for a given release. A release definition consists of information such as how the release will be triggered, which tasks to perform when the release happens, and which environments to deploy the software to. The release definition is everything that’s involved in the entire release process.
A release definition is created via the Releases section under the Build and Release hub in VSTS. During the release definition creation process, you can pick things to define how the release will be triggered, which version of an attached build will be run and any artifacts to deploy as part of the release. This is where you can also pick which agents to run the deployment on, the schedules that the deployment will follow and set up the logic of how to determine which environment to deploy to.
Although it’s possible to create release definitions from scratch, RM also provides the ability to create release definitions from templates. Once a release definition is created, you have the option to “Save as Template” which you can then refer to later to expedite creating future release definitions.
Releases
Once a release definition is created, you now have the ability to create a release from that. A release is a deployment workflow. The release is the action that’s taken from the input of the release definition. For example, if you have setup a release definition to trigger a release when build XYZ is finished, send an approval to the QA manager, wait for approval and once approved, deploy to a staging environment, the release is what would make all that happen.
The release is where you can optionally define what environments a deployment will go if not already setup via the release definition. Setting up a release is easy once all of the configurations have already been done via the release definition.
Summary
Release management in VSTS is an excellent service for any organization practicing DevOps. It automates that final step in the software development process to get the bits deployed to test environments and to production.