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
- 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 http://visualstudiogallery.msdn.microsoft.com/bce6cbf1-fb55-4a7d-b39b-8589634d846f. 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!