TFS as a true cross-technology ALM platform

  • Article

This is a posting by one of our guest authors, Pieter Gheysens. The same post is available on his own blog https://intovsts.net. 

PieterGheysens_thumb1 Pieter Gheysens is the founder of Sparkles (www.sparkles.be) and focuses as a Visual Studio ALM MVP and Certified Scrum Master on Application Lifecycle Management solutions for the Microsoft .NET Development Platform based on Team Foundation Server. During the last 10 years, Pieter has been involved in many large enterprise development projects as a developer, team lead and software architect. He's passionate about setting up the optimal team development environment to deliver high quality software and strives to get the best out of people, tools and processes. You can read about his experiences at https://intovsts.net. Since a few years now, Pieter is the User Group Lead for the Belgian Visual Studio User Group (www.visug.be) which organizes many free technical community events with local and international speakers.

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 https://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 (https://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).