每晚在调度程序上执行 DevOps 发布管道中的一个阶段
Execute a stage in DevOps Release pipeline every night on scheduler
我在以下设置中有一个 Azure DevOps CI 构建和发布管道：
- CI 在
develop 分支中使用每个新提交构建 运行s 并创建一个 Build Drop（工件）
- 发布管道 运行s 每个新工件并部署到 INT 并最终部署到 PROD（手动批准后）
我想添加一个第 3 阶段（称为 MONITOR），每晚 运行 在 PROD 发布后 使用与 PROD 阶段相同的掉落使用，具有以下架构：
[Build Drop] -> [INT] -> manual approval: [PROD] -> nightly scheduler: [MONITOR]
这对我来说似乎是不可能的，你知道如何实现这个目标吗？
以下内容对我来说很重要：
- MONITOR 和 PROD 运行 总是来自完全相同的工件
- 仅当 PROD 成功时才执行 MONITOR
- 如果有更新的 PROD 版本，则不再执行旧的 MONITOR，而是使用最新的 Artifact 执行最新的 MONITOR
到目前为止，我尝试了以下操作：
- 在提交到 PROD 时将
develop 合并到 master。然后在 MONITOR 阶段使用从 master 开始的计划夜间构建 - 它有效，但 MONITOR 使用与 PROD 不同的工件，所以对我来说不可用
- 在 PROD 之后使用 MONITOR 的计划触发器 - 不起作用，MONITOR 仅在计划时间执行一次，再也不会执行
- 基于特定工件版本创建了额外的发布管道，并带有预定触发器 - 这可行，但我必须在每次成功的 PROD 发布时手动维护特定工件版本。另一个警告是我必须使用 2 个单独的管道，这使得概述不太好。 （但是，到目前为止，我实现的最佳解决方案）
你有更好的想法吗？非常感谢
您是否在使用 YAML 模板，如果是，您是否使用过 cron 计划？ https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled-triggers
如果使用经典版本 UI，我认为您可以让定义触发器按计划进行，但这会使整个定义排队。您可能需要在变量方面发挥创意，也许可以创建 'isScheduled=true' 并使用它来确定是否应该跳过任务。
其他想法：
创建调用 REST API?示例应用程序和 github link 此处：https://oshamrai.wordpress.com/2019/04/22/azure-devops-rest-api-19-queue-builds-and-download-build-results/
Azure-Devops AZ CLI 扩展可能更简单，不过：https://docs.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines/build?view=azure-cli-latest#ext-azure-devops-az-pipelines-build-queue
我会做的是有 2 个独立的发布管道。
这允许您在不生成新工件（计划构建）的情况下安排发布。
然后，我将执行@Soccerjoshj07 建议的一些操作，即我将在 MONITOR pipeline/stage.
上的任务中调用 REST api
我将对 Releases endpoint to get the top=1 releases for releasedefinitionid=x. Then use the Release Environment 端点进行 REST api 调用，以获取该最新版本 ID 的 PROD 环境。有了环境，检查 succeeded 的状态。如果不是，发布失败。
根据评论中概述的新要求进行编辑
给定 PROD.1 成功 并且 PROD.2 失败 当 MONITOR 被触发时，那么来自 PROD.1 的工件应该用于 MONITOR.
根据这个标准，我会改变一些东西。与其让 MONITOR 去挖掘最新的 PROD 版本，如果最新版本失败则失败，我会将 successful PROD 阶段标记为构建工件并且在 Monitor 管道上使用 artifact filters。
标记可以通过 REST api or using the Tag Build or Release Task from Colin's ALM Corner Build & Release Tools 进行，可能如下所示：
除了设置两个发布管道外，如果你只想对一个阶段使用预定触发器，恐怕没有这种开箱即用的方法来实现，预定触发器只适用于整个管道。
作为解决方法，您可以为 MONITOR 阶段的作业添加 custom condition。
例如在 yaml 中：
- stage: MONITOR
jobs:
- job:
condition: and(always(), eq(variables['Release.Reason'], 'Schedule'))
steps:
在 UI 中，您可以在代理作业的 Run this job 中设置：
在这种情况下，该阶段仅在计划触发器触发释放时执行。如果由于其他原因触发发布，将跳过MONITOR阶段。
此解决方法的局限性在于，当您的管道被计划的触发器触发时，还会执行其他两个阶段。
或者用powershell任务写一个脚本（分INT/PROD个阶段）判断Release.Reason是否是Schedule。如果是，则跳过当前阶段。
如何获取PROD的最新神器版本和判断PROD的部署状态，可以参考上面两个回答
我在以下设置中有一个 Azure DevOps CI 构建和发布管道：
- CI 在
develop分支中使用每个新提交构建 运行s 并创建一个 Build Drop（工件） - 发布管道 运行s 每个新工件并部署到 INT 并最终部署到 PROD（手动批准后）
我想添加一个第 3 阶段（称为 MONITOR），每晚 运行 在 PROD 发布后 使用与 PROD 阶段相同的掉落使用，具有以下架构：
[Build Drop] -> [INT] -> manual approval: [PROD] -> nightly scheduler: [MONITOR]
这对我来说似乎是不可能的，你知道如何实现这个目标吗？
以下内容对我来说很重要：
- MONITOR 和 PROD 运行 总是来自完全相同的工件
- 仅当 PROD 成功时才执行 MONITOR
- 如果有更新的 PROD 版本，则不再执行旧的 MONITOR，而是使用最新的 Artifact 执行最新的 MONITOR
到目前为止，我尝试了以下操作：
- 在提交到 PROD 时将
develop合并到master。然后在 MONITOR 阶段使用从master开始的计划夜间构建 - 它有效，但 MONITOR 使用与 PROD 不同的工件，所以对我来说不可用 - 在 PROD 之后使用 MONITOR 的计划触发器 - 不起作用，MONITOR 仅在计划时间执行一次，再也不会执行
- 基于特定工件版本创建了额外的发布管道，并带有预定触发器 - 这可行，但我必须在每次成功的 PROD 发布时手动维护特定工件版本。另一个警告是我必须使用 2 个单独的管道，这使得概述不太好。 （但是，到目前为止，我实现的最佳解决方案）
你有更好的想法吗？非常感谢
您是否在使用 YAML 模板，如果是，您是否使用过 cron 计划？ https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled-triggers
如果使用经典版本 UI，我认为您可以让定义触发器按计划进行，但这会使整个定义排队。您可能需要在变量方面发挥创意，也许可以创建 'isScheduled=true' 并使用它来确定是否应该跳过任务。
其他想法： 创建调用 REST API?示例应用程序和 github link 此处：https://oshamrai.wordpress.com/2019/04/22/azure-devops-rest-api-19-queue-builds-and-download-build-results/
Azure-Devops AZ CLI 扩展可能更简单，不过：https://docs.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines/build?view=azure-cli-latest#ext-azure-devops-az-pipelines-build-queue
我会做的是有 2 个独立的发布管道。
这允许您在不生成新工件（计划构建）的情况下安排发布。
然后，我将执行@Soccerjoshj07 建议的一些操作，即我将在 MONITOR pipeline/stage.
上的任务中调用 REST api我将对 Releases endpoint to get the top=1 releases for releasedefinitionid=x. Then use the Release Environment 端点进行 REST api 调用，以获取该最新版本 ID 的 PROD 环境。有了环境，检查 succeeded 的状态。如果不是，发布失败。
根据评论中概述的新要求进行编辑
给定 PROD.1 成功 并且 PROD.2 失败 当 MONITOR 被触发时，那么来自 PROD.1 的工件应该用于 MONITOR.
根据这个标准，我会改变一些东西。与其让 MONITOR 去挖掘最新的 PROD 版本，如果最新版本失败则失败，我会将 successful PROD 阶段标记为构建工件并且在 Monitor 管道上使用 artifact filters。
标记可以通过 REST api or using the Tag Build or Release Task from Colin's ALM Corner Build & Release Tools 进行，可能如下所示：
除了设置两个发布管道外，如果你只想对一个阶段使用预定触发器，恐怕没有这种开箱即用的方法来实现，预定触发器只适用于整个管道。
作为解决方法，您可以为 MONITOR 阶段的作业添加 custom condition。
例如在 yaml 中：
- stage: MONITOR
jobs:
- job:
condition: and(always(), eq(variables['Release.Reason'], 'Schedule'))
steps:
在 UI 中，您可以在代理作业的 Run this job 中设置：
在这种情况下，该阶段仅在计划触发器触发释放时执行。如果由于其他原因触发发布，将跳过MONITOR阶段。
此解决方法的局限性在于，当您的管道被计划的触发器触发时，还会执行其他两个阶段。
或者用powershell任务写一个脚本（分INT/PROD个阶段）判断Release.Reason是否是Schedule。如果是，则跳过当前阶段。
如何获取PROD的最新神器版本和判断PROD的部署状态，可以参考上面两个回答