如何使用不同分支的不同环境变量运行相同的Bitbucket管道?

发布于 2025-02-09 11:02:48 字数 429 浏览 1 评论 0原文

我有一个部署到3个环境的MonorePo项目 - 测试,分期和生产。部署到测试来自下一个分支,而Master分支的登台和生产。测试部署应在下一步的每个提交上自动运行(但是我也可以手动触发它们),但是应手动触发主分支的部署。此外,每个部署都可以由客户端推送和服务器推动(取决于更改的文件)。部署到每个主机的命令完全相同,唯一更改的是主机本身和环境变量。

因此,我有2个问题:

  1. 当我手动触发管道时,我可以提示我提示我部署目标,从而使我选择ENV变量的集合以注入命令的设置顺序?我在一个教程中看到了此屏幕截图,但是从那以后我找不到它,找不到它。
  2. 我可以有平行的命令序列吗?我希望服务器和客户端同时推动运行,但是它们俩都有不同的步骤。还是我需要将它们与多个脚本合并到同一步骤中,以实现这一目标?

感谢您的帮助。

I have a monorepo project that is deployed to 3 environments - testing, staging and production. Deploys to testing come from the next branch, while staging and production from the master branch. Testing deploys should run automatically on every commit to next (but I'm also fine with having to trigger them manually), but deploys from the master branch should be triggered manually. In addition, every deploy may consist of a client push and server push (depending on the files changed). The commands to deploy to each of the hosts are exactly the same, the only thing changing is the host itself and the environment variables.

Therefore I have 2 questions:

  1. Can I make Bitbucket prompt me the deployment target when I manually trigger the pipeline, thus basically letting me choose the set of the env variables to inject into the set sequence of commands? I've seen a screenshot for this in a tutorial, but I lost it and can't find it since.
  2. Can I have parallel sequences of commands? I'd like the server and the client push to run simultaneously, but both of them have different steps. Or do I need to merge those into the same step with multiple scripts to achieve that?

Thank you for your help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

葬シ愛 2025-02-16 11:02:48

您两个问题的答案是“是”。

  1. 使其成为可能的功能称为custom管道。 在这里是一个整洁的文档,展示了如何使用它们。 /p>

  2. 有一个并行关键字,您可以用来定义并行步骤。查看 this doc 详细信息。

如果我不误解您的设置描述,那么您的最终管道看起来应该非常相似:

pipelines:
  custom:
    deploy-to-staging-or-prod: # As you say the steps are the same, only variable values will define the destination.
       - variables:            # List variable names under here, and Bitbucket will prompt you to supply their values.
          - name: VAR1
          - name: VAR2
       - parallel:
          - step:
              - ./deploy-client.sh 
          - step:
              - ./deploy-server.sh 

  branches:
    next:
      - step:
          script:
            - ./deploy-to-testing.sh

upd

如果您需要使用部署而不是单独提供每个变量,则使用可以使用手册触发类型:

definitions:
  steps:
    - step: &RunTests
        script:
          - ./run-tests.sh
    - step: &DeployFromMaster
        script:
          - ./deploy-from-master.sh

pipelines:
  branches:
    next:
      - step:
          script:
            - ./deploy-to-testing.sh
    master:
      - step: *RunTests
      - parallel:
        - step:
            <<: *DeployFromMaster
            deployment: staging
            trigger: manual
        - step:
            <<: *DeployFromMaster
            deployment: production
            trigger: manual

理解此管道的关键文档仍然一个 and 这个 yaml锚点。请记住,我故意介绍了“跑步”步骤

由于在提交上触发管道,因此您无法制作第一步手册。

它将充当部署步骤的阻止者,这只能由于您的要求而是手动。

The answer to both of your questions is 'Yes'.

  1. The feature that makes it possible is called custom pipelines. Here is a neat doc that demonstrates how to use them.

  2. There is a parallel keyword which you can use to define parallel steps. Check out this doc for details.

If I'm not misinterpreting the description of your setup, your final pipeline should look very similar to this:

pipelines:
  custom:
    deploy-to-staging-or-prod: # As you say the steps are the same, only variable values will define the destination.
       - variables:            # List variable names under here, and Bitbucket will prompt you to supply their values.
          - name: VAR1
          - name: VAR2
       - parallel:
          - step:
              - ./deploy-client.sh 
          - step:
              - ./deploy-server.sh 

  branches:
    next:
      - step:
          script:
            - ./deploy-to-testing.sh

UPD

If you need to use Deployments instead of providing each variable separately, use can utilise manual type of trigger:

definitions:
  steps:
    - step: &RunTests
        script:
          - ./run-tests.sh
    - step: &DeployFromMaster
        script:
          - ./deploy-from-master.sh

pipelines:
  branches:
    next:
      - step:
          script:
            - ./deploy-to-testing.sh
    master:
      - step: *RunTests
      - parallel:
        - step:
            <<: *DeployFromMaster
            deployment: staging
            trigger: manual
        - step:
            <<: *DeployFromMaster
            deployment: production
            trigger: manual

Key docs for understanding this pipeline is still this one and this one for yaml anchors. Keep in mind that I introduced a 'RunTests' step on purpose, as

Since a pipeline is triggered on a commit, you can't make the first step manual.

It will act as a stopper for the deploy step which can only be manual due to your requirements.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文