Azure经典发布Pipeline回滚配置：分阶段回滚与代码重拉取需求

一、让stage3仅在stage1失败时触发 #

主流CI/CD工具都支持按前序阶段的执行状态控制后续阶段是否运行，直接给stage3配置触发规则即可：

• 以GitLab CI为例，配置文件写法如下：

stages:
  - stage1
  - stage2
  - stage3

stage1:
  stage: stage1
  script:
    - # 此处编写stage1的部署命令

stage2:
  stage: stage2
  script:
    - # 此处编写stage2的部署命令
  only:
    - stages: [stage1]
    - status: success

stage3:
  stage: stage3
  script:
    - # 此处编写stage1的回滚命令
  only:
    - stages: [stage1]
    - status: failed

核心逻辑是给stage3绑定「仅当stage1执行失败」的触发条件，其他工具比如Jenkins可通过「Post-build Actions」里的「Run only if build fails」选项实现，原理都是基于前序阶段的执行状态判断。

二、同一阶段内重新拉取代码解决回滚找不到值的问题 #

如果不想单独增加回滚阶段，要在stage1内直接处理失败回滚，可在脚本中添加条件判断，失败时先重新拉取代码再执行回滚：

• 示例脚本：

# 执行stage1部署操作
if ! ./deploy-stage1.sh; then
  # 部署失败，强制拉取远程最新代码
  git fetch --all
  git reset --hard origin/${CI_COMMIT_BRANCH}
  # 执行回滚操作
  ./rollback-stage1.sh
  exit 1 # 保持阶段失败状态
fi

通过强制拉取远程代码并重置到分支最新状态，能确保回滚时使用的是完整、正确的代码库文件，避免因部署过程中修改文件导致找不到对应值的问题。

三、stage2失败时的回滚处理 #

和上述逻辑一致，可选择两种方式实现：

• 单独阶段方式（GitLab CI示例）：

stage4:
  stage: stage4
  script:
    - # 此处编写stage2的回滚命令
  only:
    - stages: [stage2]
    - status: failed

• 脚本内嵌方式：

if ! ./deploy-stage2.sh; then
  git fetch --all
  git reset --hard origin/${CI_COMMIT_BRANCH}
  ./rollback-stage2.sh
  exit 1
fi

内容的提问来源于stack exchange，提问作者Marccelus Enoh