TFS as a true cross-technology ALM platform

March 3, 2012

A while ago I was involved in a request for a big financial institution to come up with a Proof-Of-Concept document to move a large Java development team to TFS 2010. The same request was sent to another consultancy firm to have a solution on top of GIT and the Atlassian tools.

Guess what?! The final decision was to move the entire Java development team to TFS 2010. During the evaluation process I had to cope with a lot of non-believers, but I’m pretty sure that a lot of Java people were quite impressed and unaware of the possibilities that the current and future ALM offering from Microsoft delivers. On the other hand, I was also surprised by some interesting features in the Atlassian product suite. Both solutions actually met the specific requirements, but in the end I strongly believe that the company made the correct decision to choose for TFS 2010 as a true cross-technology ALM platform. Ultimately this was an objective decision based on the facts and not a decision led by gut feeling or emotion.

First of all, there was already an existing and mature TFS 2010 infrastructure in place which served a .NET and SharePoint development team. Team Foundation Server 2010 introduced an evolved architecture built to scale to the most challenging of teams and scenarios. A high available multiple server environment was already set up to support a potential load of up to 400 developers. The architecture included two distinct TFS Application Tiers which sit behind a load balancer. The TFS Data Tier is running in a SQL Cluster for high availability. This architecture can easily be extended with an extra TFS Application Tier and an extra SQL Server instance for optimizing the load on multiple Team Project Collections.

TFSInfra

More information on scalability for TFS 2010 can be found here.

Another explicit requirement was to easily cope with the most important version control operations and to be able to track and manage individual changes in parallel development scenarios. The Java team was still stuck with an older version control system which could not live up to the expectations of a modern version control system.

Switching to another version control system like TFS Version Control (or GIT) means that the involved stakeholders will need to be trained to make use of the new tool/system in an optimal way. While switching to another tool, there’s also an opportunity to adapt the existing way of working. Choosing for example a more appropriate branching & merging strategy is certainly recommended to simplify software configuration management. TFS 2010 introduced a number of excellent branching & merging features to fully support development teams (including configuration managers and release managers) in their day-to-day operations. Most actions can be easily triggered from the UI and don’t require complex command line operations:

  • Branches are first class citizens in the version control repository
  • Branch Hierarchy & Timeline View
  • Tracking Individual Changesets across branches
  • Drag And Drop Functionality to Merge Branches
  • Cherry-pick merging
  • Branching & Merging on Label or DateTime
  • Full rollback functionality for individual changesets or set of changesets
  • View hierarchical history of changes across branches
  • Annotate feature to view history in source code
  • Compare version control folders on branch/label/datetime
  • Compare local workspaces with server version control folders
  • Fine-grained permissions on version control folders and branches
  • Associate a distinct file type with a specific merge tool

image

Needless to say that GIT as a DVCS also offers a powerful version control system and even offers better support for offline version control but these scenarios were not explicitly required.

Deep version control integration in a Java IDE was naturally another requirement. Visual Studio Team Explorer Everywhere 2010 helps .NET and Java development teams collaborate across platforms. It provides the tools and plug-ins to access Team Foundation Server 2010, so everyone can work together to achieve business goals. Team Explorer Everywhere 2010 works with the Eclipse-based IDE, in the operating system of choice and helps to collaborate across .NET and Java development teams. It’s an easy-to-install standalone plug-in which offers easy access to all possible version control operations. More information on Team Explorer Everywhere can be found here.

image

Of course, Team Foundation Server is a whole lot more than only version control. I will add a few other important integrated features that were important for the final decision.

image

The build services provided by TFS 2010 offer an enterprise-class, distributed build platform. Utilization of the build services is done inside the IDE (Team Explorer Everywhere plug-in in Eclipse) in which the code is being created. The build services provide notifications on build events using the standard TFS eventing mechanisms, which means that email alerts can easily be sent to the team regarding build status. Continuous Integration builds make sure that the individual developer can be identified who broke the build. There’s even a Gated Check-In trigger available that can prevent broken builds. The build process, based on Windows Workflow Foundation is highly extensible to adapt to the needs of complex business environment. The Team Foundation Build Architecture is also extremely scalable with the introduction of a Build Controller and a pool of Build Agents which can be spread across different machines.

image

image

As from the TFS 2010 release, the ALM offering also includes a full solution for managing test plans, designing test cases and test reporting. Microsoft Test Manager (part of the Test Professional Suite or Visual Studio Ultimate) is a tool for functional testers and connects to TFS for executing and recording manual/automated tests from dedicated test case work items. Creating bugs and follow-up has become convenient due to the excellent integration with the Build Automation system. Bug reports now include automatically (due to diagnostic data adapters) all important information the developers need to reproduce and fix the bug. Visual Studio Lab Management is an add-on for TFS that allows deploying and testing applications in virtual test environments and includes a framework to file rich actionable bugs due to the various data collectors (for example video recording). Automated UI tests can also be easily integrated in existing build definitions.

image

Reporting in TFS 2010 is one of the most powerful features. All possible data in TFS is stored in a SQL Server database where data is regularly processed in a data warehouse and in analytical cubes. For every created Team Project in TFS, you will automatically get a number of out-of-the-box SQL Reporting Services reports and a number of customizable reporting dashboards in the SharePoint team project portal. Existing reports can be easily customized or new reports can be easily added and shared for multiple stakeholders. Microsoft Excel can also be used to quickly define ad-hoc Pivot table reports based on the SQL Analysis cubes.

image

What about compliance (Sarbanes-Oxley Act)? Well, this requirement was probably very important in the final decision! Team Foundation Server provides three main pieces of functionality as it relates to SOx – Work Item Tracking, Version Control and Automated Build. These three features working together provide the capability to eliminate many of the risks associated with SOx 404 compliance. At the heart of SOx is the ability to know who made what change when, what requirement was the change made for and who authorized the change to be made. Was the requirement tested to make sure that it works correctly and who authorized the release of that requirement to production? Or, to state it another way, is the requirement traceable? Many technical solutions require multiple tools to provide this kind of traceability and generally they break the traceability chain at some point because they are not integrated at all required points. With Team Foundation Server 2010, full traceability is baked in. Team Foundation Server provides a comprehensive and flexible set of capabilities through traceability, test case management and automated builds. The rich extensibility of both the built-in features and a third-party ecosystem gives you the tools you need in order to meet the requirements of SOx.

Full article on Sox and TFS 2010 available at http://msdn.microsoft.com/en-us/library/gg983694.aspx.

GIT on the other hand was initially designed as a version control system for open source workflows and may have compliance issues inside strictly regulated (financial) institutions due to a number of reasons:

  • User Auditing: a commit in GIT is associated with a simple string (any string but by convention a name and email address). This can be changed at any time and doesn’t offer full traceability to a controlled identity.
  • Path based access control: TFS has very fine-grained control over permissions at any point in the repository. GIT (in common with other DVCS tools) has no way to do this.
  • Administration: a centralized version control system life TFS provides a central place to perform and audit administration activities including security, access control, permissions management of user accounts, backup, et. DVCS tools like GIT don’t offer that out-of-the-box.

Conclusion

Team Foundation Server doesn’t only offer a solution for reliable version control, but offers a fully integrated Application Lifecycle Management (ALM) solution for the enterprise. The requested requirements for the entire Java development process could all be fulfilled with the existing high-available TFS 2010 setup that was currently in use for another existing development program. Against the global perception of Microsoft products, Team Foundation Server is really extensible on client- and server-side (http://msdn.microsoft.com/en-us/library/bb130146.aspx) and offers a lot of room for customization on all levels. From the early beginning, extensibility was a core design principle – both to enable great 3rd party partners and because all development shops have a need to customize the tools they use. There’s also a public TFS 2010 SDK for Java which includes documentation, samples and redistributable components to help developing software products that integrate with TFS 2010.

A final big thank you to all the Microsoft involved people who helped to make this project a success. This was also a good demonstration of vendor commitment to the customer: support by local sales persons, together with product group people and partners. Up to me now to accompany the rollout in the field!

TFS v.Next has also an interesting roadmap and will even more become the default cross-technology ALM choice:

Note that TFS v.Next went into Beta last week and includes a go-live license. More information can be found at the blog of Jason Zander (corporate vice president for the Visual Studio team in the Developer Division at Microsoft).

Leave a Comment » | Uncategorized | Permalink
Posted by pietergheysens

Managing Builds through the Build Quality value

February 12, 2012

The integration in TFS between Builds and Work Items is just too good. In this blog post I will describe a solution based on a TFS Server Plugin to have more fine-grained control on completed builds.

Completed builds may sometimes be more valuable for the development team and only a few of them will eventually be published/deployed for (public) Testing. This means that Testers (in theory) should only be able to log bugs against these particular builds.

There are two important fields on a bug work item which may point to a build: “Found in Build” and “Integrated in Build”.

BuildQuality1

For both fields a value can be selected from a combobox. The values in the combobox are part of the global list for the builds in the active Team Project.

BuildQuality2

By default, ALL finished builds (failed + succeeded) will trigger the BuildCompletion event in the Team Project Collection and the accompanying Build Number will be appended to the existing global list for the builds in the Team Project. In Team Projects where a lot of builds are defined, this “Builds” global list will be flooded by superfluous builds which should never be selected for the above fields. CI builds for example should not be part of this global list. Only full builds which are deliberately transferred for testing should be searchable in the above comboboxes.

So, how to explicitly mark a build for “Testing”? This can be easily done with setting a Build Quality for a given build.

BuildQuality3

Note that people who want to modify the Build Quality should have the permission “Edit build quality”.

BuildQuality4

Build Quality values can also be managed in a dedicated list.

BuildQuality5

By using a specific Build Quality value, it’s also possible to create a TFS Server Plugin and to listen to a BuildQualityChangedNotification event and to only add the Build Number to the global list when the Build Quality is set to “Ready for Initial Test”. Of course, the default event-subscription for the BuildCompleted event must be disabled and the existing global list should be cleaned.

This is exactly what I did. Only the Build Numbers of the builds that get a desired Build Quality (“Ready For Initial Test”) will be pushed to the global list of the Builds in the Team Project.

When your team makes fully use of Microsoft Test Manager to file bugs, the “Found in build” field can be automatically set by associating particular builds to a Test Plan. Test execution can then be done against an approved build list. The “Integrated in build” field is normally automatically set by the build process which picks up a bug resolution through a changeset at check-in time.

BuildQuality6

BuildQuality7

Some more details how I did implement the customization of the global build list:

Delete the out-of-the-box event-subscription for the BuildCompleted event

The easiest way is actually to navigate to the event-subscription table via SQL Management Studio (tbl_EventSubscription in specific Team Project Collection database) and to delete the event-subscription row from there. But, that shortcut is not really recommended I’m afraid. A safer solution is to rely on the Bissubscribe command line tool ((executable can be found in :\Program Files\Microsoft Team Foundation Server 2010\Tools). Strange enough, there’s no option to list the existing event-subscriptions, but there certainly is an unsubscribe switch to unsubscribe from an event-subscription. You will need the ID of the event-subscription. The only way to get this ID without having to write custom code on the TFS API is to get the ID from looking into the tbl_EventSubscription table in SQL Management Studio. Note that it’s the Integer ID you will need instead of the GUID Subscriber ID.

BuildQuality8

BuildQuality9

Recreating this default event-subscription is possible through the command BisSubscribe /eventType BuildCompletionEvent /address http://:8080/tfs//WorkItemTracking/v1.0/Integration.asmx /collection http://:8080/tfs/.

Clean up the existing “Builds” global list

The global list of a Team Project Collection can be exported/imported with the witadmin command-line options or you can export/import a global list through the UI with the Process Editor from the TFS Power Tools.

BuildQuality10

You will be prompted to store the GlobalList.xml file after which you may edit the list. Delete as many ListItem entries as you want in order to clean up the Build list. This is the value list that will be used for the “Found in Build” and “Integrated in Build” fields.

BuildQuality11

Import the global list back to TFS via witadmin or the Process Editor.

BuildQuality12

To immediately witness the result, you may need to restart Visual Studio to clear the cache.

Activate the TFS Server Plugin for processing BuildQualityChangedNotification events

Since TFS 2010, it has become fairly easy to write custom event handlers that will run in the context of Team Foundation Server. It’s a plugin (dll) that needs to be deployed on the TFS Application Tier. How to accomplish this is not well documented, but your best starting point would be to read Chapter 25 of the book Professional Team Foundation Server 2010. Grant Holliday – one of the authors – explains how the ISubscriber interface can be used for extending Team Foundation Server.

For my purpose I implemented the ISubscriber interface in my BuildQualityChangedEventHandler class. The Build Quality I will use in my example is “Ready For Initial Test”. This action should append the Build Number to the Build global list of the Team Project.

BuildQuality13

Next task was to pick up the BuildQualityChangedNotificationEvent and to take action when the Build Quality was set to “Ready For Initial Test”: export global list, append the current Build Number and import the list back to TFS.

BuildQuality14

That’s it, build the assembly and drop it in the plug-in folder on all active TFS Application Tiers.

BuildQuality15

Setting the Build Quality to “Ready For Initial Test” does the trick and adds the Build Number to the Build global list for the appropriate Team Project.

BuildQuality16

As an extra, I also decided to keep the “Ready For Initial Test” builds indefinitely.

BuildQuality17

BuildQuality18

Controlling your builds with the Build Quality value in combination with a TFS Server plugin gives you a lot of power! The next step could be to trigger deployments off a Build Quality value …

7 Comments | Team Build | Permalink
Posted by pietergheysens

TFS 2010: Virus Scan file/folder exclusions

December 20, 2011

At several customers I have seen that some Virus Scan Systems (no names) have a serious negative impact on the performance of Team Foundation Server. Especially the Build Server may be an easy target for the Virus Scanning actions.

Here’s my latest recommendation I have sent to the Ops Team. Note that all involved servers run Windows Server 2008 R2 (64 bit) and the software is installed on the C drive. The TFS Application Tier also has WSS 3.0 (SP2) installed. Use at your own risk and good luck to get this approved by your Ops Team. Traditionally they handle the presumption of innocence principle: the virus scan is innocent until proven guilty!

  • TFS Application Tier
    • C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\_tfs_data [TFS Version Control Cache folder]
    • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions [SharePoint Portal]
    • C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files [SharePoint Portal + Web Access]
    • C:\Users\TFSWSSAccount\AppData\Local\Temp [SharePoint Portal]
  • TFS Build Server(s)
    • Build Agent(s) working directory: D:\Builds
    • TFS local cache folder for TFSBUILD account: C:\Users\TFSBUILDAccount\AppData\Local\Microsoft\Team Foundation
  • TFS Data Tier
    • SQL Server data files: .mdf + .ldf
  • Client DevSeat
    • TFS workspaces folder: D:\TFS

I did find some official references:

Leave a Comment » | Installation & Configuration of TFS | Tagged: | Permalink
Posted by pietergheysens

The importance of Continuous Building/Integration

December 13, 2011

Automatically triggering a build after each check-in (continuous integration option in TFS Build Definitions) in a development branch is a good practice that nowadays needs less explanation than a few years ago. Many development teams seem to adopt this practice quite well, but there’s still a lot of room for improvement.

The main benefit of enabling continuous (integration) builds is clear: providing early feedback on the validity of the latest code changes that were committed to the version control repository. I won’t discuss in detail the different checks (compilation, deploy, test) that should be part of the validation step (as always: it depends!), but for this post I want to focus mainly on the importance of having at least a continuous (integration) build. A future topic to tackle is how to get your CI builds as fast as possible with TFS 2010.

TriggerCI

The first guideline that developers should follow if they want to reap the full benefits of CI builds, is to check-in early and often. I’m often worried/shocked when developers show me the amount of pending changes in their local workspace. This nearly always leads to the conclusion that those developers are working on many different tasks at the same time which should be avoided at all cost. The risk of committing unwanted files for a dedicated change is just too high. There are a number of version control features available to safely switch to another task: shelving or creating an extra workspace. The next version of TFS (TFS11) will even include better support for task-driven development through a revised Team Explorer (more details in this blog post of Brian Harry). Check-in early and often does of course not mean that developers must just check-in changes that are not ready yet and not locally validated, but it does mean that developers should work on small incremental changes. This requires every involved developer to break down their assigned work into small tasks which may result in a check-in operation. Ideally, as a developer, you should commit your changes to the version control repository at least daily. And don’t forget to provide a decent comment for the check-in operation in addition to an association with a work item. This meta-data might become quite important in some merging scenarios.

Having a CI build and adopting a check-in early and often policy, will lead to the fact that a broken build can only be caused by an incremental small change which should be easier to fix than a large changeset or a combination of multiple changesets by different developers. More frequent check-ins will further decrease the amount of files that could be part of a conflicting changeset that caused the build to fail.

BuildOverview

Another golden rule in a CI environment is to fix the broken build as soon as possible and to delay other commits of pending changes. This implies that a notification mechanism should be put in place to warn the development team about broken builds. In Team Foundation Server 2010, you can easily set up an e-mail alert or you can rely on the built-in Build Notifications tool. The developer who caused the build to fail must take responsibility to fix it immediately. The check-in operation of a developer can only be considered as completed/done when the CI build has built successfully the latest changeset.

My recommended 10-step workflow for all developers:

DeveloperWorkflow

After the last step, you may start all over again or you may just go home! Committing changes to version control requires you at least to wait until the CI build has finished successfully. Do you really want to impact the entire development team by going home without verifying your latest changes?

This reminds me to my early years where I was a junior .NET developer in a mid-sized development team. At that time, there wasn’t yet a proper build server and we never heard of continuous integration before. I don’t have to tell you how many times all developers were impacted by an invalid check-in and how much time we spent on finding the culprit. You probably have all been in a similar situation.

  • Dev1: My local build fails after a get latest
  • Dev1: Who did a check-in recently? Anyone heard of method X?
  • Dev2: I Just did a get latest and everything works fine!
  • Dev3: Are you sure that you took a “real” latest of everything?
  • Dev1: Wait, let me redo a get latest to be sure!
  • Dev4: Damn, I also took a get latest and my build now fails!
  • …
  • Dev2: Sorry guys, I might have forgotten to check-in a file!

In some cases, the person who caused the build to fail was not at his desk (sick/holiday/meeting) the moment the build failure was discovered! Yeah, those were the times we all never want to go back right? Not to mention what this type of troubleshooting costs!

In brief, it’s all about discipline and communication. Having a nice up-to-date build dashboard on a big screen might definitely help to make everyone aware of the importance of the latest build status.

In a next blog post I will talk about the importance of the CI build speed. It’s obvious that for providing early feedback, the CI builds must run as fast as possible. What’s the value of a CI build that takes more than 1 hour?! There are some interesting things you can enable in the TFS Build Definitions to optimize CI build definitions.

Note that since TFS 2010, there is also the Gated Check-in trigger option that will even prevent broken builds by delaying the actual commit until a successful build was run with the latest code changes in a temporary shelveset.

2 Comments | Team Build | Tagged: | Permalink
Posted by pietergheysens

Visual Studio 11 ALM Preview

September 17, 2011

The BUILD conference held last week in California was not only the start for getting the details about Windows 8, but was also the time where Team Foundation Server on Windows Azure was announced with a public preview.

TFSService

Read all about the preview on this blogpost from Brian Harry. I have been part of a private preview in the past months and I’m really thrilled with the hosted TFS Service coming our way. This will surely decrease the infrastructure and maintenance obstacle for many small and medium enterprises. Note that the service is far from ready and many features (reporting for instance) are still missing. The interesting part with a hosted and reliable TFS service is the ability to (automatically) push new features more frequently to the public. Quite a big difference with hosting a private Team Foundation Server on-premise.

You may also configure a local build server against a hosted TFS account which was made possible with Windows Azure Access Control Services (ACS).

If you were not able yet to pick up an invitation code for registering your TFS 11 account, you may use my invitation code [5 users left – first come, first served]: a0d8ad92-c44b-4ce7-82ed-b63b8fd91979. Visit tfspreview.com and use this code.

Next to this, you may also download a preview/CTP of Team Foundation Server 11 which is designed to showcase updates and improvements made since TFS 2010 and provides an opportunity for developers to use and provide feedback before the final release. See this blog post at ALM Rocks for detailed installation steps. A preview of Visual Studio 11 can be downloaded here.

Instead of doing a full install of TFS 11 (including Windows Server 2008 R2, IIS, SQL Server, SharePoint, Visual Studio 11 …), I decided to wait for the Visual Studio 11 ALM Virtual Machine which is a fully prepared and configured Hyper-V virtual machine. Thanks to Brian Keller for making this available once again!

TFS 2010 was already a BIG release with a strong focus on Testing and Architecture, but the upcoming release won’t disappoint neither. Exciting times!

[For the people in Belgium: note that an interesting user group event (AZUG) is coming up with Clemens Reijnen, a colleague VS ALM MVP, who will give a session on ALM for Windows Azure.]

4 Comments | Uncategorized | Permalink
Posted by pietergheysens

Errors during build execution while downloading large files from Version Control

August 3, 2011

In a large SharePoint development project at a customer I was confronted with the not always reproducible build error while syncing the build workspace:

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

image

This error sometimes occurred while downloading the larger database backup files (> 1.5GB) which are required in the deployment and test phase.

Luckily a patch (KB981898) for the TFS Application Tier (Windows Server 2008 R2) does exist to resolve this particular issue! Also have a look at this blog article for more background info.

Also thanks to Giulio Vian for helping me out with this issue!

Leave a Comment » | Team Build | Tagged: | Permalink
Posted by pietergheysens

Work Item Only View (WIOV) Users in TFS 2010

June 29, 2011

Team Web Access (TWA) is a customizable Web interface that can access Team Foundation Server project data. It acts as a client of Team Foundation Server and provides most of the functionality available through Visual Studio Team Explorer. Users that connect to TFS via TWA should also have a valid Client Access License (CAL).

WIOV

But … without having a CAL you may also create and view/modify work items that are created by you in Visual Studio Team Foundation Server. To perform these tasks, you need only Team Web Access in Work Item Only View (WIOV) and the required permissions.

Taken from the Visual Studio 2010 Licensing Whitepaper (area Client Access License Exception for Certain Work Items):

A user does not need a CAL or External Connector License to create new work items or to update work items that that same user has created. This exception applies only to work items related to defect filing or enhancement requests. However, a CAL is required when a user views or modifies a work item created by another user or interacts with Team Foundation Server in any other way.

Great, but how to make this work inside Team Foundation Server 2010?

Open up Team Foundation Administration Console and click on the Group Membership link that belongs to the Application Tier tab.

image

There you will find a TFS Security Group Work Item Only View Users. User accounts of users should be added to this group when these users should only have access to the Work Item Only View feature.

The actual downgrade of the permissions for these users is set through the Security Administration.

image

This TFS Security group is denied access to the full Web Access features.

Being part of this group will show you a limited version of Team Web Access where you will only be able to view and manage your own work items.

image

3 Comments | Installation & Configuration of TFS | Tagged: | Permalink
Posted by pietergheysens

« Previous Entries
Next Entries »
Follow

Get every new post delivered to your Inbox.