Continuous Delivery on Steroids: Einführung in Heroku Pipelines

Heroku ist ein Platform as a Service (PaaS) Anbieter. Mit Heroku Pipelines stellt Heroku seit kurzem die Möglichkeit bereit, schnell und einfach eine Continuous Delivery Pipeline aufzubauen. Deshalb ist das Thema vor allen Dingen für Entwickler interessant, die sich auf die Entwicklung von Anwendungen konzentrieren aber trotzdem nicht auf die Vorteile von Continuous Delivery verzichten wollen. Auch für IT Manager spielt die Entscheidung zwischen Do-it-Yourself Continuous Delivery oder Heroku PaaS Umgebung eine wichtige Rolle. Darum zeige ich in diesem Blogpost, wie eine Heroku Pipeline aussieht und wie sie sich von einer klassichen Continuous Delivery Pipeline abgrenzt. Zu einer klassischen Continuous Delivery Pipeline gehört neben der Deployment Automatisierung auch die Ausführung von automatisierten Tests und Code Metriken. Folglich gehe ich auch auf die Integration von Heroku mit GitHub und verwandten Services wie Travis CI , coveralls.io und codacy ein.

Die klassische Continuous Delivery Pipeline

Welcher Entwickler kennt das nicht: Ein neues Projekt wird gestartet, doch statt von Beginn an an der Lösung der Business Probleme zu arbeiten, verbringt man die ersten Sprints mit dem Aufsetzen der Entwicklungsinfrastruktur. Wir müssen einen Build Server einrichten und entsprechende Build Jobs konfigurieren. Außerdem wollen wir für das Deployment verschiedene Umgebungen haben. Häufig gibt es hier die Dreiteilung zwischen Development, Integration (oder QA) und Production Umgebung. Ist die Infrastruktur fertig aufgebaut, will diese natürlich auch regelmäßig von uns gewartet werden. Eine klassische Continuous Delivery Umgebung sieht heutzutage ungefähr so aus:

Den Weg, den ein neues Feature durch diese Continuous Delivery Umgebung nimmt, habe ich mit Zahlen markiert:

1. An unserem Arbeitsplatz entwickeln wir ein neues Feature und machen ein Code Review.
2. Nach erfolgreichem Code Review, pushen wir die Änderung in ein zentrales git Repository.
3. Von dort wird diese vom Build Server gebaut, getestet und es werden Codemetriken erhoben.
4. Häufig gibt es außerdem noch Jobs, mit denen wir ein Deployment in unterschiedliche Umgebungen anstoßen können.
5. Da wir schnell und einfach skalieren wollen, betreiben wird die Development, Integration und Production Umgebungen bei AWS .
6. Für die Provisionierung der Umgebungen nutzen wir ein Provisionierungstool wie z.B. Ansible .

In der Abbildung sind eine ganze Reihe von Infrastrukturkomponenten zu sehen, um die wir uns selber kümmern müssen: Ein Git Repository, der Build Server mit seinen Build Jobs (in unserem Beispiel Jenkins ), verschiedene Ausführungsumgebungen bei AWS , sowie Provisionierungsskripte. Viele bewegliche Teile, die Probleme machen können. Manchmal reicht schon ein Systemupdate auf dem Build Server, welches eine neue Java Version installiert und plötzlich schlagen Build Jobs fehl. Die Ursachenforschung kostet Zeit und Nerven.

Heroku Pipelines

Glücklicherweise müssen wir einen Großteil dieser Arbeit heutzutage nicht mehr selbst machen. Heroku Pipelines sind eine einfache Lösung zum Aufsetzen einer Continuous Delivery Pipeline. Dabei werden mehrere Heroku Apps miteinander verkettet (wie man eine Heroku App konfiguriert, habe ich bereits in einem anderen Blogpost beschrieben). Eine Heroku Pipeline sieht im Heroku Dashboard dann so aus:

Zu sehen sind drei Umgebungen: Review, Staging und Production. Schauen wir uns den Ablauf eines Deployments genauer an. Die erste Umgebung, die eine Änderung durchläuft, ist die Review Umgebung. Hier wird für jede Änderung ein eigenes Deployment der Anwendung durchgeführt. Besonders gut funktioniert das, wenn Heroku mit GitHub integriert betrieben wird (siehe Abschnitt Integration mit GitHub und co.). Sofern eine Änderung auf der Review Umgebung für gut befunden wurde, wird sie zurück in den Master Branch gemerget. Diesen Merge Commit registriert Heroku und löst ein automatisches Deployment der Anwendung auf die Staging Umgebung aus. Staging ist also eine Integrationsumgebung, auf die Änderungen am Master Branch automatisch deployt werden. Die finale Umgebung ist Production. Hier bietet es sich an, das Deployment so zu konfiguieren, dass es explizit ausgelöst werden muss. Dann können wir auf Staging so lange Änderungen sammeln, bis der gewünschten Umfang für das nächste Production Release erreicht ist. Eine explizite Promotion von Staging nach Production sieht dann so aus:

Das ist schon ziemlich komfortabel! Wir müssen keine Deployment Jobs in unserem Buildserver pflegen, sondern können mit einem Knopfdruck auf unsere Produktionsumgebung deployen. Heroku Pipelines machen aber alleine noch keine Continuous Delivery Umgebung aus. Für automatisierte Deployments sind eine umfassende Testumgebung sowie Codemetriken unerlässlich.

Integration mit GitHub und co.

Die fehlenden Teile der Continuous Delivery Umgebung können wir sehr einfach mittels GitHub und weiterer Services auffüllen. Hier sind vor allen Dingen die folgenden zu nennen:

• Travis CI für die Ausführung automatisierter Tests
• coveralls.io für die Bewertung der Testabdeckung
• Codacy für die Bewertung der Code Qualität

Eine Continuous Delivery Pipeline bestehend aus Heroku, GitHub, Travis CI, coveralls.io und Codacy sieht schematisch so aus:

Hier gibt es keine Infrastrukturkomponenten mehr, um die wir uns kümmern müssen. Statt dessen verwenden wir spezialisierte Services um die Aufgaben einer Continuous Delivery Pipeline zu realisieren. Die Schritte, die ein neues Feature durch diese Pipeline nimmt, habe ich wieder mit Zahlen markiert:

1. Als Erstes stellen wir unsere Änderung als Pull Request auf GitHub bereit.
2. Travis CI führt die automatisierten Tests aus. Bei einem Fehlschlag zurück zu 1.
3. coveralls.io prüft ob sich die Testabdeckung signifikant verschlechtert hat. Wenn ja, zurück zu 1.
4. Codacy prüft ob sich die Code Qualität signifikant verschlechtert hat. Wenn ja, zurück zu 1.
5. Ein zweiter Entwickler macht ein Code Review. Sofern es Verbesserungsvorschläge gibt, zurück zu 1.
6. Die Änderungen im Pull Request werden bei Heroku als Review App deployt. Nun kann der Product Owner (PO) / der Fachbereich prüfen ob die Anforderungen richtig umgesetzt wurden. Wenn nein, zurück zu 1.
7. Sofern der Pull Request bis hierhin durchgekommen ist, wird er zurück in den Master Branch gemerget. Dies löst das Deployment auf die Staging Umgebung aus.
8. Auf der Staging Umgebung können wir die Änderung in Integration mit anderen Änderungen prüfen.
9. Sofern ein Bündel von Änderungen bereit für die Produktion ist, lösen wir ein manuelles Deployment nach Production aus.

An die Stellen der beweglichen Teile aus dem klassischen Setup sind Services wie Heroku, GitHub und co. getreten. Wir müssen uns um einen Großteil der Infrastruktur nicht mehr selber kümmern und haben deshalb mehr Zeit uns auf das Wesentliche zu konzentrieren. Keine SSH Debugging Sessions auf virtuellen Servern mehr. Kein Kopfzerbrechen mehr, weil unsere Provisionierungsskripte nicht das tun, was sie sollen. Nie mehr schlaflose Nächte, weil ein Update auf unserem Buildserver bevorsteht.

Fazit

In diesem Blogpost habe ich Heroku Pipelines vorgestellt. Heroku Pipelines versetzen Entwickler in die Lage, sich bei der Entwicklung von Anwendungen auf das Wesentliche zu konzentrieren, ohne auf die Vorteile von Continuous Delivery verzichten zu müssen. In Kombination mit GitHub und co. sind sie eine echte Alternative zu traditionellen, selbstgestrickten Continuous Delivery Umgebungen.