Sunday, 23 November 2014
First step is to allow triggering a release in the Release Template. This can be done in release template properties.
Select “Can Trigger a Release from a Build?” option.
Next step is to change the TFS build template to Special Template capable of triggering a release. If there is customized build template being used currently, it is possible to change it to support triggering a release. How to do that explained in below link.
If default build template is used as shown above, change it to template available with Release Management Client. This can be found at below shown location of a Release management Client installed machine.
Add ReleaseTfvcTemplate.12 to build process templates and select it as the build template in the build definition. If TFS 2012 ReleaseDefaultTemplate.11.1 should be used. If Git is used as source control repository ReleaseGitTemplate is available.
This template has a category for Release.
Set Release Build to true.
To demonstrate the release with TFS build, below simple ASP.Net web application is altered with a simple change and tested in Development environment.
The depsvr which is configured to deployed using VS Release Management still has old version and development (localhost) shows the change,
Check in the change.
CI build (Build each check in) is successful.
Next step is to trigger a build with output and initiate a release via that build.
Wait for release to be triggered with the TFS build.
New release is not triggered and Build failed with “Build service account needs to be a system user in Release Management Server”.
Add the TFS Build Service account as a service account in Release Management.
Second attempt failed with same error.
The Q&A in below link gives a hint.
Hint is the build server needs to be installed with Release Management Client and configured to access Release Management Server.
Next attempt of the build successfully triggers the release in Release Management Server.
Acceptance Deployment step should be set to automated in release path of Release triggered by a TFS Build.
Build succeeds and Release succeeds.
DepSvr is updated with the change in the Demo web application.
Sunday, 16 November 2014
We can add a Server, or Tag to the deployment sequence. Using a Tag is better since it will allow copy and pasting the template to different stages of the pipeline and even if the servers (will be different servers always in real life) are different in each stage, the tag locates the server related to the correct environment.
The first action we are going to add to the deployment sequence of the web server is create the app pool action. More details of default available release actions can be found in MSDN - Release actions to deploy an app for Release Management.
Let’s set parameters to create the application pool, .Net framework and the app pool name.
Next action we are adding is create website.
Let’s set App Pool, Site Name, Port etc. for website.
We need to create a deployment component to copy the TFS build output to our web site folder (Build definition for the template was defined in Part1)
Click New to create new component.
Give a name to the component and select Builds with application. There are different options you can select as you can see below.
Release Management server will locate the build drop of the referred TFS build in template. we have to specify our website content location. If it is in the root of the build drop we can specify \ character.
In the Deployment tab of the component select XCopy Deployer and click Save & Close.
Select the new component created and click Link.
Now the component is available in our release template.
Add the component to the deployment sequence and set the installation path parameter to the Web Site physical file folder.
Now we can copy the WebSvr sequence to the next stage (QA).
Change the parameters of actions for the QA stage.
We can do same for the Prod.
Save and Close the release template.
Next go to Release tab of the Release Management Client and click New.
Select the Target Stage as Prod so that our release will deploy through the pipeline from DevInt—>QA—>Prod.
Click on Latest to select the latest successful build.
Click on Create in Draft.
We can compare and verify configuration variables before we start the release.
Start the release and since all stages set up to deploy automatically, release will deploy from DevInt—>QA—>Prod.
We can see the three application pools getting created (in same server since we use a single server for all the stages in this demo).
Three websites created as well.
XCopy Deployer component has copied web site files to the Web Site physical folders.
The web sites are up and running.
With this Visual Studio Release Management series of posts I have explained how to setup Release Management Server, Client etc., configure and do a simple deployment. VS Release Management has lot more features and could be used to do lot more complex deployments. It has advanced security management options to setup groups, control permissions for each stage, template etc.
SQL Server Integration Services (SSIS) projects can be created to perform ETL (Extract Transform and Load) operations. As Implementing of Co...
Task groups are really useful to share common actions with multiple build or release pipelines in Azure DevOps (VSTS). You can group multip...
Generally windows services are deployed by creating an msi installer. It is possible to deploy msi via VSTS/TFS release management using the...
GItHub has a easy way to get raw contents of a file by clicking on Raw button for any code file in GitHub, where it will redirect to url sta...
Azure DevOps pipelines support default conditions allowing you to execute a step “Only when all previous tasks have succeeded”, “Even if a p...