VSTS - Azure, Comments & Redeploy

Here we go with my 3 favourite new VSTS features for July.

Release management - Azure deployments

Now, setting up an Azure Service endpoint is easy: you just need to select the subscription on which to create a service endpoint, and you are ready to deploy to Azure.

• Users can now automatically set up an ARM service connection by selecting the subscriptions linked with the Azure Active Directory that is backing the VSTS account.
• Note: A new Azure Service Principal will be created and assigned the Contributor role, having access to all the resources in the selected subscription. You can modify the Service Principal access from Azure portal > Subscriptions > Users > Roles.
• Prerequisites: -The VSTS account should be backed by an Azure Active Directory. For more info, see the Visual Studio article Team Services: Access with Azure Active Directory (Azure AD).
• Note: Only Azure subscriptions that are linked with the Active Directory are listed.

Comment tracking for pull requests

Pull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10. With the latest improvements, the comments follow the code to show what the user expects—if a comment was added on line 10, and two new lines were subsequently added to the beginning of the file, the comment will be shown on line 12.

Here's an example change with a comment on line 13.

Even after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place (line 14).

I think this improvement is a big step forward for improving the code commenting experience in pull requests. In the near future we will have even more improvements coming, including improved comment placement for renamed or moved files.

Release – redeploy after success

When a deployment to an environment fails, you may want to be able to redeploy an older release that already succeeded once in that environment. This feature lets you do just that. 

When you try to redeploy an older release, you will be shown the list of commits as well as the list of work items that will be rolled back. You just need to make sure that the automation scripts for deployment can really handle the rollback scenario. That is still on you.