You are a configuration manager. You have been charged with the responsibility of deploying Team Foundation Server into your enterprise so that project teams comprising of project managers, business analysts, developers, testers and even end users can use it to deliver high quality line of business applications. Are you prepared?
Obviously you have carefully studied the TFS installation guide and read widely about the installation experiences of other configuration managers in your same position and you think you are ready to perform the installation.
Is wish you luck! But have you considered the principles of Team Foundation Server administration?
Principles of Team Foundation Server Administration
In the coming months there are going to be a lot of configuration managers and build masters moving ahead with the deployment of Team Foundation Server into their enterprise. This is a good thing – when deployed and used correctly TFS can significantly enhance the analysis, scheduling, development, testing and feedback processes of development teams, however, if used incorrectly it can be quite frustraiting experience for everyone involved.
With that in mind I offer up these principles of TFS administration which should help guide your adoption and long term satisfaction with the product:
- Team Foundation Server is development infrastructure
- Beware the build server
- Administer the server, not the process
- Version control process templates
I firmly believe that the infrastructure requirements of developers in terms of standard desktop images vary greatly from that of a standard user. Typically a developer will need to have administrative rights to their local machine, and sometimes even need to run a server operating system.
With power comes responsibility and one of the important things that development teams need to realise is that Team Foundation Server is development infrastructure, as such it should be carefully managed and not put on a box which is the dumping ground for miscellaneous pieces of software.
When provisioning you should avoid co-locating TFS with any other parts of your computing infrastructure. This makes sense for a couple of reasons – for one you may not be able to install it in the first place, but secondly it creates an unnatural dependency with another system which could limit future options.
Another sugguestion that I like to make to people is giving each team their own build server. While the build server can and likely will (initially) be co-located on the TFS application tier, at some point in a projects lifecycle it is going to want to put something into the build that is going to require a special piece of software or configuration to be installed on the TFS box.
Don’t do it! Remember, Team Foundation Server is development infrastructure and you shouldn’t install miscellaneous pieces of software on it.
Of course, letting development teams run their own build server shouldn’t be a problem in most cases but some configuration managers feel that they need absolute control, which brings me onto my next point – administer the server, not the process.
Team Foundation Server allows teams to choose which process they use – in fact, they allow teams to customise that process to meet their requirements. As a configuration manager don’t get too precious about how people are using version control – provided they aren’t impacting other teams you can let most things slide and be responsive to requests to load new process templates (after testing them in a virtualised environment).
Finally – if you are going to do process template customisation I would strongly recommend that you keep them locked up safely in version control. This has the side benefit of being able to easily evolve your internal processes over time so each team isn’t starting from a (potentially) distant baseline.