Cleaning historic buildings from the Global List

Question

What is the best practice for cleaning up unused or old collections from the global list?

Currently, each CI assembly adds its own shortcut to the Builds list. Over time, the list becomes inflated, and sometimes we manually delete unused ones from the list.

Answer 1

The global TFS list is bloated, but it works . We have the same problem.

I suggest doing the following:

• Modify work item type definitions to include the Allow existing values for WIT fields that rely on the global list for assembly list (for example, Found in Assembly field in Errors).
• Periodically (manually or on a schedule) delete old assemblies. You can take a look at each retention policy for an assembly definition. It will be safe to delete assemblies that should not be saved (the last 10 definitions are by default). I suggest automating this and querying the TFS database to make sure the assemblies are safe to delete.
• Alternatively, you can look at the location of the removal of the assembly and analyze the results of the directory (i.e. save the strobe that is stored there).

Answer 2

TFS adds these labels to the global list so that work items can be associated with specific assemblies. Theoretically, you should not “clear” the assembly list from the global list, because you will leave any work items that use these lists as a value that is in an invalid state.

There are other lists that inflate over time, for example, the list of users "assign". Anyone who has ever been a valid user for this team project will appear on this list for the same reason as above. If you delete a user, the user leaves the work items in an invalid state. You will receive an error message when you try to associate change groups with other actions or perform other operations with invalid work items.

There should be no performance issues with long lists of items. It becomes an annoying selection from a huge list in the drop-down list ... but it's a kind of TFS beast character. It saves all kinds of information so that you can stretch metrics over time.

See the Tfs_Analysis cube or transactional tables for assembly. You will find data rows for every assembly you have ever run. (TFS 2008 deleted rows from transactional tables when deleting an assembly ... in TFS 2010, the data is saved and the IsDeleted flag is set in the database, so the data remains there forever)

Answer 3

I don’t know how to clean old assemblies - we also have a useless bloated list including hundreds of remote collections that make fields such as “error” found in “unusable”.

However, most of the build-up can be reduced for CI assemblies, as you may not need / need labels for them. Each assembly definition can be edited to stop its source control marking when the assembly begins. (I can’t offer complete instructions, I’m afraid, because I am now far from my computer)