How to migrate multi-step deployment stages in Pipelines to use environment and concurrency-group?

Stefan Fußenegger

Is there an easy guide to migrate existing multi-step deployment stages to the new environment and concurrency-group properties? I'm especially looking at getting automatic resume of paused builds (= deployments). In the article Evolving deployments in Bitbucket Pipelines: Concurrency Groups and Environments there is this explanation:

Today, you still do need to use the <span>deployment</span> keyword in order to get deployment tracking for your pipeline. In order to get the benefit of automated step queueing AND deployment tracking at the same time, simply add both a deployment and a concurrency-group property to your step.

The <span>concurrency</span><span>-</span><span>group</span> logic will take precedent over the deployment lock, providing automated queueing and resumption of steps when multiple run at the same time targeting the same <span>concurrency</span><span>-</span><span>group</span>.

But what about existing deployment stages with multiple steps? Can I simply move the steps out of the stage and steps with the same deployment and concurrency-group values will be treated the same as a stage? Meaning consecutive steps will be completed before another pipeline can access the step? Or could a second concurrent pipeline build run step 1 right after a first pipeline finished step 1 but before it can complete step 2. So assuming pipelines #1 and #2 running 2 steps each, say deploy and test, could it be that the order of execution is

1. #1 deploy
2. #2 deploy
3. #1 test
4. #2 test

or will it always be

1. #1 deploy
2. #1 test
3. #2 deploy
4. #2 test

obviously the latter is what I'd be looking for

Theodora Boudale

Hi Stefan,

The concurrency-group property is not supported in stages at the moment. I can create a feature request for that if you'd like, please feel free to let me know.

Let's assume a deployment stage with two steps. If you take these two steps out of the stage, you won't be able to use the deployment keyword in both steps. A workaround would be to use the environment keyword along with concurrency-group. Any environment variables will be available to both steps because of the environment keyword. Please keep in mind though that you won't be able to track deployments in the Deployments page of the repo (I mean from the Deployments option on the left sidebar, while viewing a repo on Bitbucket's website).

A sample yml for this would be the following:

image: atlassian/default-image:5

pipelines:
  default:
    - step:
        name: 1st Step
        environment: Staging
        concurrency-group: build-group
        script:
          - echo "This is step 1"
    - step:
        name: 2nd Step
        environment: Staging
        concurrency-group: build-group
        script:
          - echo "This is step 2"

With regards to the order the steps are executed with the concurrency-group, Pipelines follows a first-in-first-out order based on the order the steps start running. If we assume a yml file like the one I shared above, let's say you trigger Pipeline 1.

• The 1st Step of Pipeline 1 is running. The 2nd Step hasn't started running yet, so it is not in this queue.
• You trigger Pipeline 2 (while 1st Step of Pipeline 1 is running). The 1st Step of Pipeline 2 will be the first one in the queue waiting, because it tries to start running before the 2nd Step of Pipeline 1. So, it will run as soon as the 1st Step of Pipeline 1 finishes.
• Then, the 2nd Step of Pipeline 1 will follow.

Please feel free to let me know if you have any questions.

Kind regards,
Theodora