Automated Build and Deployment Solution with TFS

In this article you’ll find out how to implement build automation with Team Foundation Service. All the examples, referred below, use Team Foundation Service on-premise (in your organization). Some of the settings may be overridden by your TFS Administrator if you are using TFS on-premise. We can speed up the deployment life cycle by utilizing the automated builds. If we are running in an agile process and wanted to leverage continuous integration to see new features as soon as possible, then we can achieve this by automating builds with TFS build definitions.

It is considered that you already setup the build machine and installed the Visual Studio Team Foundation Server 2012. Create new controller and agents in the Team foundation server settings panel in the build machine.

Step 1 :- Go-to the Team Explorer -> Builds tab and click “New Build Definition”.

If you do not have sufficient privileges to create build definition, you will get an error message (as below).  You can request your TFS Admin to grant you build rights (ManageBuildResources).

Step 2:- on clicking the link, you will come up with a screen like this

On the General tab, choose a build definition name.  As a best practice, the build definition name should depict nature of build (nightly, gated), environment and application name

On Trigger tab, you will have following options

• Manual – As the name suggests, you can trigger manual builds on the build server
• Continuous Integration – Trigger a build when code is check-in
• Rolling Builds – Trigger a build at every X minutes
• Gated check-in – Trigger a build before check-in.  This ensures that only error-free code gets checked-in
• Schedule – Schedule a build at a particular time of a day

On Source Settings tab, you can choose the working folders.  It is advisable to choose the closest branch in which the code resides as a working folder.

On Build Defaults tab, you can define your build controller and staging locations

• When using Team Foundation as Service (cloud-based TFS), the build controller will have only one value in the drop down ‘Hosted Build Controller’. When using Team Foundation Server (on-premises), you will have to configure a build controller for yourself. We will deal with building your own build controller in a separate article.
• For staging locations, you can have the build output checked in to TFS directly or to a shared drive, or ignore the build output.

If you are staging it to a shared drive you need to make sure that the Service Account / Active Directory Account through which the build service is running on the build server has Full Control on the shared location.

On Process tab, you can define your own build process. We will deal with the customization of process template in a different article.  When using Team Foundation as Service (cloud-based TFS), you will have following templates

• Default Template
• Upgrade Template – When upgrading from older version of TFS
• Azure Continuous Deployment – Build and deploy websites and services to Azure Cloud platform.
• Tfvc Template – Team Foundation Version Control template
• Git Template – GIT version control template

Each template will give you different options to configure.  Some of the common options are

• Version Control – Clean Work-space, Get Version, Label Sources
• Build –
  • Projects – You can select solution file or individual projects that need to be built
  • Configurations – You can select a configuration and platform here.  The configuration selected here should be available under Configuration Manager of your solution otherwise the build will fail.  This can also be useful when you have configuration transforms for app.config / web.config files
  • Output Location – In TFS 2010, the build output of all the selected projects wasalways copied to a single folder.  With TFS 2012+, you can choose of the options – single folder, per project, or as configured in individual projects.

  • Advanced – This setting allows you to pass additional parameters to MSBuild, configure pre-build and post-build scripts and enable/disable code analysis.  For the uncommon complex tasks you can check-in your pre-build and post-build scripts in TFS and change the settings in Advanced section.  You can also choose to run FxCop to perform code analysis on your projects

• Test – You can configure your test projects here.  By default, MSTest will be used as engine for unit-testing.  If you want to disable unit-test runs, you can set Disable Tests to true
• Advanced – Advanced allows you to configure your build agents and post-build behavior. If you want to create a Build Bug for every failed build, or want to update Work Items with the build number, you can set it up in this setting

On Retention Policy tab, you can define how long you would want to retain build outcome. In your organization, this may be driven by some audit/compliance requirements or by best practices.

Once you have configured the build definition, you can view the build definitions in the same Team Explorer

After successful completion of the build you will be able to see this screen

Some options we need to use to configure the build definition are given below

Select the build configuration and solutions to build 

Select the build number format as like this

$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)

So we will have the build number something like this

In the Advanced tab use the MSBuild Arguments like this 

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=WMSVC /p:AllowUntrustedCertificate=True /p:MSDeployServiceUrl=<mention the ms deploy url path> /p:DeployIisAppPath="<mention the iis name>" /p:UserName=<user name with domain> /p:Password=<Password>

Note : without <>, replace the bold text with the correct values

For /p:MSDeployServiceUrl give the Msdeploy url by default it would be something like

https://example.com:8172/MsDeploy.axd

for /p:DeployIisAppPath give the iis application path something like “example.com”

for /p:UserName and /p:Password give the system credentials with domain like

exampleuser and password

We have successfully automated the deployment process.