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:

  • main: any push to main will deploy the code to a staging environment after running the tests.
  • Produktion: Code, für den ein Merge in den Produktions-Branch durchgeführt wird, wird automatisch in der Produktionsumgebung veröffentlicht.

First, we'll configure the deployment to staging. To do that, we use the branch-specific pipelines and create a pipeline that gets executed for every push on the main branch.

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

We have now created a pipeline that will deploy every push to main to Heroku after building and testing our application. The clone section at the beginning of the configuration ensures we do a full clone (otherwise Heroku might reject the git push). Just push this configuration to Bitbucket to see your first automated deployment to staging happening.

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.

When that's done, you can create a pull request to merge the code from main to production and subsequently release the new changes to your production environment.

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.

With Bitbucket Pipelines it is possible to configure custom pipelines that can be triggered manually. They can be used for various purposes: long-running tests that you do not want to run on every push, or specific actions that you want to control yourself. We will use a custom pipeline to set up a continuous delivery workflow where pushes to the main branch get automatically deployed to a staging environment, and commits can be manually deployed to production.

First, we need to configure the automatic deployment to staging. You simply need to add a branch-specific pipeline for main that will deploy the staging environment.

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.