Bitbucket Pipelines是否支持手动选择集成环境部署功能

你之前了解的「仅支持向固定递进顺序的环境执行部署」是平台默认提供的部署晋升轨道的特性，并非全部配置能力，通过组合平台自带的自定义流水线、参数变量、手动触发步骤能力，就可以实现需求，具体配置逻辑如下：

• 入口使用custom类型的自定义流水线，这类流水线不会随代码推送自动触发，仅支持开发者在Bitbucket界面手动点击启动。你可以为这类流水线配置下拉选择类型的自定义变量，把savanna、desert、jungle三个集成环境设为可选值，开发者触发流水线时就可以看到环境选择项。
• 如果你需要先跑完通用初始步骤再暂停等待选择，可以把流水线拆成三个阶段：
  • 第一阶段自动执行和环境无关的通用流程：包括依赖安装、代码校验、单元测试、构建打包，构建完成的产物通过artifacts配置传递给后续步骤
  • 第二阶段配置为手动触发的确认步骤，初始阶段跑完后流水线会自动暂停，在界面提示开发者确认目标环境，开发者点击确认后才会往下执行
  • 第三阶段为部署步骤，通过条件判断匹配开发者选中的环境变量值，仅执行对应环境的部署逻辑，不会触发其他环境的操作
• 不需要受默认部署递进规则限制：默认的测试→预发→生产递进规则只是官方提供的通用最佳实践模板，你可以在仓库设置里把三个集成环境添加为平级的独立部署环境，不需要配置递进晋升关系，每个环境单独存储独立的访问密钥、服务地址等环境变量，不同开发者的部署操作完全隔离，不会互相干扰。

下面是最小可用的配置示例，你可以直接基于这个调整：

pipelines:
  custom:
    集成环境手动部署:
      - variables:
          - name: TARGET_ENV
            default: savanna
            allowed-values:
              - savanna
              - desert
              - jungle
            description: 选择目标部署集成环境
      - step:
          name: 通用构建与检查
          script:
            - echo "安装依赖、执行单元测试、构建部署产物"
          artifacts:
            - build/**
      - step:
          name: 确认部署
          trigger: manual
          script:
            - echo "已确认目标部署环境：$TARGET_ENV"
      - step:
          name: 执行部署
          deployment: $TARGET_ENV
          script:
            - echo "开始向$TARGET_ENV环境部署"
            # 此处替换为实际部署逻辑，根据变量匹配对应环境的部署命令
            - case $TARGET_ENV in
                savanna) echo "执行savanna环境部署操作" ;;
                desert) echo "执行desert环境部署操作" ;;
                jungle) echo "执行jungle环境部署操作" ;;
              esac

补充说明：你可以在仓库的Repository settings → Deployments 页面分别添加三个同名的集成环境，给每个环境配置独立的权限规则，比如限制只有对应模块的开发人员可以部署到特定环境，进一步避免误操作。

内容的提问来源于stack exchange，提问作者Kirk Sefchik