An introduction to Agile development with Team Foundation Server: But I’m not a .NET developer

1. TFS support for Agile practices
2. Tailoring TFS to support your Agile process with process templates
3. Iteration planning
4. Information radiators
5. But I’m not a .NET developer
6. Agile support in TFS 11

I thought it would be interesting to get some guest writers in this series of blogs and I’m very grateful to Richard Fennell from Black Marble for providing this post. We work with Richard (and Black Marble ) a lot and he’s an expert in this area as recognised by his award as a Microsoft Most Valuable Professional (MVP) for Visual Studio (ALM) and as an ALM Ranger . You can read more from Richard on his blog . Over to Richard…

The reaction when looking at Visual Studio Team Foundation Server (TFS) for many companies is

‘That all sounds great but we work in a heterogeneous environment; we develop in a variety of tools not just Visual Studio, it is not for us’ .

In today’s modern connected world this is a very common position; there are few companies who can completely ignore the needs of non-Windows developers of mobile platforms such as Java, iPhone and Android.

Enter TEE

This issue has been recognised by Microsoft and, via their purchase a couple of years ago of Teamprise, now offer Team Explorer Everywhere (TEE) to help fill this gap.

TEE is a Java implementation of the TFS client which can be used in two ways on any operating system that supports Java

1. from the command line (so is an equivalent to the standard TF.EXE command on Windows)

2. or as plug-in in any Eclipse based IDE (providing the same features as Team Explorer in Visual Studio).

The key point here is that, especially in Eclipse, the experience of a developer using TEE is the same as it would be on a Windows platform with Visual Studio. They have the same options in Team Explorer

• They can access the same work items and work item queries
• They can access the same SharePoint Portal (it is just a web site after all!)
• They can access the same Reporting Services hosted reports that report on the same data sources
• And most importantly they can access the same source code repository

All this functionality means that there should be no need to change working practices between a Java or .NET project. All the developers can follow the same Application Lifecycle (ALM) process. So features that need to be delivered that cross development platforms (e.g. a .NET web service that is called by a Java based front end) can be broken down to their constituent development tasks and passed to the required development teams, irrespective of the target platform or development environments. The .NET features can be developed in Visual Studio and the Java features in Eclipse. As work it is completed in either stream it is checked back into the same TFS source repository and the same set of TFS work items are updated. This means, as there is a single project for all platforms then project wide unified reports can be generated.

However, all this TFS integration does not mean that an Eclipse developer cannot use the other tools within the IDE. TEE wires into Eclipse in the same manner as any other source code repository provider, so in no way reduced the range other Eclipse features that can be used, for example a developer can also make use of the Eclipse ALM task management tool Mylyn which can be linked directly to TFS via the plugin provided by TaskTop.

Equally TEE is not limited to use with Eclipse and Java. As it is a standard Eclipse plugin there is no reason it cannot be used to manage the source and work items associated with any form of file editing based development supported by Eclipse.

But I want to automate my build too

But being able to work within the IDE on non-Microsoft platforms to access work item and the source control repository is not enough. Any company’s mature ALM process will include some form of automate build. Wouldn’t it be good if this build functionality could also be unified across platforms?

The first way this can be done is provided with TEE and the TFS Build Extension Power Tools. A developer is able, from within Eclipse, to define a TFS build. This will be executed on a standard Windows based TFS build system and will eventually run a standard ANT or Maven (2 or 3) build.

This means a Java developer can used all the features of Ant or Maven, defining a build that not only builds their project but also run jUnit tests. The result of these jUnit tests are in turn published to TFS, again making the experience of the java developer as close to the .NET developers as possible and with the added benefit that the test results are available in the TFS build reports irrespective of the platform the view is on.

There is an alternative way to automated builds that is not based on the TFS Team Build system, though this not directly support by Microsoft. You can use your existing non-Microsoft build process e.g. Ant or Maven themselves, but make use the TF command line tools to integrate them with TFS.

Remember that TF command line tools are availability as both Windows (.NET) and Java versions. So you are not limited on the operating system for your build box or build technology in use.

Obviously working this way will require some hand crafting of build scripts, but keep an eye open for the next release of ALM Rangers Build Customisation Guidance, as this will include a new section on this very subject.

But I don’t use an IDE

But not all roles in software development use IDE tools.

• Team members such as graphic designers often use tools that have no awareness of integrated source control so cannot check files in and out from within their tools.
• There are developers working with command line based tools, especially in areas such as the embedded device market.

So for people in these roles the TEE Eclipse plugin or Team Explorer in Visual Studio is not the answer.

There is the TF command line tool as mentioned above, this allows check-in and out using a command line, but this is not the friendliest way to work is it? An alternative if the user is running on a Windows platform is the Windows Shell Extension TFS Power Tool. This allows files to be check in and out of TFS using a right click within Windows Explorer.

This can provide a very productive means of working for many people. Again building on the tools they use every day, in this case Windows Explorer.

But what about the server?

TFS is based on Windows Server technology, for some companies this might be a problem.

• they may not wish to have a dedicated TFS server in house as their development team is small
• or may not have any Windows servers at all if they don’t work with Microsoft platforms.

Historically this requirement for a Windows server has been a stumbling block for TFS. Some vendors do offer hosted TFS on a cost per developer per month model, but these offerings are based on the standard TFS 2010 architecture.

At the Build Windows 2011 Conference Microsoft announced ‘Team Foundation Service’ hosted on Azure. This is a preview of a service that uses the same codebase as TFS 11, the next version of TFS.

Team Foundation Service removes the need for an in house TFS server, it can be accessed using any TFS11 compatible client, so can be used from Visual Studio, Eclipse or the command line.

Why you may ask why you would use Team Foundation Service over other hosted source control providers. The answer is the standard one for TFS; TFS is a complete ALM solution, providing end to end work item tracking a reporting as well as source control.

This means a distributed team, no matter what their development platforms is, can access the Azure hosted Team Foundation Service via a web browser or their IDE of choice irrespective of their location. And most importantly their progress is tracked using a unified work item/ reporting model across all the development platforms. Providing a complete end-to-end ALM solution.

[Giles: I’ll cover more on the Team Foundation Service in a later post in this series]

Have I convinced you to have a look?

So the fact that your developers do not only work on Microsoft platforms does not mean TFS is not a possible choice of ALM solution.

Irrespective of the development environment in use TFS can be accessed from command lines, browser and IDEs. Providing a heterogeneous development environment that means work can be tracked across the whole ALM process.

Comments

• Anonymous
  February 02, 2012
  Sorry, but until you can take the words "check-in and out" out of this article, the rest of it is frankly irrelevant. TFS can have all the wonderful features in the world, but while the source control is still recognisably SourceSafe it's just too painful to work with. In 2012 it shouldn't take hours for a remote worker to create a branch, and nobody should have to "check that file back in so I can work on it". "TFS is a complete ALM solution" with the most important bit fundamentally broken.

• Anonymous
  February 02, 2012
  @Mark. Team Foundation Server is not based on Visual SourceSafe.  However, like Visual SourceSafe it is a centralised version control system and judging by your comment you probably prefer a distributed version control system.  That’s okay, but they do not fit everyone’s requirements. Branching with TFS is fast - a new branch will be created and committed as a single operation but the files are not duplicated on the server (changesets in TFS are stored as reverse deltas).     Multiple Checkout is default behaviour for TFS so if you have to ask users to check-in files before you work on them then this is a conscious decision made by your system administrator. You might be interested in some enhancements to version control happening in TFS 11 with “Local Workspaces” - more details are available here: blogs.msdn.com/.../version-control-model-enhancements-in-tfs-11.aspx You may also be interested in Team Foundation Service: http://tfspreview.com/ Email us blogs.msdn.com/.../contact.aspx or direct message us @VisualStudioUK and we’ll sort you out with an invite code.

• Anonymous
  February 03, 2012
  Publishing non-MSTest (e.g. NUnit) unit testing results to TFS is more difficult that it should be in TFS 2010 from Visual Studio. I'm interested in using the eclipse plugin for some Python development and wonder how feasible it is to have the python test results pushed into TFS for analysis later, or perhaps more specifically what are the general steps and how hard it is to set-up and maintain this scenario

• Anonymous
  February 05, 2012
  Hi Dylan, On your first point you're correct and you may be interested to know that in the next version of Visual Studio there will be much better suport for non-MSTest unit test frameworks. This document takes you through support for other testing frameworks: download.microsoft.com/.../Unit%20Testing%20with%20Visual%20Studio%2011%20-%20MSTest,%20NUnit,%20xUnit.net,%20and%20Code%20Clone.docx On the question of how to publish python test results I don't specifically know but the general approach to publish custom results is to either:

1. Generate a .trx file (xml based format) for the test result output from your custom testing framework (or wrapper on it) and use tcm.exe (msdn.microsoft.com/.../dd465192.aspx) to publish the trx.  Check msdn.microsoft.com/.../cc164248.aspx which though dated is good article on this topic.
2. Use the Test Case Management APIs to directly pump the data from your custom testing framework (or wrapper).  The APIs are documented at msdn.microsoft.com/.../dd465178.aspx.  There are some good blogs on this topic here: blogs.msdn.com/.../densto. TFS now has both a .NET API and a Java API (www.microsoft.com/.../details.aspx) so I would assume the latter route might be the place to start? I hope this helps, Giles

• Anonymous
  February 06, 2012
  Thanks for the pointers Giles. I'll definitely look into it. Cheers