Mit Bitbucket und Bitbucket Pipelines zum automatisierten Deployment

Software wird nicht einmal gebaut und dann in Ruhe gelassen. Sie ändert sich, solange sie im Einsatz ist. Je mehr Handgriffe zwischen fertigem Code und laufender Plattform liegen, desto teurer wird jede einzelne Änderung, und desto grösser die Wahrscheinlichkeit, dass beim hundertsten Mal ein Schritt vergessen geht. Deshalb automatisieren wir die Auslieferung so weit, wie es geht. Hier steht, wie unser Deployment abläuft und welche Werkzeuge daran beteiligt sind.

Was ein automatisches Deployment abnimmt

Ein Deployment ist die Bereitstellung von Software auf einer Umgebung. Klassisch besteht es aus mehreren Schritten:

• Release zusammenstellen
• Konfiguration für die Zielumgebung vorbereiten
• Build erstellen und automatisierte Tests durchlaufen
• Auf das Abnahmesystem einspielen
• Abnahme durch die Anwenderinnen und Anwender
• Auf Produktion verteilen

Automatisiert wird alles, was keine menschliche Entscheidung braucht. Übrig bleibt die Abnahme. Ein Release lässt sich damit von der Person einspielen, die die Änderung geschrieben hat. Es muss niemand mit Sonderwissen dazukommen. Und der Weg von Staging auf Produktion ist derselbe wie der von der Entwicklungsumgebung auf Staging.

Die Begriffe dazu: Continuous Integration meint das laufende Zusammenführen und Testen des Codes, Continuous Delivery eine jederzeit auslieferbare Version, Continuous Deployment die Auslieferung ohne manuellen Auslöser.

Vom Commit bis auf die Umgebung

Am Anfang steht eine Änderung am Code: neue Dateien, geänderte Zeilen, manchmal eine Anpassung an der Datenbank. Entwickelt wird in der eigenen Umgebung. Die Änderungen fasst ein Commit zusammen, der auf einen Branch im Repository gepusht wird, und genau das startet die Pipeline.

In der Pipeline laufen die automatisierten Tests parallel. Behat prüft verhaltensbasierte Szenarien, also den Ablauf aus Sicht der Benutzerin. PHPUnit prüft die einzelnen Bausteine des Codes und ihr Zusammenspiel. Fällt ein Test durch, kommt die Änderung nicht weiter.

Besteht der Commit die Tests, folgt ein Pull Request. Ein zweites Teammitglied liest den Code und gibt ihn frei; erst dann wird gemerged. Der Merge löst das Deployment auf die zugehörige Umgebung aus. Während Code und Daten auf dem Ziel-Branch ausgetauscht werden, ist das System kurz nicht erreichbar, danach läuft die neue Version.

Drei Werkzeuge tragen den Ablauf:

• Git für die Versionierung des Codes.
• Bitbucket für Repositories, Commits, Branches und Pull Requests.
• Bitbucket Pipelines für die Build- und Testläufe, die pro Commit parallel starten.

Was das im Alltag bringt

• Der Ablauf ist in jedem Projekt derselbe, ein Release überrascht niemanden mehr.
• Weniger manuelle Schritte heisst weniger Stellen, an denen etwas schiefgehen kann.
• Deployments dauern kürzer, weil nichts von Hand vorbereitet wird.
• Das Entwicklungsteam wird nicht für jedes Release aus der Arbeit gerissen.
• Der Aufwand pro Release sinkt und damit die Kosten.

Der Prozess gehört zu unserem Plattform-Stack und läuft überall gleich. Wer neu in ein Projekt kommt, findet dieselbe Pipeline vor wie im letzten. Das ist der eigentliche Gewinn an der Standardisierung.