Where/How do I get started with TFS?


Question: Where or how should I get started with Team Foundation Server?

Answer 1: It depends.. What do you want to accomplish?

Answer 2: Install, Get comfortable with source control, then move on to the next thing. Most likely build and/or work item usage.


Let’s delve into this a bit more.

Answer 1: It depends….

In this scenario, you really want to assess your current environment, as well as your key needs and priorities.When you review what Application Lifecycle Management entails, you realise that it made up of multiple areas including process, testing, project management, requirements management, source control & config management, testing, architecture, and code quality.

You might find doing an ALM assessment useful. You can find an online version of such an assessment. Doing such an assessment can assist with determining where you rank in each of those areas, and help determine where you should be focussing. There are companies that can assist with this process as well.

From a TFS perspective, let’s look at what you can use it for, and some of the dependencies. Before I start, let me iterate that the key value proposition with TFS is the integration between these components. There are some who believe that TFS is all or nothing. This is certainly not the case. The intention of the bits below is to indicate what parts could be used in conjunction with other tools.

Team Foundation Server can be broken down into the following components:

Source Control – Can be used standalone. You could for example use a third party testing tool or build server with TFS.

Test Case Management – This can be used standalone. It does leverage and require the workitem capabilities of TFS, so TFS does need to be installed. You don’t have to use the TFS Source Control or Build Server but you will lose some benefits here. You generally do require the Visual Studio Test Professional Product in order to be productive here.

Defect Management – TFS can be used as a standalone defect management tool. Once again, it leverages the TFS workitem capabilities. You don’t have to use TFS Source Control or Build. As per above, you do lose some of the integration capabilities. For example the ability to associate a work item with a changeset (aka a checkin).

Project Management – This can be used standalone. You could manage your work using TFS and use something else to manage source, build etc. Again, you lose the integrated functionality.

Reporting – Cannot be used standalone. The reporting is intertwined with the other components of TFS. If all that you need is reporting capabilities on top on what you already have (and that is not TFS), then the rich reporting capabilities of TFS will not help.

Lab Management – Can be used partially in a standalone environment, but TFS does still need to be installed. If you have an existing source control and build system, it is possible to still use Lab Management. Lab Management allows you to pickup a build from a share, and you can use this as a basis to deploy and test. It will be a bit more involved in this scenario, and once again you will lose some functionality. You will however need to use the Test Case Management capabilities in order to execute your tests. I will look to blog a bit more on this in future

Build Server – Cannot really be used standalone. The build server does depend upon using TFS source control. Technically you could use a different system for managing work, bugs and test cases, but you will lose the integrated functionality.  If you really dig deep, you could probably modify the build template to get the source code from another system, but the effort here could be high.

Again, let me iterate that the key benefit with TFS is that it provides integration between the various components above. So while it is possible to use some components in a standalone type fashion, you would need to put in some additional effort, and you will not be realizing the benefits. But the reality is that in some situations, you do have some existing systems in place, and adopting a component might make sense.

This best example I can give of this is around Test Case Management. I have met customers who already have processes and tools in place for source and build.They are not looking at immediately changing this, but they could install TFS and use it purely for Test Case Management and execution.


Answer 2: Start with Source Control…

This is a more general answer, and is based on the current environment of many development teams. Many dev teams today don’t have a “formal” process today, and to a large degree mainly use just source control – and in some cases the source control system is regarded as the backup system.

Many of these development teams, however, want to start adopting more aspects of application lifecycle management, and want to get onto the agile train. In a situation like this, TFS provides a great platform for improving your software processes. The mistake some teams make though, is that they try and adopt all aspects of TFS overnight, rather than taking an incremental approach.

In this scenario, I recommend starting with Source control. If you are on Sourcesafe, migrate this over to TFS, and than make sure that everyone on the team is comfortable using TFS as a source control repository. You might also want to think about aspects like branching and merging in the context of how you deal with multiple versions, quick fixes and different isolated teams working on a project.

Once you are happy with this, you can consider moving onto build servers and/or managing work. There is also nothing stopping you from having parallel implementations. For example a set of manual testers could start to use the testing capability (refer to above though).

Note: TFS2010 has a basic install and also more flexibility around configuring different components. This allows you to install TFS without setting up reporting and Sharepoint for example. Initially a team starting with just source control might not need the portal or reporting in the near term. Your longer term plan, however, might require these components. In these cases I would recommend that you configure these initially. Trying to add these capabilities later is possible, but is a bit more complex.


Comments (1)

  1. Niel Zeeman says:

    good post!

Skip to main content