Bitbucket Pipelines neu gedacht: So helfen Trigger beim Skalieren Ihrer CI/CD-Workflows

Unübersichtliche YAML-Dateien, lange Feedback-Zyklen und starre Strukturen machen es schwer, flexibel auf neue Anforderungen zu reagieren.

Atlassian hat dieses Problem erkannt – und die Struktur von Workflows in Bitbucket Pipelines grundlegend überarbeitet. Im Zentrum steht eine neue Funktion: Triggers.

Als Atlassian-Partner zeigen wir in diesem Artikel, was es mit dem neuen Trigger-Modell auf sich hat, welche Vorteile es für Entwicklerteams bringt und wie Sie sofort von mehr Modularität und Transparenz profitieren können.

1. Was sind „Triggers“ in Bitbucket Pipelines?

Mit Triggers können Sie Pipelines nicht mehr nur auf klassische Selektoren wie Branch-Namen oder Pull-Requests begrenzen. Stattdessen definieren Sie ereignisgesteuerte Regeln, die bei bestimmten Aktionen (z. B. Push oder Pull-Request-Update) geprüft werden. Wenn definierte Bedingungen erfüllt sind, werden alle zugeordneten Pipelines parallel ausgeführt.

Das ermöglicht:

• eine klare Trennung zwischen Definition und Ausführung von Pipelines,
• die Automatisierung auf Basis von Events und Bedingungen,
• parallele Ausführung beliebig vieler Pipelines pro Ereignis.
  
  

2. Die neuen Komponenten: triggers, condition und glob()

Die neue Struktur basiert auf einem obersten triggers-Block in der Datei bitbucket-pipelines.yml. Innerhalb jedes Triggers können Sie eine oder mehrere Bedingungen (condition) definieren. Wird eine Bedingung bei einem Event erfüllt, werden alle referenzierten custom pipelines gleichzeitig ausgeführt.

Besonders leistungsfähig wird das durch:

• logische Operatoren wie &&, ||, (), ==, != etc.
• Musterabgleich mit glob() (z. B. feature/*, hotfix/*)
• kombinierbare Regeln, um spezifische Abläufe zu definieren.
  
  

3. Beispiel: So funktioniert ein Trigger-gesteuerter Workflow

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

Jede Bedingung prüft Variablen wie Branch-Namen oder Ziel-Branch bei Pull Requests. Stimmen die Kriterien, werden die angegebenen Pipelines gestartet – nicht nur eine, sondern alle zutreffenden.

4. Wichtige Unterschiede zum bisherigen Modell

5. Vorteile: Skalierbare, modulare CI/CD-Prozesse

Das neue Trigger-Modell bietet mehrere konkrete Vorteile:

 Modularisierung großer Pipelines: Statt monolithischer Abläufe lassen sich kleinere, spezialisierte Pipelines definieren.
 Klare Trennung von Logik und Ausführung: Mehr Übersicht, leichter wartbar.
 Verbesserte Beobachtbarkeit: Jede Pipeline erhält einen eigenen Build-Status.
 Mehr Flexibilität für Pull-Requests: Triggern nach Ziel-Branch ist jetzt möglich.

6. Jetzt umstellen: So starten Sie mit dem neuen Workflow

Die gute Nachricht: Sie können direkt loslegen – ohne das bisherige Modell abschalten zu müssen. Beide Systeme funktionieren parallel. Es empfiehlt sich jedoch, schrittweise auf das neue Trigger-Modell umzusteigen, um langfristig von den Vorteilen zu profitieren.

Wichtig zu wissen:

• Nur Pipelines aus dem custom-Bereich dürfen in Triggers referenziert werden.
• Maximal 20 Bedingungen pro Trigger-Typ
• Maximal 100 auszuführende Pipelines pro Trigger
• Triggers werden auch in Dynamic Pipelines unterstützt
• Weitere Trigger-Typen sind geplant (z. B. für erweitertes SDLC-Automatisierung)
  
  

Jetzt starten: Lassen Sie sich zum Trigger-Modell beraten

Sie möchten mehr über den neuen Trigger-Workflow erfahren? Als Atlassian-Partner stehen wir Ihnen gerne beratend zur Seite.

KONTAKTIEREN!