Partager via

So how do you find time to manage TFS?

  • Article

TFS is a large product. Not a day goes by for me without discovering something new. With this size and complexity comes the potential for a significant administrative burden. Create a team project here, assign some permissions there, and the poor TFS administrator will be run off their feet. Sound familiar? IMO, this type of administrative model, while seemingly attractive, goes against the spirit of TFS. It isn't called Team Foundation Server for nothing

Developers have earned a reputation for being "cowboys" and in many cases, not without reason. This alone causes organisations to control access by developers to resources of any type. TFS is often no exception. However, I believe that TFS is a development tool that is best left up to the development teams to administer. But before you pack your bags to join me on the commune, this does not mean that everyone is made a TFS Administrator. The key is a well thought-out process of delegation. That is, rather than lock everything down so tight that the TFS administrator has to do everything, figure out what you can safely outsource to the users.

Safely outsource? Is that possible? Here are a few thoughts:

  • Remember that you can't permanently delete items from source control. This means that any "mistakes" can generally be undone. You may therefore get away with granting more access to source control by default than you may have initially thought.
  • Let the owner of a team project look after it. Sure, Project Administrators can delete the project, but if you're truly worried about that (given that you have to go out of your way to actually torch a team project), you probably have the wrong people on the payroll!
  • Do you really need to be the one that creates all the areas for a team project? One option is to allow a group of users to create sub-areas beneath a node of your choosing. If it gets out of hand, all your reports can still work against the node you initially created.
  • Don't fall into the trap of managing TFS security by assigning rights to individuals. Always use groups of some description. Where this isn't feasible, outsource it.
  • Don't try to keep secrets. Granting read-only access to everything by everyone by default can save a lot of administrative time. Besides, not hiding anything is great for communication!

Now for the words of warning... Keep your TFS Administrators (and Project Administrators for that matter) down to as few people as possible. These users can really wreak havoc (I guess I'm about to be booted off the commune). Finally, keep your IT Pros (and DBAs) away from TFS. Trust me, they can't just "tweak" it to make it better. Don't get me wrong, IT Pros are absolutely essential to the delivery of good software. However, we sometimes have different opinions on how to achieve it.

Comments