用于生成和发布的任务组(经典)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
注意
YAML 管道不支持任务组。 在这种情况下,可以使用模板。 请参阅 YAML 架构参考。
通过任务组,你可以将已在生成或发布管道中定义的一系列任务封装到可添加到生成或发布管道的单个可重用任务中,就像任何其他任务一样。 可选择从封装任务提取参数作为配置变量,并提取任务信息的剩余部分。
新任务组将自动添加到任务目录,并准备好添加到其他发布和生成定义中。 任务组存储在项目级别,不能在项目范围之外访问。
通过任务组,可以标准化和集中管理所有应用程序的部署步骤。 如果你在定义中包含任务组,然后对任务组进行集中更改时,该更改将自动反映在使用该任务组的所有定义中。 无需单独更改每一个定义。
创建任务组的前提条件
在你希望在使用任务组时能够在其中配置这些参数的场合,确保要包含在任务组中的所有任务的参数都定义为变量(例如 $(MyVariable))。 会自动提取任务中使用的变量并转换为任务组的参数。 这些配置变量的值将转换为任务组的默认值。
如果为参数指定值(而不是变量),该值将成为固定参数值,不能作为参数公开给任务组。
如果你为封装任务的参数指定了值(而不是变量),或者没有为其提供值,则这些参数在被添加到构建或发布管道之后,无法在任务组中进行配置。
任务条件(例如,对于 PowerShell 脚本任务,“仅当上一个任务失败时运行此任务”)可以在任务组中进行配置,并且这些设置与任务组一起保留。
保存任务组时,可以提供新任务组的名称和说明,并选择希望在“任务目录”对话框中的哪个类别中显示此任务组。 还可以更改每个参数的默认值。
将生成或发布进行排队时,将提取封装的任务,用户为任务组参数输入的值将应用于任务。
对任务组所做的更改反映在任务组的每个实例中。
创建任务组
确保要包含的所有任务不包含任何链接参数。 要确保这一点,一种简单方法是在整个过程的设置面板中选择“全部取消链接”。
在生成或发布管道中选择一系列任务,打开快捷菜单,然后选择“创建任务组”。
为新任务组指定名称和说明,以及要将新任务组添加到的类别(“添加任务”面板中的选项卡)。
选择“创建”后,将创建新的任务组,并替换管道中选定的任务。
底层任务中的所有“$(vars)”(预定义的变量除外)都将作为新创建的任务组的强制参数出现。
例如,假设有一个任务输入 $(foobar),你不打算将其参数化。 但是,创建任务组时,任务输入将转换为任务组参数“foobar”。 现在,可以 $(foobar) 作为任务组参数的默认值。 这可确保在运行时,扩展任务获得其预期相同的输入。
保存更新的管道。
管理任务组
在当前项目中创建的所有任务组都列在 Azure Pipelines 的“任务组”页中。
使用“导出”快捷方式命令将任务组的副本另存为 JSON 管道,并使用“导入”图标导入以前保存的任务组定义。 使用此功能在项目和企业之间传输任务组,或复制和保存任务组的副本。
选择任务组名称以打开详细信息页。
- 在“任务”页中,可以编辑构成任务组的任务。 对于每个封装的任务,可以更改非变量参数的参数值,编辑现有参数变量,或将参数值与变量相互转换。 保存更改时,使用此任务组的所有定义都将选取更改。
任务组的所有变量参数将在管道定义中显示为必需参数。 还可以设置任务组参数的默认值。
在“历史记录”选项卡中,可以看到组更改的历史记录。
在“引用”选项卡中,可以展开所有生成和发布管道的列表以及其他使用(引用)此任务组的列表。 这有助于确保更改不会对其他进程产生意外影响。
创建任务组的预览和更新版本
Azure Pipelines 和 TFS 中的所有内置任务都进行版本控制。 这样,生成和发布管道就可以继续使用任务的现有版本,同时开发、测试和发布新版本。 在 Azure Pipelines 中,可以对自己的自定义任务组进行版本控制,使其行为方式相同,并提供相同的优势。
编辑完任务组后,选择“另存为草稿”而不是“保存”。
任务组版本号后面将附加字符串 -test。 如果对更改感到满意,请选择“发布草稿”。 可以选择将其发布为预览版还是生产就绪版本。
现在可以采用下列方法之一在生成和发布过程中使用更新的任务组:更改现有管道中任务组的版本号;从“添加任务”面板添加。
与内置任务一样,添加任务组时的默认版本是最高的非预览版本。
完成对更新任务组的测试后,选择“发布预览”。 Preview 字符串将从版本号字符串中删除。 现在,它将在定义中显示为“生产就绪”版本。
在已包含此任务组的生成或发布管道中,现在可以选择新的“生产就绪”版本。 从“添加任务”面板中添加任务组时,系统会自动选择新的“生产就绪”版本。
使用任务组版本
任何任务组更新都可以是次要或主要版本更新。
次要版本
操作:编辑后直接保存任务组,而不是将其另存为草稿。
影响:版本号不会更改。 假设你有一个 1.0
版本的任务组。 你可以拥有任意数量的次要版本更新,如 1.1
、1.2
、1.3
等。在你的管道中,任务组版本显示为 1.*
。最新的更改将自动显示在管道定义中。
原因:这应该是任务组中的一个小更改,你期望管道使用此新更改,而无需在管道定义中编辑版本。
主版本
操作:将任务组另存为草稿,然后创建预览,验证任务组,然后将预览作为主版本发布。
影响:任务组将升级到新版本。 假设你有一个 1.*
版本的任务组。 新版本发布为 2.*
、3.*
、4.*
等。有关新版本可用性的通知显示在使用此任务组的所有管道定义中。 用户必须在管道中显式更新为新版本的任务组。
原因:如果发生重大更改,可能会中断现有管道,那么您可能需要对其进行测试,并将其作为新版本推出。 用户可以选择升级到新版本或选择保留相同版本。 此功能与常规任务版本更新相同。
但是,如果任务组更新不是中断性变更,但你希望先进行验证,然后强制实施管道以使用最新更改,则可以按照以下步骤操作。
- 使用所需的更改更新任务组,并将其保存为草稿。 将创建一个新的草稿任务组“<Taskgroupname>-Draft”,其中包含已完成的更改。 此草稿任务组可供你在管道中使用。
- 现在,可以直接在测试管道中使用此草稿任务组,而不是发布为预览版。
- 在测试管道中验证此新的草稿任务组,在你确信后,回到主任务组并执行相同的更改并直接保存。 这将被视为次要版本更新。
- 新更改现在将显示在使用此任务组的所有管道中。
- 现在可以删除草稿任务组。
相关主题
帮助和支持
- 浏览故障排除提示。
- 获取有关 Stack Overflow 的建议。
- 在 Azure DevOps 开发人员社区中发布问题、搜索答案或建议功能。
- 获取 Azure DevOps 支持。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈