Top 10 other things every TFS Administrator should do

This post follows Rene’s top 10 list post:

11. Search and destroy old and/or unused label

Label table can be huge in the TFS database because there is a label entry for each file. Most of the time, you just need “key labels” associated with some golden builds. The best thing to do is a good build retention policy and be sure to remove the labels when the build are destroyed. Use Team Foundation Sidekicks to find the others.

12. Check access rights

If you start to grant some source control access rights user per user, you will be in a nightmare very soon. Do create TFS groups or (better) AD groups and give access to them instead of per user. IMHO AD groups are better because they are managed outside TFS and can be used to grant access to the reporting, sharepoint, build shares…

13. Remove unused and/or old shelvesets

Shelvesets are used by developers to save their work. But a 6 month old shelveset is most of the time useless because the source code are changed too much since it was created. Team Foundation Sidekick is also your best ally here to track them.

14. Remove obsolete build definitions

This is for clarity: only keep the builds that matter. An alternative is to deactivate the unused builds if you want to keep some of them. From Richard Arnold: do not forget to removed used workspace manually if you want to save some place on the build servers: delete files on the server and remove workspace into TFS.

15. Sync all your process templates to avoid too different projects & upgrade them

Several advantages:

  • only one process template to manage
  • developers are not lost when they switch to another project
  • you can use you time to work on reporting for this specific template

16. Use exclusive lock only when the file type cannot be merged

Some types cannot be merged. The exclusive lock will not remove the merge issue between two branches but it will help you to avoid conflicts inside a branch. Remove exclusive locks for all the other types.

17. Check if you have an exhaustive install document for your build machines

If you need to install a lot of things on a build machine, the documentation will help you to create another build machine easily & quickly. If you need a ticket for the support Team to install another build machine. Keep the reference of the ticket: it will save you some time!

18. Verify if all your customer VS are up to date (SP/CU…) & your server too

It is difficult to manage a heterogeneous set of softwares. For Visual Studio 2010, you have this tool It is easier for Visual Studio 2012: install the last update.

19. Create a symbol server & force symbol creation at build time

The symbol server will help you to access to the built version when you are debugging a built software. It is fully integrated with the build process.

20. Always have a backup server to test migration stuff on your project collection

You need an extra TFS Server as a sandbox to work on a copy of your Team Project Collection. Very useful when you are planning to migrate your process templates.

Hope this helps too!

2 thoughts on “Top 10 other things every TFS Administrator should do

  1. Richard Arnold

    A little addition to 14: Don’t forget that the workspaces are still mapped to your build machine if you delete a build definition. That could lead to unnecessary HDD usage on your build machine.




Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>