Release Management Architecture in Visual Studio Online with vNext Environments

Release Management – The Background

Release Management Service in Visual Studio Online (referred as RM-VSO in the rest of this blog post) automates the process of deploying the builds into the target environments. It integrates nicely with the Team Build Service in VSO and both the services can work together to implement a continuous integration/continuous delivery (CI/CD) pipeline. The on-premises version of Release Management has been around for a couple of years, however the Visual Studio Online version has just been recently released, in November 2014, and somewhat different than the on-premises version. (Check the latest on the MS official blog Microsoft Application Lifecycle Management). This blog post focuses on the Release Management Service architecture with reference to visual studio online and vNext Environments.

Skilling up on RM-VSO and deploying a ‘Continuous Integration/Continuous Delivery (CI/CD)’ pipeline is not too difficult. However, the absence of adequate information material (at the time of writing this blog) on RM-VSO and its integration with vNext environment can be a daunting task for someone new to RM-VSO. Current Microsoft resources available on RM are mainly for the on-premises version and one has to rely heavily on the community blogs to understand and implement RM-VSO. There are indeed some good blog posts already published that provide you with step by step instructions (see the links in the reference section at the end), however, when I was looking for the resources on RM-VSO I couldn’t find something that could provide me with an architectural overview, the core components and their relationships, particularly with reference to vNext environments. I reverse engineered the step by step guides to construct the RM-VSO architecture in my mind. It helps to know the core architectural concepts to design and implement a CI/CD solution.

Setting up an RM-VSO based release process can be summarised as

• Connect to the vNext environment and servers in Azure, the targets where the releases will be deployed on
• Define ‘Release Path(s)’, ‘Stages’ and ‘Steps’ that will direct the release deployment workflows
• Define ‘ Components’ that will be deployed
• Have a build definition defined in VSO that VSO will use to produce the builds
• Create deployment script(s) and define variables (to be used in the deployment scripts)
• Define a Release Template, associate it with a build definition and setup deployment flow and actions

However, as mentioned earlier, it is vital to understand the RM-VSO architecture and components for a setting up the release processes. We will first look at the core components in RM-VSO and then how they are related and tied up together to define a release process.

Release Management – The Core Components

The following outlines the list of the key components that are required to be setup/configured to implement a release pipeline.

• RM – Desktop Client: At present the Release Management Service in VSO doesn’t have a web based user interface (due to be released in Q4-2015), therefore the RM Desktop Client is required to perform all the configuration tasks. The desktop client is required to be connected with a VSO instance once after installation and then it will remember the credentials and connection settings.
• Visual Studio Online (VSO): Hosts the Team Build and Release Management services, stores the configuration data and builds; manages the release workflows and controls the release deployment process.
• Azure Subscription: RM needs to be configured with the details of the Azure subscription(s) where the deployment servers are located. More than one subscriptions can be added. RM needs to have the subscription name, Id, management cert. key and storage account name. This enables VSO to connect the target deployment servers.
• Pick List: The lists of the lookup items to be used with release paths
• Stage Type: The stages are an important part of your delivery pipeline. For instance, you can have stages like DEV, SIT, UAT, Staging and Production. The release processes are designed around stages so you need to define them carefully. You can change them later for sure but it will require a lot of manual configuration.
• Technology Type: Not applicable to RM – VSO
• Users: The users in VSO. RM will list the users who have the project administrators’ rights, though you cannot have groups, not supported yet in RM-VSO. 
  
• Inventory: The inventory is used while defining the release template workflows 
  
• Actions: Reusable workflow actions for release templates. At present RM-VSO has only four pre-defined actions, adding new custom actions are not yet supported.
• Environments: You need to pay attention to this term which is referred as ‘Environment’ and ‘Azure Environment’ and also as vNext environments in the RM client and reference text/blogs. In RM-VSO context they all refer to a set of Azure servers, without the deployment agents, that are published under the same cloud service name within an Azure subscription (that has already been added to RM-VSO). You should group your servers wisely under common cloud service names. One release path in RM can hook up to only one ‘Environment’ i.e. if a release path has two stages (Dev and SIT) then you need at least two cloud services wrapping up the DEV and SIT servers separately. You may create a unique cloud service for each of your servers but then it would mean you will need to link as many environments in RM. Also it would mean your release paths won’t be reusable as effectively they would be tied up with individual servers instead of group of servers. 
  
• Server: An Azure server within a linked Azure environment where RM deploy the releases.
  

Before we move forward see the following illustration on how RM-VSO components/configurations are mapped to Azure objects

• vNext Release Paths: A set of release stages with each stage is comprised of approval and verification steps. Release paths are the core building blocks in a release template.
  
• Component: A deployable component to be used in the release template workflow actions. It could be the build drop folder or some file in a specific location in VSO etc.
  
• Build Definition: A release template needs to hookup with a build definition as the source of the build outputs. A build definition can also automatically fire up a release when a build is done.
  
• Variables: The variables allow you to pass on the values through them to the deployment script. This way you can configure the RM deployment processes for different deployment environments while using the same set of deployment scripts. There are four types of variables
  • Global: Available everywhere, in all release templates
  • Server: Associated with a server and available when the server is used in a release template action
  • Component: Associated with a component and available when the component is used in a release template
    action
  • Action: Associated with an action and available when the action is used in a release template. Note: Since we cannot create custom actions in RM-VSO so these variables are only created within release templates and as such they are not reusable. 
• Release Template: Releases in RM are based on release templates. Release template is the place where all the above components come together and define how a release should be deployed and progressed. A release template is composed of a release path (with stages and steps), a build definition, a control flow, actions, servers, a component, a deployment script and variables.
  

Release Template – The thing that knits your release process.

Now after getting an understanding of the key RM-VSO components it is the time to put them together. A release template is the place where all these components gel together. The following diagram depicts the Release Management components and their relationships.

The RM Release Process – A brief summary

The following summary of setting up the release management process can aid in understanding the RM architecture illustrated in the previous

• Link Azure environments
• Add servers from the Azure environments to RM
• Define lookup ‘Stages’ such as ‘Dev’, ‘SIT’, ‘UAT’ etc
• Create reusable ‘Release Paths’ with the stages and appropriate approval steps
• Create Release Templates
  • A release template is bound to a single build definition. A build definition can trigger a release automatically.
  • A release template is based on a release path, that defines the stages and steps
  • An stage in the release path is customised with a control flow sequence and actions
  • A control flow sequence can have multiple actions
• An action is configured with
  • An Azure environment and a sever
  • Userid/pwd to connect to the server
  • Path to the PowerShell or DSC script that will deploy the release package (the script should be included in the build, this is a relative path within the drop folder).
  • A component representing a release package (or a part of it)
  • Custom variables
• Once a release template is created a new release can be requested, however there must be at least one successful build already done for the build definition associated with the release template.

The following diagram helps visually in understanding a release template structure with reference to the other key components in RM.

Use this blog as a reference while skilling up on RM-VSO or designing a solution based on it.

(also published on my personal blog mycloudview.net)

References

1. Manage your release (Microsoft Official)
2. Release your app to vNext Environments (Microsoft Official)
3. Continuous Delivery with VSO: Configuring Release Management (This one is really good)
4. Create a Release Management pipeline for Professional Developers (and this one is probably the best)
5. Start with Visual Studio Release Management vNext–VS RM for Dummies