Using Microsoft TFS with Microsoft Release Management you can successfully automate from code check-in to deployed and ready to test.

You might already have some of this happening; at least you’ve got the first part.

Microsoft Release Management bridges that chasm.

Release Management install instructions are here; https://msdn.microsoft.com/en-us/library/dn593704.aspx

With Release Management Server and Client installed and Release Management Agent installed on a test lab you are ready to go. Let’s look at an example.
I’m going to have two cheap and cheerful components; Bye and Hello. Eventually it will be useful to see what happens with more than one component; I’ll start this specific blog with just one though. Both these components produce an executable which is then packaged using WIX into an MSI. The objective is to make a change to any component and have the result installed automatically onto a test lab VM. Here are the two components in TFS source control. It makes good sense to keep components under a single folder; $/Team1/Src in this particular case. This folder could end up containing 100’s of components. While on the subject of folders there is a path name length limit of 256 characters; so keep folder and file names short.

For each component there will be a build definition. Note that they will all use the same build template though. The build definition I created for Bye is ByeX.  I’ve highlighted the settings used in ByeX. The template is ReleaseTfvcTemplate.12.xaml. The “Source Settings” are scoped to the source code; a change made to the code for Bye will trigger a build and then a deploy via Release Management.

Build Definition ByeX looks as follows:

Release Management setup to deploy the result of ByeX looks as follows:

If all goes to plan the result of the code change will end up installed on VolcanicLab-1.

And of course this is logged in Release Management.

So we have crossed the chasm with check-in through to a lab box automatically updated using Release Management.

Tweet.