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!

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

  1. 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.



  2. Here is the problem I have with the label suggestion. I agree that ideally what we should have is a “good retention policy” and then to make sure all labels are dropped when the build is dropped. Unfortunately there is in reality no way to create a good retention policy. TFS retention policy is limited to a number of builds. Period. That’s insufficient, and should not be called a policy at all, but a threshold. To create a good retention policy we need to create rules that match the actual needs of the business. A retention policy should take into account things like setting limits based on the quality of the build — for example, keep all builds with a quality of Released, and at least the last 5 builds that were Ready for Deployment, and maybe the last 20 that were Ready for Lab Test, and then after that keep at least the last 30 but no more than 50 development builds. Then, set storage quotas, alerts, etc to ensure that the stakeholders are aware when storage is reaching capacity, or when purging the builds is happening. And purging should be done as needed — ideally during off hours, unless an urgent storage capacity threshold is reached.

    Because there is no such reasoning in the “policy”, we can only keep a certain fixed number, which means that in some cases, if a bunch of builds are done in one day for instance, we can end up with 20 builds from today at the expense of losing the previous 20 builds. Who needs 20 builds from the same day?

    So because of this I actually exercise the opposite advice: NEVER drop labels if there is a chance that those labels could become critical labels (usually based on their build quality.) I have toyed around with the idea of writing an application that would allow the use of rules in the retention policy, but in the meantime, I will put the needs of release management above the needs of the administrators and ensure that all labels are retained.

    1. I agree that the current policy is not sufficient. I often use branch creation to identify every production delivery (based on the Version Control Guidance). That makes me create more builds but after the Community TFS Build Extensions it is very easy. I also mix several types of builds depending of the team maturity: gated checkin with no output to validate the code, and “nightly” builds with package creation and the full range of tests. I also noticed that people prefer use a changeset number than a label to identity a version because a changeset can be used for several build defintions.

Leave a Reply

Your email address will not be published.