Ausführen von Feature Branches mit Bitbucket Pipelines

Erfahre, wie Continuous Delivery in einem Gitflow- oder Feature-Branch-Workflow gelingt. 

Sten Pittet Sten Pittet

Egal, ob du Gitflow verwendest oder einfach Feature-Branches mit einem Main-Branch: Mit Bitbucket Pipelines kannst du problemlos Continuous Delivery (CD) einsetzen. Du musst keine komplexen Continuous-Integration-Server konfigurieren, sondern nur Pipelines aktivieren und deine Workflows so definieren, dass Tests und Deployments auf deinen Branches ausgeführt werden können.

Bitbucket Pipelines

In diesem Tutorial lernst du, wie du Bitbucket Pipelines so konfigurieren kannst, dass unterschiedliche Pipelines auf unterschiedlichen Branches ausgeführt werden können. Außerdem erfährst du, wie du deine Branches vor schlechten Merges schützen kannst.

Schritt 1: Eine Standard-Pipeline erstellen, die auf den Feature Branches ausgeführt werden soll

Feature-Branches sind eine gute Methode, um zu vermeiden, dass es beim Main häufig zu Fehlern kommt. Entwickler können in einem separaten Branch an spezifischen Verbesserungen arbeiten und ihre Änderungen mergen, wenn der Build grün ist. Trotzdem musst du auch die Stabilität deiner Feature-Branches im Blick behalten. Damit alle gut zusammenarbeiten können, sollten deine Feature-Branches über einen grünen Status verfügen. Mit Feature-Branches kannst du leichter nachvollziehen, welche Änderungen vorgenommen wurden, um ein spezifisches Problem zu beheben. Dies sollte aber nicht zu Verzögerungen bei der Qualität führen.

Das Erste, was wir bei der Aktivierung von Bitbucket Pipelines tun sollten, ist die Erstellung einer Standard-Pipeline, die Tests für jeden Branch ausführen soll. Hierfür können die Standard-Vorlagen verwendet werden.

Konfiguration einer JavaScript-Standard-Pipeline

Alle sprachspezifischen Vorlagen verwenden eine Standard-Pipeline unter dem Standardschlüsselwort, die für jeden neuen Branch ausgeführt wird. Du kannst die Konfigurationsdatei bitbucket-pipelines.yml einfach in dein Repository committen, damit deine erste Pipeline auf dem Main-Branch ausgeführt wird.

Unsere erste für den Master Branch ausgeführte Pipeline

Du kannst einfach einen neuen Branch mit Änderungen pushen, um zu überprüfen, ob dieselbe Pipeline auf einem anderen Branch ausgeführt wird.

Schritt 2: Eine neue Pipeline für den Main-Branch hinzufügen

Wenn du Continuous Delivery nutzt, sollten die an den Main übermittelten Änderungen bestenfalls automatisch in einer Staging-Umgebung bereitgestellt werden. Um dies zu erreichen, fügen wir eine neue Branch-Pipeline hinzu, durch die der Code nach dem Durchführen der Tests bereitgestellt wird und die nur für den Main ausgeführt wird.

image: node:4.6.0
   pipelines:
   default:
     - step:
         script:
           - npm install
           - npm test
   branches:
     main:
       - step:
           script:
             - npm install
             - npm test
             - ./deploy.sh  

Im Abschnitt Branches in der obigen YML-Konfiguration legen wir die Pipeline fest, die ausgeführt werden soll, wenn Änderungen per Push an den Main übertragen werden.

Ab jetzt löst der Push an den Main ein Deployment aus, nachdem die Anwendung erstellt und getestet wurde. Jeder weitere Branch des Repositorys erstellt und testet dann einfach die neuen Änderungen.

Schritt 3: Deine Release Branches schützen

Nach Abschluss von Schritt 2 kann jeder Entwickler einen Release an die Produktionsumgebung auslösen, indem er seine Änderungen an den Main mergt. Dies ist riskant, da Änderungen bereitgestellt werden könnten, die noch nicht geprüft wurden. Du kannst dies jedoch leicht verhindern, indem du deinen Branches in Bitbucket Berechtigungen hinzufügst.

Gehe in deinem Repository zu "Settings" > "Branch permissions" (Einstellungen > Branch-Berechtigungen).

Branch-Berechtigungen

Füge eine neue Branch-Berechtigung für den Main hinzu. Lass dabei Write access (Schreibzugriff) leer, damit Entwickler keinen direkten Push zum Main durchführen können. Füge dich dann selbst der Berechtigung Merge via pull request (Merge per Pull-Anfrage) hinzu.

Branch-Berechtigung hinzufügen

Bevor wir die neue Branch-Berechtigung speichern, fügen wir einen Merge-Check hinzu, um sicherzustellen, dass die Durchführung von Merges nur zulässig ist, wenn mindestens ein grüner Build vorhanden ist. Erweitere einfach den Abschnitt mit den Merge-Checks, um die entsprechende Funktion zu aktivieren.

Branch-Berechtigung hinzufügen

Nach dem Speichern kannst du überprüfen, ob der Branch ordnungsgemäß geschützt ist. Kein Benutzer und keine Gruppe sollte Schreibzugriff haben und deine vertrauenswürdigen Teammitglieder sollten per Pull-Anfrage Merges durchführen können.

Schritt 4: Pull-Anfragen verwenden, um Produktionsänderungen vorzuschlagen

Da ein direkter Push zum Main nicht mehr möglich ist, musst du zum Bereitstellen in die Produktion auf Pull-Anfragen zurückgreifen. Nachdem die Pull-Anfrage erstellt wurde, musst du die Änderungen nur noch mit dem Main zusammenführen, um die Deployment-Pipeline auszulösen.

Bitbucket-Pull-Request

Nach dem Merge kannst du in deinem Repository den Abschnitt "Pipelines" aufrufen, um das Deployment in Aktion zu sehen.

Bitbucket Pipelines-Protokolle

Wir haben die Grundlagen der Ausführung von Feature Branches mit Bitbucket Pipelines behandelt. Du kannst dieses Beispiel auf deine eigenen Anforderungen anpassen und eine eigene Continuous-Delivery-Pipeline erstellen. In unseren Leitfäden zu Continuous Delivery und Continuous Deployment findest du weiterführende Informationen.