Heutzutage muss dein Team neue Features oft schnell und zuverlässig entwickeln und ausrollen. Damit das richtig gut klappt, brauchst du eine gut strukturierte Deployment Pipeline.
Wir erklären dir, was genau eine Deployment Pipeline ist, was für Vorteile sie dir bringt und aus welchen Schritten sie typischerweise besteht.
Was ist eine Deployment Pipeline?
In der Software-Entwicklung versteht man unter einer Deployment Pipeline einen Prozess aus automatisierten Schritten mit dem Ziel, Änderungen auf ein Production System zu bringen. Manuelle Änderungen auf dem Server sind häufig fehleranfällig. Durch die Automatisierung wird nicht nur der Aufwand enorm reduziert, sondern auch die Qualität des Produktes verbessert. Dadurch ist sie aus der modernen Softwareentwicklung nicht mehr wegzudenken. Hierzu werden häufig Prinzipien aus der Continuous Integration (CI) Continuous Delivery (CD) genutzt.
Was verbirgt sich hinter Continuous Integration und Continuous Delivery?
Wenn du dich mit Deployment Pipelines oder auch nur agiler Softwareentwicklung im Allgemeinen beschäftigst, wirst du um die Begriffe Continuous Integration (CI) und Continuous Delivery (CD) kaum noch herum kommen. Beide Vorgänge haben sich längst als bewährte Praxis in der Entwicklung durchgesetzt.
Bei der Continuous Integration wird neuer Code möglichst schnell (idealerweise kontinuierlich) in eine gemeinsame Code-Basis integriert. Deine Entwickler*innen teilen ihren Fortschritt mehrmals täglich und führen ihre Änderungen zurück ins Projekt. Eine solche fortlaufende Integration verhindert, dass die Versionen einzelner Entwickler*innen zu weit voneinander divergieren und nur schwer miteinander vereinbar sind. Kleinstufige Integrationen vereinfachen das frühzeitige Erkennen und Beheben von Fehlern, vor allem wenn jede Integration mit automatisierten Tests einhergeht.
Von Continuous Delivery wird gesprochen, wenn das gleiche Konzept auch auf die Auslieferung des finalen Produkts ausgeweitet wird. Statt auf feste Release-Termine zu warten, wie beispielsweise jedes Quartal, bringst du neue Features auf Production, sobald diese die Entwicklung durchlaufen haben. Grob gesagt stellst du jede lauffähige Version des Produktes umgehend bereit. Dies erhöht die Flexibilität deines Projektes und verkürzt drastisch die Zeitspanne, bis ein gewünschtes Feature deinen Nutzer*innen zur Verfügung steht.
Sowohl in der Continuous Integration als auch der Continuous Delivery werden Integration und Deployment weit öfter durchlaufen, als es in der konservativen Entwicklung der Fall wäre. Dies ist nur dann möglich und sinnvoll, wenn die damit einhergehenden Prozesse möglichst einfach und schnell durchgeführt werden können.
Daher ist eine starke Automatisierung des Builds notwendig. Build-Automatisierung kann zahlreiche Aufgaben beinhalten, wie Kompilieren des Quellcodes, Erstellen von Installationsdateien, oder das Prüfen auf Codestyle-Richtlinien. Im Fokus steht immer, die Mehrarbeit für deine Entwickler*innen auf ein Minimum zu begrenzen. Softwarelösungen wie Bamboo, Jenkins oder Chef greifen dem Team dabei immer stärker unter die Arme.
Vorteile einer Deployment Pipeline
Bevor wir uns mit dem Prozess selbst befassen, wenden wir uns als erstes dem Zweck der Deployment Pipeline zu. Anders gefragt: Welche Vorteile bringt dir eine Deployment Pipeline?
- Geschwindigkeit
Die Zeit zwischen der Entwicklung neuer Features und dem Moment, in dem deine Kunden es nutzen können, wird auf ein Minimum reduziert. - Kapazitäten
Automatisierung spart Arbeitszeit! Die gewonnenen Stunden fließen zurück in deine Entwicklung und resultieren letztendlich in rundum besseren Produkten. - Motivation
Ein weiterer Grund, solche Aufgaben zu automatisieren: Ständig wiederholende, monotone Aufgaben können sich als echter Kreativitätskiller für dein Team entpuppen. - Vermeidung von Fehlern
Die menschliche Komponente in deinen Prozessen zu minimieren heißt auch, die Chance für menschliche Fehler zu verringern. - Flexibilität
Häufigere, kleinere Deployments helfen dabei, den richtigen Fokus zu finden. Dein Team kann schnell auf neue Kundenwünsche und sich ändernde Anforderungen reagieren.
Welche Schritte beinhaltet eine Deployment Pipeline?
Software-Projekte kommen in vielen verschiedenen Ausprägungen. Ob App-Entwicklung, Website, API oder Desktop-Anwendung: genau wie sich Produktanforderungen unterscheiden, variiert auch der einhergehende Tech Stack stark. Dadurch unterscheiden sich natürlich auch die Anforderungen an den Deployment-Prozess. Wie genau also deine entsprechende Pipeline aussieht, ist stark vom jeweiligen Projekt abhängig. Eine Standardlösung gibt es nicht.
Folgende Schritte gehören dennoch zum Grundgerüst einer jeden Deployment Pipeline.
1. Versionsverwaltung
Versionsverwaltung beschreibt die Erfassung und Dokumentation von Änderungen über den Lebenslauf eines Softwareprojektes hinweg. Sie stellt damit eine Art Chronik der bisherigen Entwicklung dar. Die Versionierung deiner Software erlaubt es dir, den Überblick darüber zu behalten, welche Änderungen durchgeführt wurden und wann diese ausgeliefert wurden. Frühere Versionen des Codes bleiben stets verfügbar und können im Falle einer Havarie wiederhergestellt werden. So reduziert du das Risiko, das mit der Auslieferung neuer Updates einhergeht, enorm.
Versionierungstools nehmen deinen Entwickler*innen vieles an Arbeit ab. Häufig zu diesem Zweck genutzte Werkzeuge sind Git (beispielsweise via Gitlab, Github oder Bitbucket) oder SVN.
2. Akzeptanztests
Auch deine Entwickler*innen und Projektmanager*innen können nicht jederzeit alle Szenarien im Auge behalten. Um deine Software über den Entwicklungsprozess hinweg möglichst fehlerfrei zu halten, ist eine gute Testpraxis notwendig. Tests können sicherstellen, dass deine neuen Features die erwarteten Resultate liefern. Fast noch wichtiger: durch konsequentes Testen vermeidest du, dass bereits bestehender Code plötzlich nicht wie gewohnt funktioniert!
Du solltest also unbedingt, automatisierte Tests mit in deinen Deployment-Prozess aufnehmen. Schlagen die Tests fehl, wird auch der Build abgelehnt und die zuständigen Entwickler*innen benachrichtigt. Da nur Code akzeptiert wird, der die in den Tests festgelegten Kriterien erfüllt, spricht man hier von Akzeptanztests.
Wie hilfreich es sein kann, ein Projekt bereits von Anfang an mit Tests zu entwickeln und was du dabei beachten solltest, kannst du auch in unserem Artikel zum Test Driven Development nachlesen.
3. Staging Deployment
Nehmen wir an, du hast ein neues Feature entwickelt. Dieses wurde versioniert und hat sämtliche automatisierten Tests erfolgreich durchlaufen. Idealerweise haben deine Tests dir einen großen Teil der Arbeit abgenommen und viele mögliche Fehlerquellen bereits beseitigt. Doch bevor die Entwicklung abgeschlossen werden kann und das Resultat an den Kunden geliefert wird, lohnt es sich, auch selbst nochmal einen Blick darauf zu werfen.
Das mag ein wenig widersprüchlich klingen, schließlich geht es hier um die Automatisierung von Prozessen. Allerdings lassen sich viele Fehler erst im fertigen Zustand erkennen. Vielleicht hast du den ein oder anderen Edge Case vergessen, als du deine Tests geschrieben hast. Jeder Fehler, der frühzeitig erkannt wird, spart dir Zeit, Probleme und Kopfschmerzen im weiteren Verlauf der Entwicklung!
Um das Produkt genauer unter die Lupe zu nehmen, gibt es so genannte Staging Environments. Hier finden Deployments auf eigens dafür eingerichteten Umgebungen, beispielsweise einem Staging Server, statt. Das Ergebnis wird dort noch einmal in einem sicheren Rahmen in Augenschein genommen, ohne dass bereits produktiv genutzte Umgebungen (und deren Nutzer*innen) davon betroffen sind.
Diese Testumgebung sollte ein möglichst exaktes Abbild der Produktionsumgebung darstellen. So lässt sich deine Software aussagekräftiger testen und Fehler, die der Konfiguration deiner Umgebung geschuldet sind, lassen sich auch im Staging-Schritt nachverfolgen.
Auf dieser Testumgebung überprüfen Software-Tester*innen die neue Version auf Herz und Nieren. Hier können verschiedene Nutzungsszenarien durchgespielt, Edge Cases provoziert und ganz allgemein die Funktionalität des neuen Features überprüft werden.
Jetzt musst du dich fragen: Sieht das Produkt aus wie erwartet? Verhält es sich entsprechend der Anforderungen? Dann ist es bereit für das finale Deployment!
4. Production Deployment
Das Production Deployment ist der Moment, in dem dein neuer Stand der Software tatsächlich beim Kunden ankommt. Dieser Schritt ist kritisch, denn von hier an wirken sich alle vermeintlichen Fehler auch auf die Nutzer*innen aus. Daher sollten idealerweise alle Fehler und Probleme zu diesem Zeitpunkt bereits behoben sein.
Um mögliches Fehlverhalten oder Ausfallzeiten zu vermeiden, bietet sich eine Blau-Grün-Bereitstellung (blue-green deployment) an. Die Farben blau und grün stehen für zwei an sich identische Umgebungen, die zum Deployment bereitstehen. Während also beispielsweise grün aktiv ist, kann ein Deployment auf blau durchgeführt werden. Sobald der Prozess erfolgreich abgeschlossen ist, kannst du die aktive Umgebung wechseln. Sollte es dann doch zu Fehlern nach dem Release kommen, kannst du die Server wieder auf die vorangegangene Umgebung zurückstellen, ohne dass es zu langen Ausfällen kommt. Beim nächsten Release spielst du dieses wieder auf der nun inaktiven Umgebung, in unserem Beispiel grün, ein und stellst den Traffic anschließend auf die neueste Version um.
Auch nach dem Deployment können Skripte die Qualität des Produkts überwachen, Fehler abfangen und Logs zu Laufzeitvariablen anfertigen.
Fazit
Eine gute Deployment Pipeline bietet in der Projektentwicklung vor allem zwei Dinge: Geschwindigkeit und Flexibilität. Es lohnt sich also, sich von Anfang an mit den Anforderungen des eigenen Projekts auseinander zu setzen und die Zeit zu investieren, eine maßgeschneiderte Deployment Pipeline aufzusetzen. Deine anfängliche Investition zahlt sich langfristig allemal aus und wird mit höherer Produktqualität sowie schnellerer Entwicklung belohnt.
Wobei können wir dich sonst noch unterstützen?
Neues Projekt
Du hast eine Idee für eine digitale Lösung und suchst einen Partner, der dich begleitet?
Verstärkung für dein Projekt
Du hast bereits eine Anwendung und suchst Verstärkung in der Entwicklung?
