Evolving deployments in Bitbucket Pipelines: Concurrency Groups and Environments
We’re excited to announce that Bitbucket Cloud is introducing two powerful new features in Bitbucket Pipelines: Concurrency Groups and Environments. These enhancements are part of a broader initiative to make the Deployments functionality more flexible and user-friendly by breaking down its current monolithic structure into smaller, more granular capabilities that you can control directly.
Background
Deployments in Bitbucket Pipelines have often been seen as rigid, requiring users to adopt features like locks and the deployment dashboard even when only specific aspects, such as environment variables or permissions controls, were needed. Over the years, your feedback has guided us toward a more modular approach. The introduction of Concurrency Groups and Environments marks the first step in this transformation, offering greater flexibility while preserving the core functionality of Deployments. In the future, we plan to further decompose Deployments into additional granular features, eventually redefining the deployment keyword as a shorthand for configuring these capabilities in a predefined way, ensuring backward compatibility and enhanced control.
Introducing the New Features
- Environments: This feature decouples environment variables and permissions controls from the full Deployments framework. By using the new environment keyword in your
bitbucket-pipelines.yml, you can access environment-specific variables and apply admin or branch restrictions without enforcing deployment locks or other deployment-related features. This allows multiple steps to run concurrently, all leveraging the same environment settings. - Concurrency Groups: Replacing the restrictive deployment locks, Concurrency Groups provide a simpler, more powerful way to manage step concurrency. Defined using the concurrency-group keyword, these groups ensure that steps sharing the same group execute one at a time in a first-in-first-out order, with queued steps automatically resuming as slots become available. At launch, each group supports a single-file queue with a concurrency limit of one, but we plan to introduce more configurability, such as higher limits and a
fast-forwardqueueing strategy, based on your feedback.
These features are designed to complement, not replace, Deployments, giving you the freedom to use only the components you need. They also lay the groundwork for automating processes like resuming halted deployments, boosting your team’s productivity.
Usage: Concurrency Groups
Concurrency Groups allow you to restrict the concurrency of a step. When you assign steps to the same concurrency group, Bitbucket Pipelines ensures that only one step in that group runs at a time, following a first-in-first-out order. Groups are dynamic and don’t require prior configuration—they act as a key to associate and manage step concurrency across your repository, even across different pipelines.
Example Configuration
pipelines:
default:
- step:
name: Build
concurrency-group: build-group
script:
- echo "Building the application"In this example, any step assigned to build-group will wait for other steps in the same group to complete before starting. If multiple steps reference the same group, they’ll queue automatically, and Pipelines will execute the next step as soon as a slot opens.
How this is represented in the UI
A step will be in a Waiting to run status until its turn to run comes up, at which point it will automatically be put back into a blue, In progress status.
A pipeline can also be in the Waiting to run status.
Using Concurrency groups with deployment tracking
In the future, an explicit keyword will be introduced to Pipelines to allow individual steps to be tracked on the Deployment Dashboard independent of any other deployments functionality.
Today, you still do need to use the deployment 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 concurrency-group 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 concurrency-group.
Usage: Environments
The new environment keyword lets you apply environment-specific settings to a step without requiring a full Deployment. Environments can be configured with:
- Variables: Load environment-specific variables into the step.
- Admin permissions checks: Restrict steps to admin users only.
- Branch restrictions: Limit steps to specific branches.
Unlike Deployments, Environments can be reused across multiple steps in a parallel group, offering greater flexibility. Configuration remains unchanged, managed through the existing Deployments settings screen.
Example Configuration
pipelines:
default:
- step:
name: "Run step in production environment"
environment: production
script:
- echo "Your script goes here"What’s next?
Concurrency Groups and Environments are just the beginning. We’re actively working on additional enhancements to decompose Deployments further, giving you even more control over your pipelines. Future updates may include configurable concurrency limits and advanced queueing strategies for Concurrency Groups. We’re also planning to evolve the deployment keyword into a flexible shorthand that combines these granular features, ensuring a seamless transition for existing setups.
For more information on Deployments, see Set up and monitor deployments | Bitbucket Cloud | Atlassian Support.
We can’t wait to see how you leverage these new features to streamline your workflows! Let us know your feedback as we continue to refine and expand Bitbucket Pipelines.