【问题标题】:How to combine continuous deployment and testing with scheduled testing of latest release如何将持续部署和测试与最新版本的预定测试相结合
【发布时间】:2019-04-08 14:31:26
【问题描述】:

鉴于以下发布管道:

当前逻辑:

  • 阶段“部署到开发”部署到第一个环境。
    • 构建成功后立即运行。
    • 技术细节:部署到 IIS。
  • 阶段“回归测试”在该已安装环境上运行测试。
    • 在前一阶段成功后运行。
    • 技术细节:使用 newman 运行 postman 测试。

问题:

  • 除了当前的逻辑,我还希望每天运行回归测试阶段。
  • 不应创建新构建,不重复“部署到开发”阶段,只运行“回归测试”阶段。

这可以在不单独重建舞台的情况下完成吗?

【问题讨论】:

  • 那么这就像上次构建的“回归测试”阶段的计划重新部署?
  • 是的,听起来很正确。

标签: azure-devops azure-pipelines azure-pipelines-release-pipeline


【解决方案1】:

是的,您需要做的就是为您的“回归测试”阶段启用计划部署前触发器。这似乎不是很明显,但这将使用最新版本的构建工件按计划运行。不会触发新的构建。

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops#stage-scheduled-triggers

当您选择此选项时,您可以选择星期几和 Azure Pipelines 将在一天中自动启动新管道的时间 部署。与计划发布触发器不同,您无法配置 阶段触发器的多个时间表。请注意,与预定 触发器,创建一个新的部署,从 最近可用的版本,覆盖以前的任何版本 为舞台部署的工件。它不一定需要一个 更新版本的工件可用

通过结合 After Stage 和 Schedule 触发器,“Regression Tests”阶段将在“Deploy to Dev”成功后执行,然后再次执行 在您指定的时间表上。请注意,如果您的部署失败,这不会阻止计划的触发器发生,因此您需要确保在夜间运行之前成功“部署到开发”。

从上面的引用中,您会注意到使用了“新部署”一词,根据您当前的使用情况,这可能看起来令人困惑。术语“阶段”以前称为“环境”,它包含的任务被视为“部署”。由于您的回归测试实际上并没有部署任何东西,它只会运行测试。

【讨论】:

  • 我已经配置了这个,但它似乎没有触发。但是,我可能首先必须触发整个管道(通过构建),以便使用新的管道版本。将对此进行测试。
  • 是的,因为您只修改了发布定义。您必须创建一个启用了这些设置的版本才能生效。
猜你喜欢
  • 2018-09-02
  • 1970-01-01
  • 1970-01-01
  • 2015-11-26
  • 1970-01-01
  • 2021-03-29
  • 2021-12-21
  • 1970-01-01
相关资源
最近更新 更多