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 Master-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 Pipeline

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 Master 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 Master-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 Master-Branch hinzufügen

Wenn du Continuous Delivery nutzt, wirst du wahrscheinlich wollen, dass die an den Master übermittelten Änderungen 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 Master ausgeführt wird.

image: node:4.6.0
   pipelines:
   default:
     - step:
         script:
           - npm install
           - npm test
   branches:
     master:
       - 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 Master übertragen werden.

Ab jetzt triggert der Push an den Master ein Deployment, nachdem die Anwendung erstellt und getestet worden ist. 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 triggern, indem er seine Änderungen an den Master 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 permissions

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

Adding a branch permission

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.

Adding a branch permission

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 Master 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 Master 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 pipeline logs

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.