Bitbucket pipelines rethought: How triggers help you scale your CI/CD workflows

Confusing YAML files, long feedback cycles and rigid structures make it difficult to react flexibly to new requirements.

Atlassian has recognized this problem - and has fundamentally revised the structure of workflows in Bitbucket Pipelines. At the center of this is a new function: Triggers.

As an Atlassian partner, we show in this article what the new trigger model is all about, what advantages it brings for development teams and how you can immediately benefit from more modularity and transparency.

1. What are "triggers" in Bitbucket Pipelines?

With triggers, you can no longer limit pipelines to classic selectors such as branch names or pull requests. Instead, you define event-driven rules that are checked for certain actions (e.g. push or pull request update). If defined conditions are met, all assigned pipelines are executed in parallel.

This enables

• a clear separation between the definition and execution of pipelines,
• automation based on events and conditions,
• parallel execution of any number of pipelines per event.
  
  

2. The new components: triggers, condition and glob()

The new structure is based on a top-level triggers block in the bitbucket-pipelines.yml file. Within each trigger, you can define one or more conditions. If a condition is fulfilled for an event, all referenced custom pipelines are executed simultaneously.

This is made particularly powerful by

• logical operators such as &&, ||, (), ==, != etc.
• pattern matching with glob() (e.g. feature/*, hotfix/*)
• combinable rules to define specific sequences.
  
  

3. Example: This is how a trigger-controlled workflow works

triggers:

repository-push:

- condition: BITBUCKET_BRANCH == "main"

pipelines:

- unit-tests

- scan

- deploy

pullrequest-push:

- condition: glob(BITBUCKET_BRANCH, "feature/*") && BITBUCKET_PR_DESTINATION_BRANCH == "main"

pipelines:

- unit-tests

- lint

- condition: glob(BITBUCKET_BRANCH, "hotfix/*")

pipelines:

- unit-tests

Each condition checks variables such as branch names or target branches for pull requests. If the criteria are met, the specified pipelines are started - not just one, but all that apply.

4. Important differences to the previous model

5. Advantages: scalable, modular CI/CD processes

The new trigger model offers several concrete advantages:

Modularization of large pipelines: instead of monolithic processes, smaller, specialized pipelines can be defined.
Clear separation of logic and execution: better overview, easier to maintain.
Improved observability: each pipeline has its own build status.
More flexibility for pull requests: triggering by target branch is now possible.

6. Switch now: How to get started with the new workflow

The good news is that you can get started straight away - without having to switch off the previous model. Both systems work in parallel. However, it is advisable to switch to the new trigger model gradually in order to benefit from the advantages in the long term.

Important to know:

• Only pipelines from the custom area may be referenced in triggers.
• Maximum of 20 conditions per trigger type
• Maximum of 100 pipelines to be executed per trigger
• Triggers are also supported in Dynamic Pipelines
• Further trigger types are planned (e.g. for extended SDLC automation)
  
  

Start now: Get advice on the trigger model

Would you like to find out more about the new trigger workflow? As an Atlassian partner, we will be happy to advise you.

CONTACT US!