Der Weg zu Continuous Deployment

In diesem Leitfaden gehen wir davon aus, dass dein Workflow für Continuous Integration und Continuous Delivery bereits vorhanden ist und dass dein nächster Schritt darin besteht, deine Continuous-Delivery-Pipeline einzurichten.

Sten Pittet Sten Pittet

Sieh dir auch unser Tutorial zum Einstieg in Continuous Deployment mit Bitbucket Pipelines an.

"Finger weg von der Produktion – ich möchte etwas veröffentlichen!"

Dieser Satz kommt dir vielleicht bekannt vor. Produktions-Deployments können riskant und kostspielig sein, und führen gelegentlich dazu, dass die gesamte Entwicklung auf Eis gelegt werden muss. Hierdurch verlangsamen sich die Release-Zyklen und Änderungen in der Entwicklungsumgebung stagnieren. Es ist der Beginn eines heiklen Teufelskreises. Je mehr Commits in das Repository durchgeführt werden, desto mehr Risiken gelangen beim nächsten Deployment in die Produktion und desto unwahrscheinlicher ist es, dass dein Team diesen Release durchführt.

Continuous Deployment löst dieses Problem, indem alle in das Haupt-Repository übernommenen Änderungen automatisch an die Produktion übermittelt werden. Im Vergleich zum tagelangen Vorbereiten und Kontrollieren der einzelnen Releases ist dies ein radikaler Ansatz, der jedoch einige Vorteile bietet:

  • Releases werden kleiner und leichter zu verstehen.
  • Niemand muss seine Arbeit für ein Deployment unterbrechen, da alles automatisiert ist.
  • Die Feedbackschleife mit deinen Kunden ist schneller: Neue Funktionen und Verbesserungen gehen direkt in die Produktion, wenn sie bereit sind.

Die Umstellung von genehmigten Releases auf Continuous Deployment kann eine Herausforderung sein. Genau dabei unterstützt dich dieser Leitfaden. Wir behandeln hier die Grundlagen, damit du so schnell wie möglich loslegen und deinen Release-Zyklus beschleunigen kannst.

Vergleich zwischen Continuous Deployment und Continuous Delivery

Wenn du eine Continuous-Deployment-Pipeline implementieren möchtest, ist der beste Ausgangspunkt Continuous Delivery. Die beiden Verfahren sind ähnlich, unterscheiden sich jedoch in ihren Ansätzen für Produktions-Deployments. Bei Continuous Delivery ist jede Änderung, die auf das Hauptrepository übertragen wird, bereit, ausgeliefert zu werden, aber der Produktions-Release-Prozess erfordert immer noch die Genehmigung durch eine reale Person. Bei Continuous Deployment erfolgen Releases in der Produktion automatisch für jede Änderung, die die Testsuite erfolgreich durchläuft.

Vergleich zwischen Continuous Delivery und Continuous Deployment

Bevor du mit der automatischen Auslieferung von Produktionsänderungen beginnst, benötigst du eine gute Continuous-Integration-Kultur, und es wird dringend empfohlen, mit Continuous Delivery zu beginnen. Weitere Informationen zu den beiden Verfahren findest du in den folgenden Artikeln:

Umstellung von Continuous Delivery auf Continuous Deployment

Eine Kultur der Continuous Integration

Die Grundlage für Continuous Deployment bildet eine solide CI-Kultur. Die Qualität deiner Testsuite entscheidet über das Risiko für deine Releases. Außerdem müssen automatische Tests in deinem Team während der Entwicklungsphase oberste Priorität haben. Ihr müsst also Tests für jedes neue Feature und für etwaige nach dem Release entdeckte Regressionen implementieren.

Das Reparieren eines defekten Builds für den Haupt-Branch sollte ebenfalls ganz oben auf der Liste stehen. Andernfalls setzt du dich den gleichen Risiken aus, mit denen du vor der Einführung von Continuous Deployment konfrontiert warst: Änderungen werden in der Entwicklungsumgebung gesammelt und die Entwickler können nicht sicher sein, dass ihre Arbeit abgeschlossen ist, da sie nicht wissen, ob ihre Änderungen die Akzeptanztests bestanden haben.

Wichtig: gute Testabdeckung (und vor allem gute Tests!)

Verwende Testabdeckungstools, um sicherzustellen, dass deine Anwendung angemessen getestet wird. Ein gutes Ziel ist es, eine 80%ige Abdeckung anzustreben.

Verwechsle aber nicht eine gute Abdeckung mit guten Tests. Du könntest eine 100%ige Testabdeckung mit Tests haben, die deine Codebasis nicht besonders gründlich prüfen. Nimm dir Zeit für Code-Reviews, um zu überprüfen, wie Tests geschrieben werden, und zögere nicht, auf Lücken in der Abdeckung oder auf schwache Tests hinzuweisen. Deine Testsuite fungiert als Gate zur Produktion – sie sollte daher solide sein.

Echtzeitüberwachung

Wenn alle Commits automatisch in der Produktion bereitgestellt werden sollen, musst du sicherstellen, dass du bei Fehlern zuverlässig benachrichtigt wirst. Manchmal unterbricht eine neue Änderung nicht sofort die Produktion, lässt aber die CPU- oder Arbeitsspeicherauslastung gefährlich in die Höhe schnellen. Aus diesem Grund ist die Implementierung von Echtzeitüberwachung auf deinen Produktionsservern sinnvoll, um Unregelmäßigkeiten in deinen Metriken zu verfolgen.

Tools wie Nagios oder Services wie New Relic helfen dir, grundlegende Leistungsmetriken zu verfolgen, und warnen dich bei Störungen in deinen Systemen.

Überprüfe deine Post-Deployment-Tests

Nach jedem Deployment in der Produktion solltest du einige einfache Smoke-Tests durchführen, um dich von der Funktionsfähigkeit der Anwendung zu überzeugen.

Diese Tests müssen mehr leisten, als nur eine statische Seite aufzurufen und auf eine erfolgreiche Antwort zu warten. Es hat sich bewährt, einen Test durchzuführen, der erfordert, dass alle deine Produktionsservices (Datenbank, Mikroservices, Drittanbieterservices etc.) ordnungsgemäß funktionieren.

Upstream-Arbeitsweise des QS-Teams

Da jeder Commit jetzt direkt in die Produktion geht, bedeutet dies, dass es zur Überprüfung und Genehmigung neuer Funktionen keinen herkömmlichen Puffer für dein Qualitätssicherungsteam gibt. Stattdessen sollte es eng mit dem Produktmanager und dem Entwicklerteam zusammenarbeiten, um die mit neuen Verbesserungen verbundenen Risiken zu definieren.

Dies ist eine große Chance für das QS-Team, da sich im Laufe der Zeit die Qualität der Releases verbessert. Beim Continuous Deployment wird dein Team sich natürlich um eine gute Testabdeckung der Codebasis bemühen. Andernfalls kommt es zu häufigen Störungen, die darauf zurückzuführen sind, dass Fehler in die Produktion geraten, wo sie von deinen Benutzern entdeckt werden.

Wegfall herkömmlicher Release Notes

Continuous Deployment macht es dir schwer, mit den Releases Schritt zu halten – und das ist gut so! Dein Ziel sollte es sein, tägliche Deployments oder sogar mehrere Deployments pro Tag in der Produktion zu haben. Dies können Bugfixes, kleine Verbesserungen, neue Funktionen etc. sein. Sobald ein Entwickler seine Arbeit beendet hat, sollte diese Arbeit wenige Minuten später in die Produktion aufgenommen werden.

In dieser neuen Welt ist es nicht mehr möglich, Release Notes zu verfassen, die mit jeder neuen Version an deine Kunden gesendet werden. Nutze stattdessen diesen neuen Workflow und beschränke deine Ankündigungen auf wichtige Funktionen, die für deine Kunden von Bedeutung sind. Fehlerberichte und kleine Verbesserungsanfragen können einfach in deinem Ticketsystem bearbeitet werden – Jira kann beispielsweise alle Beobachter eines Tickets aktualisieren, sobald du es schließt oder aktualisierst.

Ein anderer Ansatz für neue Projekte: Produktions-Deployments noch vor dem Programmieren

Wenn du mit einer brandneuen Codebasis beginnst, hast du eine interessante Option. Du kannst deine Continuous-Deployment-Pipeline erstellen, bevor Kunden und Funktionen vorhanden sind (nicht anders als bei der testorientierten Entwicklung). Zu Beginn lieferst du eine leere Plattform aus. Mit fortschreitender Entwicklung werden dann automatisch neue Funktionen angezeigt. Du musst lediglich deine Produktionsumgebung geschlossen halten, bis du bereit bist, sie für deine Kunden zu öffnen.

Dieser Ansatz mag auf den ersten Blick nicht intuitiv erscheinen. Er bietet jedoch eine einfache Möglichkeit, den Stress des Prozesses von einer manuellen Release-Genehmigung bis zum kontinuierlichen Deployment in der Produktion zu reduzieren. Darüber hinaus ist dies auch eine hervorragende Möglichkeit, um sicherzustellen, dass du beim Start über eine gute Testabdeckung und eine Continuous-Integration-Kultur verfügst, da dies die Voraussetzung für Continuous Deployment ist.

Wissen ausbauen und Erfahrungen weitergeben

Es ist verständlicherweise schwierig, den Sprung zu wagen und auf Continuous Deployment umzusteigen. Plötzlich werden die Tore geöffnet, und der Code geht innerhalb weniger Minuten oder Stunden direkt an die Kunden. (Oh nein!) Daher ist es wichtig, in Tests und Automatisierungen zu investieren, die dein Vertrauen in deine Builds stärken. Dies ist einfach, wenn deine Codebasis neu ist, erfordert bei einer komplexen älteren Codebasis jedoch möglicherweise die Einführung einer anderen Strategie.

Fange klein an und baue fundierte Kenntnisse und Erfahrungen mit Continuous Deployment auf. Sobald du das Verfahren in einem Projekt umgesetzt hast, ist dieser Erfolg in anderen Bereichen des Unternehmens leicht zu reproduzieren.