Erlerne Continuous Delivery mit Bitbucket Pipelines

In diesem Leitfaden sehen wir uns an, wie du mit Bitbucket Pipelines einen Continuous-Delivery-Workflow einführen kannst. Es lohnt sich also, weiterzulesen. 

Sten Pittet Sten Pittet

Anforderungen

Zeit:

30 Minuten

Zielpublikum:

Continuous Delivery und/oder Bitbucket Pipelines sind neu für dich

Voraussetzungen:

Kostenlos testen

Der Release einer neuen Funktion ist immer ein aufregender Moment, da du deinen Kunden neue Möglichkeiten bieten kannst. Ein Release kann aber auch riskant sein und viel Vorbereitung erfordern, sodass dein Team häufigen Releases zögerlich gegenübersteht. Und je länger du wartest, desto schwieriger wird das Deployment in die Produktion. Änderungen häufen sich an, es ist schwierig, den Umfang der Änderung zu verstehen, und es wird schwierig sein, die Ursachen zu identifizieren, wenn Probleme in der Produktion auftreten.

Eine einfache Möglichkeit, deinem Team diese Angst zu nehmen und die Kosten von Software-Deployments zu senken, besteht darin, den Vorgang zu automatisieren und häufiger kleinere Änderungen zu releasen. Zum einen sparst du so die vielen Arbeitsstunden, die normalerweise in die Vorbereitung des Release investiert werden. Zum anderen minderst du das mit dem Software-Deployment verbundene Risiko, weil der Umfang der einzelnen Releases deutlich geringer ist, was die Überwachung der Umgebungen und die Fehlerbehebung vereinfacht.

Diese Deployment-Automatisierung ist heute mit Bitbucket Cloud problemlos möglich. Für jedes deiner Repositorys kannst du eine Pipeline konfigurieren, die deinen Code automatisch bei jedem Push erstellt, testet und in deinen Umgebungen bereitstellt. In diesem Leitfaden sehen wir uns an, wie du mit Bitbucket Pipelines einen Continuous-Delivery-Workflow einführen kannst.

Vergleich zwischen Continuous Delivery und Continuous Deployment

Mit der Continuous Delivery stellst du sicher, dass dein Code jederzeit bereit für den Release ist, auch wenn du nicht jede Änderung für die Produktion bereitstellst. Es empfiehlt sich, deine Produktion so oft wie möglich upzudaten, um zu gewährleisten, dass der Umfang der Änderungen klein bleibt, aber letztendlich steuerst du den Rhythmus deines Releases.

Beim Continuous Deployment werden neue Änderungen, die in das Repository geschoben werden, automatisch in der Produktion bereitgestellt, wenn sie die Tests bestehen. Dies setzt deine Testkultur stärker in den Vordergrund (sprich: unter Druck), aber es ist eine großartige Möglichkeit, die Feedbackschleife mit deinen Kunden zu beschleunigen.

Ein Diagramm, das Continuous Delivery im Vergleich zu Continuous Integration zeigt (CI vs. CD) | Atlassian CI/CD

Einführung einer Continuous-Delivery-Pipeline

In diesem Beispiel erstellen wir eine einfache Continuous-Delivery-Pipeline, die automatisch für das Staging bereitgestellt wird, wenn der Build den Test bestanden hat. Wir sehen uns zwei verschiedene Strategien für das Produktions-Deployment an: eine mit Branches und Pull-Anfragen und die andere mit benutzerdefinierten Pipelines und manuellen Triggern.

In beiden Beispielen verwenden wir eine einfache Node.js-Anwendung, die eine Hallo-Welt-Nachricht in deinem Browser anzeigt. Du kannst den Code der Hallo-Welt-Anwendung unten klonen und verwenden, um diesem Tutorial zu folgen.

Wir stellen diese Anwendung mit beiden Methoden in auf Heroku gehosteten Staging- und Produktionsumgebungen bereit.

Eine einfache Hallo-Welt-Anwendung | Atlassian CI/CD

Unsere einfache Hello World-Anwendung

Vorbereitung des Deployments auf Heroku

Zu Beginn müssen wir Bitbucket Pipelines einige Umgebungsvariablen hinzufügen, damit die Bereitstellung auf Heroku funktioniert:

  • HEROKU_API_KEY: Du findest deinen API-Schlüssel in deinem Heroku-Konto.
  • HEROKU_STAGING: Name deiner Staging-Umgebung
  • HEROKU_PROD: Name deiner Produktionsumgebung

Gehe in deinen Repository-Einstellungen zu Pipelines > Umgebungsvariablen, um die Variablen hinzuzufügen.

Screenshot der Einrichtung von Heroku in Bitbucket | Atlassian CI/CD

Einrichtung von Umgebungsvariablen für das Deployment auf Heroku

In diesem Leitfaden verwenden wir Heroku. Sicherlich ist es möglich, dieses Beispiel an andere Hosting-Dienste anzupassen. Weitere Deployment-Leitfäden findest du in der Dokumentation.

Continuous Delivery mit Branches als Gate zur Produktion

Diese Konfiguration ist für Teams geeignet, die über spezielle Release-Branches verfügen, die einem Deployment zugeordnet werden können. Außerdem kannst du Änderungen an einer Pull-Anfrage überprüfen, bevor sie in der Produktion bereitgestellt werden.

In dieser Konfiguration verwenden wir zwei verschiedene Branches, um Deployments auszulösen:

  • Haupt-Branch: Bei jedem Push zum Haupt-Branch wird der Code nach den Tests in einer Staging-Umgebung bereitgestellt.
  • Produktion: Code, für den ein Merge in den Produktions-Branch durchgeführt wird, wird automatisch in der Produktionsumgebung veröffentlicht.

Zuerst konfigurieren wir das Deployment in der Staging-Umgebung. Zu diesem Zweck nutzen wir Branch-spezifische Pipelines zum Erstellen einer Pipeline, die bei jedem Push im Haupt-Branch ausgeführt wird.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main

Wir haben jetzt eine Pipeline erstellt, die nach dem Entwickeln und Testen unserer Anwendung jeden Push zunächst im Haupt-Branch und anschließend auf Heroku bereitstellt. Der Klonabschnitt am Anfang der Konfiguration stellt sicher, dass wir einen vollständigen Klon durchführen (andernfalls könnte Heroku den Git-Push ablehnen). Verschiebe diese Konfiguration einfach zu Bitbucket, um dein erstes automatisiertes Deployment in der Staging-Umgebung zu sehen.

Screenshot eines erfolgreichen Pipeline-Deployments | Atlassian CI/CD

Eine erfolgreiche Pipeline, die unsere Anwendung für das Staging bereitstellt

Wie du vielleicht vermutet hast, müssen wir nur eine weitere Branch-Pipeline hinzufügen, damit der Produktions-Branch automatisch in der Produktionsumgebung veröffentlicht werden kann, wenn Änderungen im Produktions-Branch gemergt werden.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main     # When code is pushed to the main branch it is deployed automatically to the production environment.     production:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:main  

Wir führen die Tests erneut im Produktions-Branch durch, um vor dem Release der Anwendung sicherzustellen, dass der Build durch nichts beeinträchtigt wurde.

Unsere Pipelines sind jetzt konfiguriert. Wir können den Produktions-Branch jetzt so einschränken, dass nur Merges per Pull-Anfrage akzeptiert werden. Navigiere dazu einfach in den Repository-Einstellungen zu Workflow > Branch-Berechtigungen. Dieser Schritt ist wichtig, um zu verhindern, dass Kollegen Änderungen direkt von ihrem lokalen Rechner an die Produktion übermitteln.

Konfigurieren der Berechtigungen des Produktions-Branch | Atlassian CI/CD

Konfiguration der Berechtigungen des Produktions-Branch

In dem hier abgebildeten Screenshot siehst du folgende Berechtigungen:

  • Niemand hat Schreibzugriff.
  • Nur ein Entwickler kann einen Merge in den Branch durchführen.

Wir haben auch einen Merge-Check hinzugefügt, um sicherzustellen, dass der Quell-Branch vor dem Merge des Codes mindestens einen grünen Build hat. Dadurch können wir Build-Zeit sparen und Entwickler daran hindern, einen Merge von fehlerhaftem Code in unseren Produktions-Branch durchzuführen.

Wenn dies erledigt ist, kannst du einen Pull Request erstellen, um den Code vom Haupt- in den Produktions-Branch zu mergen und anschließend die neuen Änderungen in deiner Produktionsumgebung veröffentlichen.

Bitbucket-Screenshot der Erstellung einer Pull-Anfrage | Atlassian CI/CD

Erstellung einer Pull-Anfrage für einen Merge von Änderungen in die Produktion

Sobald du die Pull-Anfrage mergst, siehst du, wie für den Produktions-Branch eine neue Pipeline ausgelöst wird.

Eine Pipeline wurde durch die Pull-Anfrage erfolgreich ausgelöst | Atlassian CI/CD

Nach Abschluss der Pipeline werden deine neuen Änderungen erfolgreich in der Produktionsumgebung bereitgestellt.

Die Produktionsumgebung ist auf dem neuesten Stand!

Du hast nun einen Workflow für Continuous Delivery mit Bitbucket Pipelines eingerichtet und kannst Pull-Anfragen sicher verwenden, um Code für deine Kunden zu veröffentlichen.

Die endültige Quelle dieses Beispiels findest du im unten verlinkten Repository.

Continuous Delivery mit manuellem Trigger für den Release

Diese Konfiguration ist ideal für Teams, die Trunk-basierte Entwicklung praktizieren.

Mit Bitbucket Pipelines ist es möglich, benutzerdefinierte Pipelines zu konfigurieren, die manuell ausgelöst werden können. Sie können für verschiedene Zwecke verwendet werden: für lang andauernde Tests, die du nicht bei jedem Push ausführen möchtest, oder für bestimmte Aktionen, die du selbst kontrollieren möchtest. Wir werden eine benutzerdefinierte Pipeline verwenden, um einen Continuous Delivery-Workflow einzurichten, bei dem Pushs in den Haupt-Branch automatisch in einer Staging-Umgebung bereitgestellt werden und Commits manuell für die Produktion bereitgestellt werden können.

Zunächst müssen wir das automatische Deployment für das Staging konfigurieren. Du musst lediglich eine Branch-spezifische Pipeline für den Haupt-Branch hinzufügen, die die Staging-Umgebung bereitstellt.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main  

Du kannst diese Konfiguration an dein Repository übertragen, um das erste Deployment im Staging in Aktion zu sehen.

Unser erstes automatisches Deployment im Staging

Wir haben nun unser Staging-Deployment eingerichtet und können unserer bitbucket-pipelines.yml-Konfiguration einfach eine benutzerdefinierte Pipeline hinzufügen, mit der wir manuell den Release in die Produktion auslösen werden.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main   custom:     prod-deployment:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

Nachdem du die neue Konfiguration in dein Bitbucket-Repository gepusht hast, kannst du im Commit unter dem Bereich "Commit information" (Commit-Informationen) auf den Link Run pipeline (Pipeline ausführen) klicken, um das Deployment in die Produktion auszulösen.

Die Aktion "Run pipeline" (Pipeline ausführen) listet die verfügbaren benutzerdefinierten Pipelines auf.

Klicke einfach auf die Schaltfläche Run (Ausführen), um zur Pipeline für das Produktions-Deployment weitergeleitet zu werden, in der du die Protokolle überwachen kannst.

Im Bereich "Commit information" (Commit-Informationen) der Pipeline siehst du den Namen der verwendeten benutzerdefinierten Pipeline. Du bist jetzt bereit, deine neue Bitbucket Pipelines-Konfiguration für Continuous Delivery zu verwenden, und du kannst deine Hallo-Welt-Produktion überprüfen, um sicherzustellen, dass alles gut gelaufen ist!

Unser Hallo-Welt-Programm wurde mit einem manuellen Trigger in der Produktion bereitgestellt.

Die endgültige Quelle dieses Beispiels findest du im unten verlinkten Repository.