Team entwickelt mit einer Deployment Pipeline neue Features schnell und zuverlässig

Was bringt dir eine Deployment Pipeline?

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?

Artikel teilen

Mehr aus unserem Blog

5 Jahre Lean Ocean – Das Interview

Vor 5 Jahren ist Lean Ocean in einem WG-Zimmer gestartet. Und heute hat das Unternehmen nichts von seinem Startup Flair verloren – nur die Büros sind schicker geworden.
Im Video-Interview werfen unsere Geschäftsführer Oliver und Stephan zusammen einen Blick auf die Entwicklung von Lean Ocean, gemeinsame Meilensteine und was die Arbeit bei Lean Ocean prägt.

Ein Tag als Softwareentwickler bei Lean Ocean

Was macht eigentlich ein Softwareentwickler bei Lean Ocean und wie sieht ein üblicher Arbeitstag aus? Das erzählt dir Norbert im folgenden Blogartikel! Wir haben Norbert, einen unserer Developer, einen Tag lang begleitet und über die Schulter geschaut. Vom ersten Kaffee zum wohlverdienten Feierabend– hier erhältst du spannende Einblicke in einen abwechslungsreichen Arbeitstag.

Von der Idee zum Feature

Wie sieht es eigentlich bei Lean Ocean hinter dem Code aus? Wie läuft so ein Projekt ab und wie wird aus einer Idee dann ein richtiges Feature? In diesem Artikel beantworten dir Oliver und Tom die wichtigsten Fragen zu unserem brandneuen Format #behindthecode. Als erstes geht Oliver als CTO von Lean Ocean auf den Entwicklungsprozess von Features ein und dann gibt uns unser Projektmanager Tom noch ein paar Antworten.

Picture of Oliver Holz

Oliver Holz

holz@lean-ocean.com