为生成、发布和测试设置保留策略
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
注意
Microsoft Visual Studio Team Foundation Server 2018 和早期版本在命名方面具有以下差异:
- 用于生成和发布的管道称为定义
- 运行称为生成
- 服务连接称为服务终结点
- 阶段称为环境
- 作业称为阶段
借助保留策略,可以设置在系统中存储的运行、发布和测试的保留时间。 为了节省存储空间,需要删除较旧的运行、测试和发布。
Azure DevOps 的“项目设置”中提供了以下几种保留策略:
- 管道 - 设置项目、符号、附件、运行和拉取请求运行的保留时间。
- 发布(经典)- 设置是否保存生成并查看默认和最大保留期设置。
- 测试 - 设置自动和手动测试运行、结果和附件的保留时间。
注意
如果使用本地服务器,还可以指定项目的保留策略默认值,以及何时永久销毁发布。 本文后面的部分中详细介绍了发布保留。
先决条件
默认情况下,参与者、生成管理员、项目管理员和发布管理员组的成员可以管理保留策略。
若要管理保留策略,你必须具有以下订阅之一:
还可以每月购买 Azure Test Plans 访问权限,并分配基本 + 测试计划访问级别。 请参阅按用户角色测试访问权限。
配置保留策略
登录到你的项目。
转到项目设置的“设置”选项卡。
在“管道”下选择“发布保留”或在“测试”下选择“保留”。
- 选择“发布保留”以设置发布保留策略,并配置何时删除或永久销毁发布。
- 选择“保留”以设置手动和自动测试运行的保留时间。
配置保留策略
登录到你的项目。
转到项目设置的“设置”选项卡。
在“管道”下选择“设置”或“发布保留”,或者在“测试”下选择“保留”。
- 选择“设置”,为运行、项目、符号、附件和拉取请求运行配置保留策略。
- 选择“发布保留”以设置发布保留策略,并配置何时删除或永久销毁发布。
- 选择“保留”以设置手动和自动测试运行的保留时间。
重要
Azure Pipelines 不再支持按管道保留策略。 建议使用项目级保留规则。
设置运行保留策略
在大多数情况下,已完成的运行的保留时间不需要超过一定的天数。 使用保留策略,可以控制在删除运行之前每个运行的保留天数。
除了定义运行的保留天数之外,还可以确定应为每个管道保留的最小运行数。
警告
Azure DevOps 不再支持每个管道的保留规则。 为 YAML 和经典管道配置保留策略的唯一方法是使用上述项目设置。 不能再配置每个管道的保留策略。
为每个管道保留的最近运行数的设置需要更多说明。 此设置的解释根据管道中生成的存储库类型而有所不同。
Azure Repos:Azure Pipelines 为管道的默认分支和存储库的每个受保护分支保留了配置的最近运行数。 配置了任何分支策略的分支被视为受保护分支。
例如,以具有两个分支
main
和release
的存储库为例。 假设pipeline's default branch
是main
分支,release
分支具有分支策略,使其成为受保护分支。 在这种情况下,如果将策略配置为保留三个运行,则会保留main
分支的最近三个运行和release
分支的最近三个运行。 此外,还会保留此管道的最近三个运行(无论是什么分支)。为了进一步阐明这个逻辑,我们假设此管道的运行列表如下所示,最近的运行在最上面。 该表显示了在已配置为保留最近三个运行的情况下,将保留哪些运行(忽略天数设置的影响):
运行编号 分支 保留/不保留 为什么? 运行 10 主要 保留的 最近 3 个用于主要,最近 3 个用于管道 运行 9 branch1 保留的 最近 3 个用于管道 运行 8 branch2 保留的 最近 3 个用于管道 运行 7 主要 保留的 最近 3 个用于主要 运行 6 主要 保留的 最近 3 个用于主要 运行 5 主要 不保留 最近 3 个既不用于主要,也不用于管道 运行 4 主要 不保留 最近 3 个既不用于主要,也不用于管道 运行 3 branch1 不保留 最近 3 个既不用于主要,也不用于管道 运行 2 发布 保留的 最近 3 个用于发布 运行 1 主要 不保留 最近 3 个既不用于主要,也不用于管道 所有其他 Git 存储库:Azure Pipelines 为整个管道保留配置的最近运行数。
TFVC:Azure Pipelines 为整个管道保留配置的最近运行数,而不考虑分支。
运行的哪些部分被删除
当保留策略将生成标记为要删除时,你可以控制删除与生成相关的哪些信息:
- 生成记录:可以选择删除整个生成记录,或在生成被删除后仍保留有关生成的基本信息。
- 源标签:如果将源标记为生成的一部分,可以选择删除生成创建的标记 (Git) 或标签 (TFVC)。
- 自动测试结果:可以选择删除与生成关联的自动测试结果(例如,由发布测试结果生成任务发布的结果)。
删除生成时,将删除以下信息:
- 日志
- 已发布的项目
- 已发布的符号
删除运行时,将删除以下信息:
- 日志
- 所有管道和生成项目
- 所有符号
- 二进制文件
- 测试结果
- 运行元数据
- 源标签 (TFVC) 或标记 (Git)
通用包、NuGet、npm 和其他包不绑定到管道保留。
何时删除运行
保留策略每天处理一次。 处理策略的时间是可变的,因为我们出于负载均衡的目的,会将工作分散在一天中进行。 没有任何选项可以更改这个过程。
如果满足以下所有条件,就会删除运行:
- 已超过在保留设置中配置的天数
- 它不是在保留设置中配置的最近运行之一
- 它不会标记为无限期保留
- 未按发布保留
保留策略每天在凌晨 3:00 (UTC) 运行。 没有任何选项可以更改策略运行时间。
在管道运行上自动设置保留租约
保留租约用于管理超过已配置的保留期的管道运行的生存期。 通过调用租约 API,可以在管道运行上添加或删除保留租约。 可以使用脚本和针对 runId 和 definitionId 的预定义变量在管道中调用此 API。
可以在特定时段内在管道运行上添加保留租约。 例如,部署到测试环境的管道运行可以保留较短的持续时间,而部署到生产环境的运行可以保留更长时间。
在管道运行上手动设置保留租约
设置发布保留策略
经典发布管道的发布保留策略确定链接到它的发布和运行的保留时间。 使用这些策略,可以控制每个发布在上次修改或部署后要保留的天数,以及每个管道应保留的最小发布数。
每次修改发布或将其部署到阶段时,发布上的保留计时器值都会重置。 要保留设置的最小发布数优先于天数。 例如,如果指定至少保留三个发布,不管指定的天数如何,最近三个发布都将无限期保留。 但是,如果不再需要这些发布,可以手动删除它们。 若要详细了解发布保留的工作原理,请参阅下面的常见问题解答。
作为发布管道的作者,可以在“保留”选项卡上为管道的发布自定义保留策略。
YAML 和生成管道的保留策略是相同的。 可以在“设置”部分的“管道”的“项目设置”中查看管道的保留设置。
本文后面的内容还介绍了如何逐阶段自定义这些策略。
全局发布保留策略
如果使用本地 Team Foundation Server 或 Azure DevOps Server,可以指定项目的发布保留策略默认值和最大值。 还可以指定何时永久销毁发布(从生成资源管理器的“已删除”选项卡中移除)。
如果使用 Azure DevOps Services,可以查看项目的这些设置,但不能进行更改。
可以从项目的“发布保留”设置中查看全局发布保留策略设置:
- Azure DevOps Services:
https://dev.azure.com/{organization}/{project}/_settings/release?app=ms.vss-build-web.build-release-hub-group
- 本地:
https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub
最大保留策略设置所有发布管道可以保留的发布时长的上限。 发布管道的作者不能为他们的定义配置超出此处指定的值的设置。
默认保留策略为所有发布管道设置默认保留值。 生成管道的作者可以重写这些值。
销毁策略可帮助你在删除发布后保留一定的时间。 不能在单个发布管道中重写此策略。
设置集合级别保留策略
对于本地服务器,还可以使用自定义保留规则设置集合级别保留策略。 这些保留策略适用于经典生成管道。 https://{your_server}/{collection_name}/_settings/buildqueue
的页面规定了最大值和默认值。
注意
在 TFS 中,发布保留管理仅限于指定天数,并且仅在 TFS 2015.3 及更高版本中可用。
特定于阶段的保留策略
你可能需要保留已部署到特定阶段的更多发布。 例如,你的团队可能需要进行以下保留:
- 将部署到生产阶段的发布保留 60 天,上次部署的发布至少有 3 个。
- 将部署到预生产阶段的发布保留 15 天,上次部署的发布至少有 1 个。
- 将部署到 QA 阶段的发布保留 30 天,上次部署的发布至少有 2 个。
- 将部署到开发阶段的发布保留 10 天,上次部署的发布至少有 1 个。
发布管道的以下示例保留策略满足上述要求:
在本例中,如果部署到开发的发布在 10 天内未提升到 QA,则它可能是要删除的候选项。 但是,如果在部署到开发 8 天后将同一个发布部署到 QA,则会重置其保留计时器值,在系统中再保留 30 天。
指定每个管道的自定义策略时,不能超过管理员设置的最大限制。
生成和发布保留策略之间的交互
链接到发布的生成具有其自己的保留策略,保留期可能比发布的保留期要短。 如果要将生成保留与发布相同的时长,请为相应的阶段设置“保留关联的项目”复选框。 这会替代生成的保留策略,并确保在需要重新部署该发布时项目可用。
当你删除发布管道、删除发布时,或者当保留策略自动删除发布时,关联的生成的保留策略将确定何时删除该生成。
注意
在 TFS 中,TFS 2017 及更高版本中提供了生成与发布保留之间的交互。
设置测试保留策略
可以设置手动和自动测试运行策略。
手动测试运行保留策略
若要在特定天数后删除手动测试结果,请在项目级别设置保留限制。 即使删除了这些生成,Azure DevOps 也会保留与生成相关的手动测试结果。 这样,生成策略就不会在你分析数据之前删除测试结果。
登录到 Azure DevOps。 至少需要项目管理员权限。
转到项目,然后选择页面底部的 项目设置。
- 在“测试”部分下的“保留期”页中,选择要保留手动测试数据的时间限制。
自动测试运行保留策略
默认情况下,Azure DevOps 只在你保留生成时保留与这些生成相关的自动测试结果。 若要在删除生成后保留测试结果,请编辑生成保留策略。 如果使用 Git 进行版本控制,可以根据分支指定保留自动测试结果的时长。
登录到 Azure DevOps。 至少需要生成级别权限才能编辑生成管道。
转到项目,然后选择页面底部的 项目设置。
- 在“管道”下选择“ 设置”,然后修改保留策略。
其他自动测试结果
若要清理从已删除的生成中留下的自动测试结果或与生成无关的测试结果(例如,从外部测试系统发布的结果),请在项目级别设置保留限制,如手动测试运行保留策略中所述
设置项目保留策略
可以在管道设置中为管道运行设置项目保留策略。
登录到项目,对于 Azure DevOps Services,URL 路径为
https://dev.azure.com/{yourorganization}/{yourproject}
。转到项目设置的“设置”。
选择“管道”中的“设置”。
编辑“项目、符号和附件的保留天数”。
使用“复制文件”任务将数据保存更长时间
使用“复制文件”任务,可以将生成和项目数据的保存时间设为超过保留策略中所设置的时间。 “复制文件”任务比“发布生成项目”任务更可取,因为通过“发布生成项目”任务保存的数据将被定期清理和删除。
如果要从 Git 存储库生成,还可以逐个分支自定义这些策略。
全局生成保留策略
可以为项目集合指定生成保留策略默认值和最大值。 还可以指定何时永久销毁生成(从生成资源管理器的“已删除”选项卡中移除)。
- TFS 2018:
https://{your_server}/tfs/DefaultCollection/_admin/_buildQueue
最大保留策略设置了所有生成管道的运行可以保留的时长上限。 生成管道的作者不能为他们的定义配置超出此处指定的值的设置。
默认保留策略为所有生成管道设置默认保留值。 生成管道的作者可以重写这些值。
永久销毁发布可帮助你在删除运行后保留一定的时间。 不能在单个生成管道中重写此策略。
Git 存储库
如果存储库类型为下列类型之一,就可以使用分支筛选器来定义多个保留策略:
- Azure Repos Git 或 TFS Git。
- GitHub。
- 其他/外部 Git。
例如,你的团队可能需要进行以下保留:
- 将用户分支生成保留 5 天,每个分支至少有 1 个成功或部分成功的生成。
- 将主分支生成和功能分支生成保留 10 天,每个分支至少有 3 个成功或部分成功的生成。 需要将要保留更长时间的特殊功能分支排除在外。
- 将来自特殊功能分支和所有其他分支的生成保留 15 天,每个分支至少有 1 个成功或部分成功的生成。
生成管道的以下示例保留策略满足上述要求:
指定每个管道的自定义策略时,不能超过管理员设置的最大限制。
清理拉取请求生成
如果使用拉取请求生成来保护 Git 分支,可以使用保留策略自动删除已完成的生成。 为此,请添加一个策略,使用以下分支筛选器保留最少 0
个生成:
refs/pull/*
TFVC 和 Subversion 存储库
对于 TFVC 和 Subversion 存储库类型,可以使用上面所述的相同选项来修改单个策略。
策略顺序
当系统清除旧生成时,它会按你指定的顺序根据策略评估每个生成。 可以在列表中上下拖放策略以更改此顺序。
“全部”分支策略会自动添加为评估顺序中的最后一个策略,以强制执行所有其他分支的最大限制。
常见问题解答
如果将运行或发布标记为无限期保留,保留策略是否仍适用?
不是。 将单个运行或发布标记为无限期保留时,管道的保留策略和管理员设置的最大限制都不适用。 它将一直保留,直到你无限期停止保留它。
如何指定部署到生产的运行将保留更长时间?
如果使用经典发布部署到生产环境,可以在发布管道上自定义保留策略。 指定部署到生产环境的发布必须保留的天数。 此外,指示将保留与该发布关联的运行。 这将替代运行保留策略。
如果使用多阶段 YAML 管道部署到生产环境,可以配置的唯一保留策略是在项目设置中。 不能基于将生成部署到的目标环境来自定义保留期。
我没有将运行标记为无限期保留。 但是,我看到大量运行被保留。 如何防止出现这种情况?
这可能是以下原因之一导致的:
- 运行由项目中的某个人标记为无限期保留。
- 这些运行由一个发布使用,并且发布对这些运行持有一个保留锁。 按上文所述自定义发布保留策略。
如果你认为不再需要这些运行,或者发布已被删除,可以手动删除运行。
“要保留的最小发布数”设置是如何起作用的?
要保留的最小发布数是在阶段级别定义的。 它表示 Azure DevOps 将始终在一个阶段保留最近部署的指定发布数,即使这些发布已经超过了保留期。 只有在某一阶段开始部署时,才会根据该阶段要保留的最小发布数考虑发布。 同时考虑成功的部署和失败的部署。 不考虑等待审批的发布。
将发布部署到具有不同保留期的多个阶段时,如何确定保留期?
最终保留期是通过考虑所有阶段的保留天数设置来决定的,在这些阶段中,部署发布时会选择要保留的最长时间。 要保留的最小发布数在阶段级别进行管理,不会根据部署到多个阶段的发布而更改。 将发布部署到设置为 true 的阶段时,保留关联的项目将适用。
我删除了一个阶段,其中有一些旧发布。 在这种情况下,将考虑什么保留期?
由于删除了阶段,因此阶段级别保留设置现在不适用。 在这种情况下,Azure DevOps 将回退到项目级默认保留期。
我的组织需要我们将生成和发布保留比设置中允许的时间更长的时间。 如何请求更长的保留期?
如果希望运行或发布保留的时间超出保留设置允许的时间,唯一的方法是手动将其标记为无限期保留。 无法手动配置更长的保留期设置。 请联系 Azure DevOps 支持部门获取帮助。
还可以探索使用 REST API 的可能性,那样就可以下载有关运行的信息和项目,并将其上传到你自己的存储或项目存储库。
我丢失了一些运行。 是否有办法将其找回?
如果你认为由于服务中的某个 bug 而导致运行丢失,请立即创建支持票证以恢复丢失的信息。 如果生成定义是被手动删除的,并且删除时间已超过一周,则无法恢复它。 如果由于某个保留策略,运行按预期方式删除,则无法恢复丢失的运行。
如何使用代理的 Build.Cleanup
功能?
在代理上设置 Build.Cleanup
功能将导致池的清理作业仅定向到这些代理,让其他代理可以自由地执行常规工作。 删除管道运行后,存储在 Azure DevOps 外部的项目会通过代理上的作业运行进行清理。 当代理池中的清理作业达到饱和时,就会导致问题。 这个问题的解决方法是在池中指定一个代理子集作为清理代理。 如果任何代理设置了 Build.Cleanup
,则只有这些代理将运行清理作业,让其余代理可以继续运行管道作业。 通过导航到“代理”>“功能”,并将 Build.Cleanup
设置为等于 1
,可以启用清理功能。
删除生成时文件共享项目会发生什么情况
删除包含文件共享项目的生成时,新的生成任务在生成代理上排队以清理这些文件。 根据以下条件选择代理来执行此任务:具有 Build.Cleanup
功能的代理是否可用?
运行生成的代理是否可用?
同一池中的代理是否可用?
类似池中的代理是否可用?
是否有任何代理可用?
发布过程中发布的自动测试结果是否一直保留到发布被删除为止?
发布阶段内发布的测试结果按照为测试结果配置的保留策略指定的方式保留。 在保留发布之前,测试结果不会保留。 如果需要让测试结果的保留时间与发布一样长,请在项目设置中相应地将自动测试运行的保留设置设为“从不删除”。 这可确保仅当删除发布时才会删除测试结果。
是否会删除手动测试结果?
否。 不会删除手动测试结果。
如何保留版本控制标签或标记?
注意
即使删除了生成,也会保留在生成管道期间应用(但并非从源任务自动创建)的任何版本控制标签或标记。 但是,在生成期间从源任务自动创建的任何版本控制标签或标记都被视为生成项目的一部分,并将在删除生成时被删除。
如果需要即使删除了生成也能保留版本控制标签或标记,则需要将其作为管道中任务的一部分应用、在管道外部手动标记,或者限期保留生成。
其他管道中使用的管道会发生什么情况?
经典发布会保留它们自动使用的管道。
其他管道中使用的管道会发生什么情况?
经典发布会保留它们自动使用的管道。 如果使用 YAML,还可以创建多阶段 YAML 管道来表示发布,并在其中使用另一个 YAML 管道作为资源。 只要保留了发布管道,资源管道就会自动保留。
相关文章
反馈
https://aka.ms/ContentUserFeedback。
即将推出:在整个 2024 年,我们将逐步取消以“GitHub 问题”作为内容的反馈机制,并将其替换为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈