Jakob Ehn

New Book: Pro Team Foundation Service

Jakob Ehn — Mon, 20 May 2013 21:27:33 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2013/05/20/new-book-pro-team-foundation-service.aspx

The last couple of months I have been working together with Mathias Olausson, Mattias Sköld and Joachim Rossberg on a new book project for Apress that has just been published. The book is called Pro Team Foundation Service and covers all aspects of working with Team Foundation Service, Microsoft's hosted version of Team Foundation Server in the cloud. I have mainly worked on the chapter related to automated build and continuous deployment, but also with some of the other chapters.

It has been a quite hectic project due to a tight schedule, but at the same time it has been a lot of fun to work on this book together with late night meetings and weekends filled with book writing and chapter editing.

During the project we’ve had great help from several people at Microsoft, Jamie Cool, Will Smythe, Anutthara Bharadwaj, Ed Blankenship and Vijay Machiraju. Also a big thanks to Brian Harry for writing the foreword to the book. In addition I’d like to thank my colleague Terje Sandstrøm for helping out with Technical Review of large parts of the book.

Here is some information about the book, you can find it on Amazon here:
http://www.amazon.com/Team-Foundation-Service-Mathias-Olausson/dp/1430259957#_

Check it out and let us know what you think!

Pro Team Foundation Service gives you a jump-start into Microsoft’s cloud-based ALM platform, taking you through the different stages of software development. Every project needs to plan, develop, test and release software and with agile practices often at a higher pace than ever before.
Microsoft's Team Foundation Service is a cloud-based platform that gives you tools for agile planning and work tracking. It has a code repository that can be used not only from Visual Studio but from Java platforms and Mac OS X. The testing tools allow testers to start testing at the same time as developers start developing. The book also covers how to set up automated practices such as build, deploy and test workflows.

This book:

· Takes you through the major stages in a software development project.

· Gives practical development guidance for the whole team.

· Enables you to quickly get started with modern development practices.

With Microsoft Team Foundation Service comes a collaboration platform that gives you and your team the tools to better perform your tasks in a fully integrated way.

What you’ll learn

· What ALM is and what it can do for you.

· Leverage a cloud-based ALM platform for quick improvements in your development process.

· Improve your agile development process using integrated tools and practices.

· Develop automated build, deployment and testing processes.

· Integrate different development tools with one collaboration platform.

· Get started with ALM best-practices first time round.

Who this book is for

Pro Team Foundation Service is for any development team that wants to take their development practices to the next level. Microsoft Team Foundation Service is an excellent platform for managing the entire application development lifecycle and being a cloud-based offering it is very easy to get started. Pro Team Foundation Service is a great guide for anyone in a team who wants to get started with the service and wants to get expert guidance to do it right.

Table of Contents

1. Introduction to Application Lifecycle Management

2. Introduction to Agile Planning, Development, and Testing

3. Deciding on a Hosted Service

4. Getting Started

5. Working with the Initial Product Backlog

6. Managing Team and Alerts

7. Initial Sprint Planning

8. Running the Sprint

9. Kanban

10. Engaging the Customer

11. Choosing Source Control Options

12. Working with Team Foundation Version Control in Visual Studio

13. Working with Git in Visual Studio

14. Working in Heterogeneous Environments

15. Configuring Build Services

16. Working with Builds

17. Customizing Builds

18. Continuous Deployment

19. Agile Testing

20. Test Management

21. Lab Management

Extending Team Explorer 2012 – Associating Recent Work Items

Jakob Ehn — Thu, 16 May 2013 16:29:44 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2013/05/16/extending-team-explorer-2012-ndash-associating-recent-work-items.aspx

Extension available at: http://visualstudiogallery.msdn.microsoft.com/9ed2d30c-a692-42b0-a21d-cdc8d2bf322c

I have been playing around a bit lately with extending Team Explorer 2012, mostly because it is fun but also to fix a little nagging feature that should have been there from the beginning. Often I (and a lot of other people) find myself wanting to associate several consecutive changesets to the same work item. The problem is that Team Explorer does not remember this, instead I have to either remember the ID or use a query that hopefully will match the work item.

Where is the work item that I just associated with?

True, when using the My Work page and the teams and sprint backlogs are correctly setup, you can find “your” work items there, but every so often this is not the case, and off I go to locate that work item again.

So this seemed to be a good feature to implement and at the same time learn a little about how to extend Team Explorer in Visual Studio 2012.

There is a great sample posted by Microsoft over at MSDN, it also talks about the main extension points and classes/interfaces that you need to know about. You can find it here: http://code.msdn.microsoft.com/windowsdesktop/Extending-Explorer-in-9dccd594. If you have developed extensions to Visual Studio before, you will be relieved to know that this new extension model for Team Explorer is purely based on standard .NET/WPF and MEF, no weird COM interfaces.

You can add new pages to Team Explorer, you can add new sections to existing pages and you can add navigation links to the Home screen. All these extensions are discovered by Team Explorer using the Managed Extensibility Framework (MEF). You just need to attribute your classes with the correct attribute and it will be found by Team Explorer. The attributes also control where your extension will appear. This extension is a Section that should appear inside the Pending Changes page:

Example of attributing a Team Explorer extension

The last property (35) is a priority number that controls when the extension is created and also where it will placed relative to the other sections. The existing Related Work Items section has priority 30, so 35 will place our extension right below it.

We also need to implement the ITeamExplorerSection interface, that contains properties and methods that needs to be implemented for anything to show up.

ITeamExplorerSection interface

The most interesting property here is the SectionContent property which is where you return the content of your extensions. This is typically a WPF user control in which you can add any controls you like.

This is how the extension appear inside the Pending Changes page. It will analyze your recent changesets in the current team project and extract the last 5 associated work items and show them in a list.
From the list you can then easily add a work item to the current pending changes by right-clicking on it and select Add. You’ll note that the work item will then disappear from the list, since you are not likely interested in adding it again.

Recently Associated Work Item section

I encourage you to read the MSDN article for more information about the possibilities to extend Team Explorer 2012. Also, try out the extension and let me know it you find it useful!

TFS Build: Running Static Code Analysis for Specific Configuration

Jakob Ehn — Sun, 20 Jan 2013 20:54:47 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2013/01/20/tfs-build-running-static-code-analysis-for-specific-configuration.aspx

Running Static Code Analysis (SCA) is something that you should be doing regularly to verify your code base against a large set of rules that will check your code for potential problems and how it comply with standard patterns such as naming conventions for example. Microsoft include several different rule sets that you can use for starters, but you can build your own rule sets as well, that contain the rule that you want to use, In addition, you can write your own custom rules and add these to your rule sets.

What you will notice quickly when you start running SCA for larger solutions is that it can take a lot of time. Therefore, you normally don’t want to run this on your local build but instead run it as part of your automated builds. It is recommended to set up a specific build for your projects that measures code quality, by running for example SCA, Code Metrics and Code Coverage. All these things take time to complete, so don’t put these in your Check-In builds, but in a Quality Assurance (QA) build.

Configuring Static Code Analysis
With Team Foundation Build, it is easy to run Static Code Analysis as part of the build, just modify the Perform Code Analysis process parameter in your build definition:

There are three possible values that you can use here:

Never – Never run Static Code Analysis
As Configured – If the project is configured to run Static Code Analysis for the current configuration, then SCA will be executed
Always – Always run Static Code Analysis, independent of how the projects are configured

If you select As Configured, you need to make sure that you have configured your projects correctly. This is done by opening the Properties window for your project and select the Code Analysis tab:

As you can see, the Code Analysis settings are specific to the Configuration and Platform for the project. This means that you can, for example, run code analysis only on Debug builds and not on Release builds.

Now, while using project specific settings like this to control when SCA is executed works, it has some drawbacks. When the solutions start to grow in size, it can be hard to make sure that the settings in every project is correctly configured. Also, as mentioned before, you typically don’t want to run SCA at all on your local builds, since it makes your build times longer. This can be solved by for example making sure that only the Release configuration has the Enable Code Analysis on Build property set to true, and then you only build the Debug configuration locally.

A better way to solve this is to control this completely from the build definition instead. You do this by setting the Perform Code Analysis process parameter to Always, as shown above. This will make sure that SCA are run for all projects, no matter how they are configured.

Running SCA for specific configurations

A problem that we faced recently at a customer that are running big builds (1+ hours) is that they are building both the and Debug and Release configurations as part of their builds. We wanted to run SCA on these builds, and we don’t want to configure each project (the solutions has 150+ projects in it). But, setting Perform Code Analysis to Always, this will result in SCA being run for both Debug and Release builds resulting in a considerable increase in build time.

So, how can we make sure that SCA is executed on all projects, but only on on (or several) configurations? One way of doing this is to customize your build template and add a parameter that specifies these configurations.

Here are the steps to accomplish this:

If creating a new build template from scratch, branch the DefaultTemplate.11.1.xaml build process template.
Open the template in Visual Studio
Select the top Sequence activity and expand the Arguments tab
At the bottom of the list, add a new parameter called RunSCAForTheseConfigurations with StringList as type
Locate the MetaData process parameter and click on the browse button on the very right
Add a new entry for the new parameter
Inside the workflow, locate the MSBuild activity that is used for compiling the projects. It is right at the end of the Compile the Project sequence:
Right-click the MSBuild activity and select Properties
Locate the RunCodeAnalysis property and open the expression editor
Enter the following expression

The expression evaluates if the current configuration (platformConfiguration.Configuration) is specified in our new property.
Save the workflow and check it in

Now you can create a new build definition and enter one or more configurations in the new property:

Since this is a property of type StringList, you can add multiple configurations here if you want to.

You can see from this build summary that SCA has only been performed on the Debug configuration, and not for Release.

Conclusion

I have shown one way to implement automatically running Static Code Analysis on a subset of configurations for a build that builds multiple solutions. This is very useful when you have large builds that compile multiple configurations.

Hope you found this post useful.

Book “Team Foundation Server 2012 Starter” published!

Jakob Ehn — Thu, 29 Nov 2012 08:33:42 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/11/29/book-ldquoteam-foundation-server-2012-starterrdquo-published.aspx

During the summer and fall this year, me and my colleague Terje Sandstrøm has worked together on a book project that has now finally hit the stores!
The title of the book is Team Foundation Server 2012 Starter and is published by Packt Publishing.

You can find it at http://www.packtpub.com/team-foundation-server-2012-starter/book or from Amazon http://www.amazon.com/dp/1849688389

The book is part of a concept that Packt have with starter-books, intended for people new to Team Foundation Server 2012 and who want a quick guideline to get it up and working. It covers the fundamentals, from installing and configuring it, and how to use it with source control, work items and builds. It is done as a step-by-step guide, but also includes best practices advice in the different areas. It covers the use of both the on-premises and the TFS Services version. It also has a list of links and references in the end to the most relevant Visual Studio 2012 ALM sites.

Our good friend and fellow ALM MVP Mathias Olausson have done the review of the book, thanks again Mathias!

We hope the book fills the gap between the different online guide sites and the more advanced books that are out. Check it out and please let us know what
you think of the book!

Book Description

Your quick start guide to TFS 2012, top features, and best practices with hands on examples

Overview

Install TFS 2012 from scratch
Get up and running with your first project
Streamline release cycles for maximum productivity

In Detail

Team Foundation Server 2012 is Microsoft's leading ALM tool, integrating source control, work item and process handling, build automation, and testing.

This practical "Team Foundation Server 2012 Starter Guide" will provide you with clear step-by-step exercises covering all major aspects of the product.
This is essential reading for anyone wishing to set up, organize, and use TFS server.

This hands-on guide looks at the top features in Team Foundation Server 2012, starting with a quick installation guide and then moving into using it for your
software development projects. Manage your team projects with Team Explorer, one of the many new features for 2012.

Covering all the main features in source control to help you work more efficiently, including tools for branching and merging, we will delve into the Agile Planning
Tools for planning your product and sprint backlogs.

Learn to set up build automation, allowing your team to become faster, more streamlined, and ultimately more productive with this
"Team Foundation Server 2012 Starter Guide".

What you will learn from this book

Install TFS 2012 on premise
Access TFS Services in the cloud
Quickly get started with a new project with product backlogs, source control, and build automation
Work efficiently with source control using the top features
Understand how the tools for branching and merging in TFS 2012 help you isolate work and teams
Learn about the existing process templates, such as Visual Studio Scrum 2.0
Manage your product and sprint backlogs using the Agile planning tools

Approach

This Starter guide is a short, sharp introduction to Team Foundation Server 2012, covering everything you need to get up and running.

Who this book is written for

If you are a developer, project lead, tester, or IT administrator working with Team Foundation Server 2012 this guide will get you up to speed quickly
and with minimal effort.

Using Private Extension Galleries in Visual Studio 2012

Jakob Ehn — Wed, 07 Nov 2012 19:47:34 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/11/07/using-private-extension-galleries-in-visual-studio-2012.aspx

Updated January 13th 2013: Added note about ASP.NET MVC 4.0 prerequirement

Note: The installer and the complete source code is available over at CodePlex at the following location: http://inmetavsgallery.codeplex.com

Extensions and addins are everywhere in the Visual Studio ALM ecosystem! Microsoft releases new cool features in the form of extensions and the list of 3rd party extensions that plug into Visual Studio just keeps growing. One of the nice things about the VSIX extensions is how they are deployed. Microsoft hosts a public Visual Studio Gallery where you can upload extensions and make them available to the rest of the community. Visual Studio checks for updates to the installed extensions when you start Visual Studio, and installing/updating the extensions is fast since it is only a matter of extracting the files within the VSIX package to the local extension folder.

But for custom, enterprise-specific extensions, you don’t want to publish them online to the whole world, but you still want an easy way to distribute them to your developers and partners. This is where Private Extension Galleries come into play. In Visual Studio 2012, it is now possible to add custom extensions galleries that can point to any URL, as long as that URL returns the expected content of course (see below).Registering a new gallery in Visual Studio is easy, but there is very little documentation on how to actually host the gallery.

Visual Studio galleries uses Atom Feed XML as the protocol for delivering new and updated versions of the extensions. This MSDN page describes how to create a static XML file that returns the information about your extensions. This approach works, but require manual updates of that file every time you want to deploy an update of the extension.

Wouldn’t it be nice with a web service that takes care of this for you, that just lets you drop a new version of your VSIX file and have it automatically detect the new version and produce the correct Atom Feed XML?

Well search no more, this is exactly what the Inmeta Visual Studio Gallery Service does for you :-)

Here you can see that in addition to the standard Online galleries there is an Inmeta Gallery that contains two extensions (our WIX templates and our custom TFS Checkin Policies). These can be installed/updated i the same way as extensions from the public Visual Studio Gallery.

Installing the Service

The service uses ASP.NET MVC 4.0, so make sure that you have this installed on your web server.
Download the installer (Inmeta.VSGalleryService.Install.msi) for the service and run it.
The installation is straight forward, just select web site, application pool and (optional) a virtual directory where you want to install the service.

Note: If you want to run it in the web site root, just leave the application name blank
Press Next and finish the installer.
Open web.config in a text editor and locate the the <applicationSettings> element
Edit the following setting values:
- FeedTitle
  This is the name that is shown if you browse to the service using a browser. Not used by Visual Studio
- BaseURI
  When Visual Studio downloads the extension, it will be given this URI + the name of the extension that you selected. This value should be on the following format:
  http://SERVER/[VDIR]/gallery/extension/
- VSIXAbsolutePath
  This is the path where you will deploy your extensions. This can be a local folder or a remote share. You just need to make sure that the application pool identity account has read permissions in this folder
Save web.config to finish the installation
Open a browser and enter the URL to the service. It should show an empty Feed page:

Adding the Private Gallery in Visual Studio 2012
Now you need to add the gallery in Visual Studio. This is very easy and is done as follows:

Go to Tools –> Options and select Environment –> Extensions and Updates
Press Add to add a new gallery
Enter a descriptive name, and add the URL that points to the web site/virtual directory where you installed the service in the previous step
Press OK to save the settings.

Deploying an Extension
This one is easy: Just drop the file in the designated folder! :-) If it is a new version of an existing extension, the developers will be notified in the same way as for extensions from the public Visual Studio gallery:

I hope that you will find this sever useful, please contact me if you have questions or suggestions for improvements!

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

Jakob Ehn — Wed, 05 Sep 2012 19:39:47 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/09/05/get-started-using-build-deploy-test-workflow-with-tfs-2012.aspx

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

Jakob Ehn — Fri, 24 Aug 2012 12:28:36 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/08/24/new-functionality-in-tfs-build-manager-ndash-managing-triggers-and.aspx

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!

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
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

Jakob Ehn — Thu, 23 Aug 2012 19:57:13 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/08/23/new-vs2012-book-pro-application-lifecycle-management-with-visual-studio.aspx

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!

ALM Rangers Readiness GIG has shipped!

Jakob Ehn — Thu, 16 Aug 2012 07:38:39 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/08/16/alm-rangers-readiness-gig-has-shipped.aspx

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

Jakob Ehn — Sun, 15 Jul 2012 21:51:33 GMT

Originally posted on: http://geekswithblogs.net/jakob/archive/2012/07/15/tfs-build-dependency-replication-using-community-tfs-build-extensions.aspx

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 . Of course, you can add it yourself and post it back to the community.