The TFS server automates the process of software generation and release through automated builds, which has been a very important functional module in the TFS System. The version of TFS released in recent years has greatly enhanced the capabilities of automation Building. In this blog I mainly summarize the issue of the generation record retention policy for TFS 2013.
In a TFS system, a large amount of temporary data is generated after each build, such as output version, log information, tags, test case records, and so On. This information has long been retained in the system, not only not much value, the maintenance of the system will also cause great trouble. therefore, it is necessary to set up a reasonable retention policy to improve the performance of the System.
In TFS 2013, The resulting retention policy is saved in the build Definition. In other words, each time you define a build, you need to set up a retention policy for this build, instead of setting a retention policy at the system level like TFS 20,151, such as:
Figure 1-retention Policy in the build definition
As you can see, the retention policy is divided into two categories: triggered and manual (triggered and Mannual) and Private.
1. Triggered and manual: refers to all types except for "gated check-in" (Gated check-in), including manual, continuous integration, rolling check-in, and scheduled builds.
2. Private policy: refers to a build with a "gated check-in" trigger.
When you create and modify a build definition, users can set the retention time for each type of build and the type of data that needs to be deleted after it Expires. With the exception of stopped, the system defaults to 10 reserved per Type.
When the amount of production data reaches the upper limit in the retention policy, the TFS system automatically deletes the stale build records in chronological order.
In addition, on the TFS team project home page, There is a diagram showing the resulting chart (Dashboard), which shows the latest 25 production records in the system, including the results of each build (green for success, red for failure, Orange for some successes), and relative length of time spent on each build, such as:
Http://www.cnblogs.com/danzhang/ALM MVP Zhang Hongjun
TFS 2013 Build (build) history retention Policies (Retention Policy)