TFS Archives - Page 3 of 7

Get Started using Build-Deploy-Test Workflow with TFS 2012

TFS 2012 introduces a new type of Lab environment called Standard Environment. This allows you to setup a full Build Deploy Test (BDT) workflow that will build your application, deploy it to your target machine(s) and then run a set of tests on that server to verify the deployment. In TFS 2010, you had to use System Center Virtual Machine Manager and involve half of your IT department to get going. Now all you need is a server (virtual or physical) where you want to deploy and test your application. You don’t even have to install a test agent on the machine, TFS 2012 will do this for you!

Although each step is rather simple, the entire process of setting it up consists of a bunch of steps. So I thought that it could be useful to run through a typical setup.I will also link to some good guidance from MSDN on each topic.

High Level Steps

Install and configure Visual Studio 2012 Test Controller on Target Server
Create Standard Environment
Create Test Plan with Test Case
Run Test Case
Create Coded UI Test from Test Case
Associate Coded UI Test with Test Case
Create Build Definition using LabDefaultTemplate

1. Install and Configure Visual Studio 2012 Test Controller on Target Server

First of all, note that you do not have to have the Test Controller running on the target server. It can be running on another server, as long as the Test Agent can communicate with the test controller and the test controller can communicate with the TFS server. If you have several machines in your environment (web server, database server etc..), the test controller can be installed either on one of those machines or on a dedicated machine.

To install the test controller, simply mount the Visual Studio Agents media on the server and browse to the vstf_controller.exe file located in the TestController folder.
Run through the installation, you might need to reboot the server since it installs .NET 4.5.

When the test controller is installed, the Test Controller configuration tool will launch automatically (if it doesn’t, you can start it from the Start menu). Here you will supply the credentials of the account running the test controller service. Note that this account will be given the necessary permissions in TFS during the configuration. Make sure that you have entered a valid account by pressing the Test link.

Also, you have to register the test controller with the TFS collection where your test plan is located (and usually the code base of course)

When you press Apply Settings, all the configuration will be done. You might get some warnings at the end, that might or might not cause a problem later. Be sure to read them carefully.

For more information about configuring your test controllers, see Setting Up Test Controllers and Test Agents to Manage Tests with Visual Studio

2. Create Standard Environment

Now you need to create a Lab environment in Microsoft Test Manager. Since we are using an existing physical or virtual machine we will create a Standard Environment.

Open MTM and go to Lab Center.
Click New to create a new environment
Enter a name for the environment. Since this environment will only contain one machine, we will use the machine name for the environment (TargetServer in this case)
On the next page, click Add to add a machine to the environment. Enter the name of the machine (TargetServer.Domain.Com), and give it the Web Server role. The name must be reachable both from your machine during configuration and from the TFS app tier server.
You also need to supply an account that is a local administration on the target server. This is needed in order to automatically install a test agent later on the machine.
On the next page, you can add tags to the machine. This is not needed in this scenario so go to the next page.
Here you will specify which test controller to use and that you want to run UI tests on this environment. This will in result in a Test Agent being automatically installed and configured on the target server.

The name of the machine where you installed the test controller should be available on the drop down list (TargetServer in this sample). If you can’t see it, you might have selected a different TFS project collection.
Press Next twice and then Verify to verify all the settings:
Press finish. This will now create and prepare the environment, which means that it will remote install a test agent on the machine. As part of this installation, the remote server will be restarted.

3-5. Create Test Plan, Run Test Case, Create Coded UI Test

I will not cover step 3-5 here, there are plenty of information on how you create test plans and test cases and automate them using Coded UI Tests.

In this example I have a test plan called My Application and it contains among other things a test suite called Automated Tests where I plan to put test cases that should be automated and executed as part of the BDT workflow.

For more information about Coded UI Tests, see Verifying Code by Using Coded User Interface Tests

6. Associate Coded UI Test with Test Case

OK, so now we want to automate our Coded UI Test and have it run as part of the BDT workflow. You might think that you coded UI test already is automated, but the meaning of the term here is that you link your coded UI Test to an existing Test Case, thereby making the Test Case automated. And the test case should be part of the test suite that we will run during the BDT.

Open the solution that contains the coded UI test method.
Open the Test Case work item that you want to automate.
Go to the Associated Automation tab and click on the “…” button.
Select the coded UI test that you corresponds to the test case:
Press OK and the save the test case

For more information about associating an automated test case with a test case, see How to: Associate an Automated Test with a Test Case

7. Create Build Definition using LabDefaultTemplate

Now we are ready to create a build definition that will implement the full BDT workflow. For this purpose we will use the LabDefaultTemplate.11.xaml that comes out of the box in TFS 2012. This build process template lets you take the output of another build and deploy it to each target machine. Since the deployment process will be running on the target server, you will have less problem with permissions and firewalls than if you were to remote deploy your solution.

So, before creating a BDT workflow build definition, make sure that you have an existing build definition that produces a release build of your application.

Go to the Builds hub in Team Explorer and select New Build Definition
Give the build definition a meaningful name, here I called it MyApplication.Deploy
Set the trigger to Manual
Define a workspace for the build definition. Note that a BDT build doesn’t really need a workspace, since all it does is to launch another build definition and deploy the output of that build.
But TFS doesn’t allow you to save a build definition without adding at least one mapping.
On Build Defaults, select the build controller. Since this build actually won’t produce any output, you can select the “This build does not copy output files to a drop folder” option.
On the process tab, select the LabDefaultTemplate.11.xaml. This is usually located at $/TeamProject/BuildProcessTemplates/LabDefaultTemplate.11.xaml. To configure it, press the … button on the Lab Process Settings property
First, select the environment that you created before:
Select which build that you want to deploy and test. The “Select an existing build” option is very useful when developing the BDT workflow, because you do not have to run through the target build every time, instead it will basically just run through the deployment and test steps which speeds up the process.
Here I have selected to queue a new build of the MyApplication.Test build definition
On the deploy tab, you need to specify how the application should be installed on the target server. You can supply a list of deployment scripts with arguments that will be executed on the target server. In this example I execute the generated web deploy command file to deploy the solution. If you for example have databases you can use sqlpackage.exe to deploy the database. If you are producing MSI installers in your build, you can run them using msiexec.exe and so on.
A good practice is to create a batch file that contain the entire deployment that you can run both locally and on the target server. Then you would just execute the deployment batch file here in one single step.

The workflow defines some variables that are useful when running the deployments. These variables are:

$(BuildLocation)
The full path to where your build files are located

$(InternalComputerName_<VM Name>)
The computer name for a virtual machine in a SCVMM environment

$(ComputerName_<VM Name>)
The fully qualified domain name of the virtual machine

As you can see, I specify the path to the myapplication.deploy.cmd file using the $(BuildLocation) variable, which is the drop folder of the MyApplication.Test build.
Note: The test agent account must have read permission in this drop location.

You can find more information here on Building your Deployment Scripts
On the last tab, we specify which tests to run after deployment. Here I select the test plan and the Automated Tests test suite that we saw before:

Note that I also selected the automated test settings (called TargetServer in this case) that I have defined for my test plan. In here I define what data that should be collected as part of the test run.

For more information about test settings, see Specifying Test Settings for Microsoft Test Manager Tests

We are done! Queue your BDT build and wait for it to finish. If the build succeeds, your build summary should look something like this:

New functionality in TFS Build Manager – Managing Triggers and Build Resources

Yesterday we pushed out a new release (August 2012) of the Community TFS Build Extension, including a new version of the Community TFS Build Manager (1.0.4.6)

The two big new features in the Build Manager in this release are:

Set Triggers
It is now possible to select one or more build definitions and update the triggers for them in one simple operation:

You’ll note that we have started collapsing the context menu a bit, the list of commands are getting long! Ler

When selecting the Trigger command, you’ll see a dialog where the options should be self-explanatory:

The only thing missing here is the Scheduled trigger option, you’ll have to do that using Team Explorer for now.

Manage Build Resources
The other feature is that it is now possible to view the build controllers and agents in your current collection and also perform some actions against them. The new functionality is available by select the Build Resources item in the drop down menu:

Selecting this, you’ll see a (sort of) hierarchical view of the build controllers and their agents:

In this view you can quickly see all the resources and their status. You can also view the build directory of each build agent and the tags that are associated with them.
On the action menu, you can enable and disable both agents and controllers (several at a time), and you can also select to remove them.
By selecting Manage, you’ll be presented with the standard Manage Controller dialog from Visual Studio where you can set the rest of the properties. Hopefully we’ll be able to implement most of the existing functionality so that we can remove that menu option Ler
Our plan is to add more functionality to this view, such as adding new agents/controllers, restarting build service hosts, maybe view diagnostic information such as disk space and error logs.

Hope you’ll find the new functionality useful. Remember to log any bugs and feature requests on the CodePlex site.

Happy building!

New VS2012 Book: Pro Application Lifecycle Management with Visual Studio 2012

During the spring/summer I have been involved with reviewing a new book about Visual Studio 2012 ALM from Apress called “Pro Application Lifecycle Management with Visual Studio 2012”

The book is written by a fellow Visual Studio ALM MVP Mathias Olausson and his colleague Joachim Rossberg. It is a very comprehensive book that covers both all aspects of ALM in general and also how to implement these practices with Visual Studio 2012. The book also has several chapters dedicated to measuring your improvements by using ALM assessments and metrics.

You can pre-order the book here at Amazon:
http://www.amazon.com/Application-Lifecycle-Management-Visual-Professional/dp/1430243449/

Check it out! Ler

ALM Rangers Readiness GIG has shipped!

Together with todays announcement that Visual Studio 2012 as been officially released, the ALM Rangers have also simultaneously shipped (“sim-shipped”) a massive set of solutions for feature gaps and value-add guidance for the ALM community.

http://blogs.msdn.com/b/visualstudioalm/archive/2012/08/15/welcome-to-visual-studio-2012-alm-rangers-readiness-wave.aspx

You can find a complete list of ALM Ranger solutions here:
http://msdn.microsoft.com/en-us/vstudio/ee358787

I have been a part of the Team Foundation Build Customization Guide, which have been updated with new features in Visual Studio 2012, as well as the top requested features from the first version of the guidance. As part of this guidance, we have also developed the Community TFS Build Manager, a Visual Studio extension that simplifies a lot of tasks when working with TFS Build. It now exist both for Visual Studio 2012 as well as for Visual Studio 2010. I’d like to thank the rest of the team for doing such a great job, especially Mike Fourie who has been driving the entire project in style!

I am proud to be a part of the ALM Rangers group, everybody involved put in a considerable amount of their (already limited) spare time to produce top quality guidance and tools for the community.

TFS Build: Dependency Replication using Community TFS Build Extensions

I have posted before on how to implement dependency replication using TFS Build, once for TFS 2008 using MSBuild and then for TFS 2010 using Windows Workflow. The last post was not complete (I could not post all implementation details back then for various reasons), so I decided that I should post a new solution for this, but this time using the Community TFS Build Extensions library.

If it is a good idea to store your dependencies in source control or not is a question that is well debated. I’m not going to argue pros and cons here, but for those of you that want to go this way here is a build process template that will get you started.

An interesting fact is that Microsoft actually have added this feature as part of the hosted TFS (TFS Services) running on Windows Azure, but decided post-Beta that this feature was not to be included in the on-premise version of TFS. The feature might reappear in the on-premise version at some point in the future but nothing is confirmed yet. For hosted TFS, this feature is a must since users would not be able to access the network shares that TFS Build normally use as drop location.

Features of the DependencyReplication.xaml build process template

I have added a new Build Process template called DependencyReplication.xaml to the TFS Build Extensions that performs the following steps, in addition to the common default template:

Accepts a source control folder input parameter where the binaries should be stored (DeployFolder)
Versions all assemblies, using the TfsVersion activity
Copies to binaries to the the deploy folder
Check in the binaries. The check-in comment includes the version number (using the TfsSource activity)
If any errors occurs as part of the replication, it will undo any pending changes as part of the build

I have uploaded the build process template to the CodePlex site, so it is available at $/teambuild2010contrib/CustomActivities/MAIN/Source/BuildProcessTemplates/DependencyReplication.xaml.

Note: The build process template uses the latest version of the activities, so make sure that you download the latest source and compile it. I had to make some additions to the library to support the functionality of the build process template. The changes will be included in the next official release, but until then you must download the latest bits and build it yourself.

How to use the Build Process Template

Add the DependencyReplication.xaml file to source control. You can add it wherever you like. This sample assumes that you add it to $/Demo/BuildProcessTemplates/
Make sure that you have added the necessary TFSBuildExtension assemblies to the Version Control path for Custom assemblies. See this link for how to do this.
Since this template only uses a few of the build activities, you only need to add the following assemblies:
- TfsBuildExtensions.Activites.dll
- TfsBuildExtensions.TfsUtilities.dll
- Ionic.Zip.dll
Create a new build definition.
In the process tab, click the Show Details button
Click New and then the Select an existing XAML file radio button and browse to the DependencyReplication.xaml file that you just added:
Note that you will now have an additional, required, process parameter called DeployFolder, located in the Misc category.
Enter the source control folder path where you want the binaries to be stored.
Note: This path must exist in source control, and must also be a part of the workspace for the current build definition otherwise the build will fail. This is a limitation of the current implementation. It can be implemented by modifying the workspace at build time, as I did in my first post on dependency replication.
You must also change the Build Number Format parameter to be $(BuildDefinitionName)_1.0.0$(Rev:.r)
Note: This build process template uses the built-in functionality for incrementing the build number, so the version number will be a part of the build number itself which gives you a nice traceability between the build and the generated assemblies. It then parses the version number from the Build number, so you need to have the four-part version number as part of the build number format. If you have some other way of managing version numbers, you will need to change the build process template correspondingly.

The 1.0.0 part above can obviously have any value, it will represent your Major.Minor.Revision part of the generated version number.
Save the build definition and queue a build

After the build has finished, you should see that the binaries have been added to source control in the given path.

Note that all files in the binaries folder will be added to source control. If this is not what you want, you need to modify the build process template. An option here would be to add the filter expression (*.*) as a process parameter to make it configurable per build definition.

If you download the binaries you should see that they have the same version number that was included in the build number for that particular build.
If you view history of the folder, you will see that the build service account (in my case the Network service) have checked in the files with a comment containing the version number:

If you have check-in policies enabled for the team project, they will be overridden as part of the check-in with a comment.

I hope that you will find this build process template useful. It is by no means a full solution, it lacks some error checking and also it should handle the case where the DeployFolder path is outside the workspace for the build definition. Let me know if you really need this feature and I will consider adding it to the template Ler . Of course, you can add it yourself and post it back to the community.

Community TFS Build Manager available for Visual Studio 2012 RC

I finally got around to push out a version of the Community TFS Build Manager that is compatible with Visual Studio 2012 RC. Unfortunately I had to do this as a separate extension,
it references different versions of the TFS assemblies and also some properties and methods that the 2010 version uses are now obsolete in the TFS 2012 API.

To download it, just open the Extension Manager, select Online and search for TFS Build:

You can also download it from this link:
http://visualstudiogallery.msdn.microsoft.com/cfdb84b4-285e-4eeb-9fa9-dad9bfe2cd10

The functionality is identical to the 2010 version, the only difference is that you can’t start it from the Team Explorer Builds node (since the TE has been completely rewritten and the
extension API’s are not yet published). So, to start it you must use the Tools menu:

We will continue shipping updates to both versions in the future, as long as it functionality that is compatible with both TFS 2010 and TFS 2012.

You might also note that the color scheme used for the build manager doesn’t look as good with the VS2012 theme….

Hope you will enjoy the tool in Visual Studio 2012 as well. I want to thank all the people who have downloaded and used the 2010 version!
For feedback, feature requests, bug reports please post this to the CodePlex site: http://tfsbuildextensions.codeplex.com

Deploying SSDT Projects with TFS Build

As many of you probably have noticed by now, Visual Studio Database Projects are not supported in the next version of Visual Studio (currently named
Visual Studio 11 Beta). When you open a solution containing a VSDB project, VS11 wants to convert it to a SQL Server Developer Tools project instead.

This project type ships with SQL Server and has a feature set that covers most of the functionality of the VSDB project, plus some new features, such
a support for SQL 2012 and SQL Azure. A feature comparison list between the two project types can be found here:
http://blogs.msdn.com/b/ssdt/archive/2011/11/21/sql-server-data-tools-ctp4-vs-vs2010-database-projects.aspx

Once you have converted your project to a SSDT project, you will find that most of the functionality is very similar to VSDB, how you work with
schema objects, schema comparisons etc. Deploying a SSDT project is called Publish and is available in the Visual Studio context menu:

When you invoke the Publish command, Visual Studio will launch the Publish Profile dialog, where you can configure how and where you want to
deploy the database:

There are lots of options that you can configure, and these options are often different depending on the target environment. For example, locally you
typically want to recreate the database every time you deploy, but when deploying to a test server, you probably only want to update it incrementally
without removing any existing data. The settings that you enter can be stored in a separate profile file, which you will use when you are deploying the database.

So, create a publish profile for each environment that you want to deploy to. In the following example, I have one profile for deploying to my local
machine, and in addition publish profiles for the test and production environments:

(Note that you can right-click a publish profile and mark it as default. This is the profile that will be chosen when you select Publish in Visual Studio, so
in this case I would select Local.publish.xml)

The Publish command calls the Publish MSBuild target which will eventually call the SqlPublishTask MSBuild task which will do the work of deploying your
database. This means that the deployment of the database project is easy to integrate into TFS Build, since you can just specify that you want to invoke
the Publish target as part of your build:

Here, I have chosen to deploy the database using the Test profile, which would typically by a remote server used for testing of the build.

Using SQLCMD variables
Sometimes you need to use parameters in your scripts, e.g. values that you can pass in dynamically when the script is executed. These are called
SQLCMD variables, and you can define these on the properties page of the database project:

Here I have defined a variable called $(TargetServer), and given it a default value of localhost. Then I have references this variable inside a post
deployment script in side the project, like this:

EXEC master..xp_cmdshell 'bcp Daatabase.[dbo].[Table] in "TableContent.dat" -T -c -S$(TargetServer)'

This is a scenario we had at a client recently, where they used the BCP utility to bulk insert lots of data into a few tables as part of the deployment.

To be able to run BCP against different target servers (dev, test etc) in my build, I used the SQLCMD variable.

When you publish your database from Visual Studio, it will prompt you to give the variables a value. But when deploying from a build, the value need

to be set per configuration. This is done by opening the publish profile file for the target environment and store that value there:

Select “Save Profile As” and save it as your target publish profile. Since we are specifying our publish profile in our build definition, it will populate

the variables with the correct values.

Awarded Visual Studio ALM MVP for 2012!

Today I received an email from Microsoft stating that:

Dear Jakob Ehn,
Congratulations! We are pleased to present you with the 2012 Microsoft® MVP Award!
This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others.
We appreciate your outstanding contributions in Visual Studio ALM technical communities during the past year.

This is incredibles news and I really want to thank both the people at Microsoft who nominated me and some of the (now) fellow MVP’s that I have worked with over the last year, both as part of the Visual Studio ALM Rangers program and as part of the TFS Build Extensions community project, in particular Mike Fourie and of course my colleague and main source of inspiration Terje Sandström Smile

I’m really looking forward to this year, it’s going to be a blast! Smile

Adding Fake Build Information in TFS 2010

We have been using TFS 2010 build for distributing a build in parallel on several agents, but where the actual compilation is done by a bunch of external tools and compilers, e.g. no MSBuild involved. We are using the ParallelTemplate.xaml template that Jim Lamb blogged about previously, which distributes each configuration to a different agent. We developed custom activities for running these external compilers and collecting the information and errors by reading standard out/error and pushing it back to the build log.

But since we aren’t using MSBuild we don’t the get nice configuration summary section on the build summary page that we are used to. We would like to show the result of each configuration with any errors/warnings as usual, together with a link to the log file.

TFS 2010 API to the rescue! What we need to do is adding information to the InformationNode structure that is associated with every TFS build. The log that you normally see in the Log view is built up as a tree structure of IBuildInformationNode objects. This structure can we accessed by using the InformationNodeConverters class. This class also contain some helper methods for creating BuildProjectNode, which contain the information about each project that was build, for example which configuration, number of errors and warnings and link to the log file.

Here is a code snippet that first creates a “fake” build from scratch and the add two BuildProjectNodes, one for Debug|x86 and one for Release|x86 with some release information:

TfsTeamProjectCollection collection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("http://lt-jakob2010:8080/tfs"));
IBuildServer buildServer = collection.GetService<IBuildServer>();

var buildDef = buildServer.GetBuildDefinition("TeamProject", "BuildDefinition");

//Create fake build with random build number
var detail = buildDef.CreateManualBuild(new Random().Next().ToString());

// Create Debug|x86 project summary
IBuildProjectNode buildProjectNode = detail.Information.AddBuildProjectNode(DateTime.Now, "Debug", "MySolution.sln", "x86", "$/project/MySolution.sln", DateTime.Now, "Default");
buildProjectNode.CompilationErrors = 1;
buildProjectNode.CompilationWarnings = 1;

buildProjectNode.Node.Children.AddBuildError("Compilation", "File1.cs", 12, 5, "", "Syntax error", DateTime.Now);
buildProjectNode.Node.Children.AddBuildWarning("File2.cs", 3, 1, "", "Some warning", DateTime.Now, "Compilation");

buildProjectNode.Node.Children.AddExternalLink("Log File", new Uri(@"\serversharelogfiledebug.txt"));
buildProjectNode.Save();

// Create Releaes|x86 project summary
buildProjectNode = detail.Information.AddBuildProjectNode(DateTime.Now, "Release", "MySolution.sln", "x86", "$/project/MySolution.sln", DateTime.Now, "Default");
buildProjectNode.CompilationErrors = 0;
buildProjectNode.CompilationWarnings = 0;

buildProjectNode.Node.Children.AddExternalLink("Log File", new Uri(@"\serversharelogfilerelease.txt"));
buildProjectNode.Save();

detail.Information.Save();
detail.FinalizeStatus(BuildStatus.Failed);

When running this code, it will a create a build that looks like this:

As you can see, it created two configurations with error and warning information and a link to a log file. Just like a regular MSBuild would have done.

This is very useful when using TFS 2010 Build in heterogeneous environments. It would also be possible to do this when running compilations completely outside TFS build, but then push the results of the into TFS for easy access. You can push all information, including the compilation summary, drop location, test results etc using the API.

Managing Build Templates with Community TFS Build Manager

A year ago I blogged about how to manage your build process templates using the TFS API. The main reason for doing this is that you can (and should!) store your “golden” build process templates in a common location in your TFS project collection, and then add them to each team project that requires those templates. This way, you can fix a bug or add a new feature in one place and have the change affect all build definitions.

However, by having the build process templates in a single location, the users must know where the build process templates are located and browse to that path and add it to the team project, before it will show up in the list of build process templates:

Unfortunately, you can’t manage the build process templates this way using Team Explorer, you have to resort to the TFS API to do these things.

Until now! Ler In the latest release of the Community TFS Build Manager I have added support for managing build process templates.

The templates are accessible by selecting “Build Process Templates” in the “Show” dropdown:

This will show all registered build process templates, either in the selected team project or in all team projects, depending on your current filter:

All build process templates in the XDemo team project. The grid is of course sortable as the rest of the application. This lets you easily see where the template is registered.

Note that several of the build process templates in the list above is stored in the Inmeta team project, which is our team project for storing all artifacts related to our software factory, including the build process templates and custom activities.

Now, we can right click on a build process template and perform any of the following actions:

Set As Default
This will set the selected build process template as the default build process template in the corresponding team project. There can only be one default build process template per team project, so the tool will automatically scan for any other default build process templates and set them back to “Custom”.
Add to Team Project(s)
This will let you select one or more team projects where you want to add this build process template to:

In the list you can select one or more team projects. You can also specify that the template(s) should be set as default by using the checkbox “Set as Default”.
Remove from Team Project(s)
This does the opposite from the previous operation, it removes the selected build process template(s) from one or more team project. After this operation, the template will not be visible in the “Build Process file” dropdown when editing a build process template.
Note: When removing a build process template, there might be build definitions using this template. If this is the case, the build manager will prompt you with a dialog before you proceed with the remove:

Hope that you find the new functionality useful. Please report bugs and feature requests to the Community TFS Build Extensions CodePlex site