I’m excited to announce Release Management for Visual Studio 2013 Update 4. This update includes several new features and performance updates that will make it easier than ever to deploy your app from development through to production. This update is the latest in a cumulative series of feature additions and bug fixes for Release Management.
Here are the 10 things you need to know about Release Management Update 4:
1. Use the Release Management service in Visual Studio Online
Yes, you got that right, Release Management Update 4 client can connect to either on-premises Release Management server or to Release Management Service in Visual Studio Online. Now you can setup a release pipeline from check-in through to deployment without having to install and maintain an on-premises Release Management server. Release Management for Visual Studio Online service is in preview!
From your Release Management client, connect to your Visual Studio Online account
2. Release to Azure from Visual Studio
Do you need to get started quickly with Release Management service in Visual Studio Online? Just download the Release Management Extension from Visual Studio gallery. You can create release artefacts directly from within the Visual Studio IDE using Release Management as a service with a Visual Studio Online account. You must use an Azure subscription to deploy to your Azure VMs with this release definition.
Step 1: Download the Release Management Tool for Visual Studio 2013 from Visual Studio gallery
Step 2: Create release artefacts in Visual Studio Online using Build Definition menu
3. Use tags when you deploy to an environment
Now you can use tags with the servers in your Azure or on-premises (standard) environments. For example, if you have multiple web servers in your environment then you can tag them all with ‘Web’ and set up your deployment actions using tags. When a stage is deployed, these actions are performed on all the servers matching the tag. You only have to create the set of actions once for multiple servers, RM will expand the actions for all the servers. You can verify this by starting a release in create-in-draft mode.
With tags you can also switch the deployment order from parallel to sequence.
In the above example, both actions FabrikamFiber Web and FabrikamFiber DB would be processed on servers tagged Web i.e., ProdAppTier, ProdAppTier2.
4. Access system variables from deployment script
By popular demand (User Voice), you can now access system variables just like other configuration variables and use them in your release template. You don’t have to hard-code these any more.
· Build directory
· Build number (for component in the release)
· Build definition (for component)
· TFS URL (for component)
· Team project (for component)
· Tag (for server which is running the action)
· Application path (destination path where component is copied)
· Environment (for stage)
· Release id
· Release name
When using system variables in scripts, prefix a $ to the variable name, for example $Stage
5. Reduce the need for configuration files to deploy your builds
If you deploy without using agents, you can now set up configuration variables for your release. Configuration variables provide reusable and customizable settings that are available during action execution. You can set configuration variables and default values on servers, components and globally, and then use those values in your PowerShell scripts and configuration scripts.
For example, setting the user name and password used for deploying your app on the server is shown above. When using configuration in scripts, prefix a $ to the variable name, for example $SMTPHost.
6. Manual intervention for a release
Now you can add manual steps to a stage in any release path, even if you deploy without agents. Add a manual intervention activity into your deployment sequence. When the manual intervention activity is triggered in that sequence, the deployment pauses and you can run some manual steps before continuing with the rest of the automation for the release path.
For example, task manual validation of DB deployment has been assigned to DB owner for sign-off. When the process executes email notification would be sent to manual intervention task recipient and the sequence is paused till sign-off.
7. Build drops stored on TFS servers
If you have set up your build definition to copy the build output to the server and not a UNC path, you can now use these builds to deploy your app.
Steps to enable this feature:
· During configuration of RM server, a folder %SYSTEMDRIVE%\ReleaseManagementShare is created on the release management server to stage server dropped builds. This folder needs to be shared to enable access to the staged builds. For e.g. \\rmserver\releasemanagementshare
· The identity used to deploy the build on the target needs read permission on the share.
8. Deploy from a build drop using a shared UNC path
In case the target server doesn’t have direct access to TFS build drop location, you can now use Release Management to deploy to servers using build drops located on a shared UNC path. You can deploy only if both the target server and the Release Management server have access to the shared UNC path.
Steps to enable this feature –
· Mark that the ‘Servers’ can access the builds using a common ‘Shared UNC Path’ option under deployment tab. Refer to screenshot below
· Set the shared UNC path location using RMSharedUNCPath as a global configuration variable.
· Define credentials having permission on the shared UNC path using global configuration variables RMSharedUNCPathUser, RMSharedUNCPathPwd
RM Server will implicitly copy the build to the Path specified in the global config var. RMSharedUNCPath.
9. Usability improvements
You can now select servers and components from the drop-down list in the action for all types of release templates. You can also give actions friendly names to make it easier to identify them.
10. Mix and match Azure and standard environments