Moving from the earlier version of Release management service to the new one in Visual Studio Team Services

Like what you see in the new Release Management service in VS Team Services?

Are you currently using the rich client to connect to the previous version of Release Management service in VS Team Services or to an on-premises Release Management 2013 or 2015 server?

Would you like to move to the new Release Management service in VS Team Services?

If your answer to these questions is Yes, then read on for guidance on how to move to the new service.

Move from previous version of Release Management Service for Visual Studio Team Services

If you are connecting to the previous version of Release Management Service using the rich client, then you would have done the following -

• Created PS/DSC scripts for deployment that are managed in version control
• Hosted an IaaS Server that executes PS/DSC scripts for deployment

You can directly move these release templates to the new Release Management Service.

Depending upon your application targets, the new release definitions would vary.

Scenario 1: You are deploying to a target using the IaaS Server as a proxy (like Azure WebApps/ Azure Cloud Services etc.

In cases where the application is hosted on a target other than the Server running the script, you would be using the IaaS Server as a proxy. The PS/DSC scripts would be handling authentication with the actual targets and performing the deployment.

You can now execute the PS/DSC script on the hosted agent and achieve the same purpose, without needing to dedicate a server as a proxy for performing deployments.
In case the target is accessible from the internet, you shall not be able to use the hosted agent and would need to configure a custom onprem agent that can access the target.

For example, the following is a mapping of the task sequence in the rich client to the deployment workflow for the environment in the new Service.

The parameters passed to the task are –    Script Filename: $(System.DefaultWorkingDirectory)\samplewebapp \drop\bin\deploy.ps1    Arguments: -webappName "samplewebapp" -storageName "samplewebappstor" -BinLocation "$(System.Default WorkingDirectory\samplewebapp\drop\bin\    PublishedWebsites" -subFile   "$(System.DefaultWorkingDirectory)\samplewebapp \drop\bin\shashankb.publighsettings" –appPoolName “sample webapppool”    –Port 8085       Note: deploy.ps1 would need to be modified slightly to take the custom configuration as commandline parameters instead of session variables.

Scenario 2: The server executing the PS/DSC scripts is the actual target hosting the application.

In cases where the application is hosted on the Server running the script, the PS/DSC script shall be performing the deployments locally. The payload binaries are also present locally on the server.

You can achieve this purpose in two ways.

1. Configure the target server as a custom agent and execute the deployment workflow (consisting of Powershell task as in Scenario 1) on the same machine.
2. Use hosted agent and use “Powershell on Target Machines” task to remotely trigger deployments to the target.

In case you are currently connecting to an on-premises Release Management Server and have configured a vNext release template, then you would have done the following –

• Added the on-premises TFS Server that hosts the build system to RM
• Created PS/DSC scripts for deployment and included them in the build output
• Setup dedicated machines for servers to execute the deployment scripts on

You can now configure the release definitions in the online version of the release management service, while maintaining complete security of the on-premises environment around Code, Build and the deployment payload.

You’ll need to add the TFS Server as an artifact source as described here.
You’ll also need to configure an agent on the on-premises servers that execute the deployment scripts as described here.

The actual release definitions would now mimic the scenarios discussed in the section “Move from previous version of Release Management Service for Visual Studio Team Services” above.

Note: In case you have defined/used a custom action (or an action other than “Deploy using PS/DSC”, then you may need to create a custom task for the same in the new service/ convert the functionality into a powershell script.

 Move from Agent-based release templates with Release Management Server

In case you are currently connecting to an on-premises Release Management Server and have configured agent-based release templates, then everything mentioned in the section “Move from vNext release templates with Release Management Server” above is applicable to you.

In addition, you would frequently run into the need for translating the fine grained actions (and the XAML based workflow) into equivalent powershell scripts. There is help available for you here to guide you through this move.

 FAQs

1.    Upgrade Client Error Connecting to Release Management Service using the rich client

Based on your activity with the previous version of the Release Management Service, certain accounts have been auto-upgraded to only be accessible from the new Service.

You may get the following error when connection the Release Management Service using the rich client.

It means that your account was selected for the auto-upgrade. You’re all set to start managing your release workflows using the Release hub on visualstudio.com