DevOps-Lexikon: Die Deployment-Pipeline

In manchen Post habe ich bereits den Begriff der Deployment-Pipeline benutzt. Heute wollen wir darauf näher eingehen.

Die Deployment-Pipeline, die erstmals durch Jez Humble und David Farley in ihrem Buch “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation” definiert wurde, stellt sicher, dass jeglicher Code, der in die Versionsverwaltung eingecheckt wird, automatisch gebaut und in einer produktivähnlichen Umgebung getestet wird.

Dadurch finden wir Build-, Test- oder Integrationsfehler schon mit der Einführung einer Änderung, sodass wir sie sofort beheben können. Machen wir das richtig, können wir immer sicher sein, dass sich unser Code in einem deploy- und auslieferbaren Zustand befindet.

Um das zu erreichen, müssen wir automatisierte Build- und Testprozesse schaffen, die in dedizierten Umgebungen laufen. Unsere Build- und Testprozesse können jederzeit laufen – unabhängig von den Arbeitsgewohnheiten einzelner Techniker/ Operations.

Ein getrennter Build- und Testprozess stellt sicher, dass wir alle Abhängigkeiten kennen, die zum Bauen, Verpacken, Ausführen und Testen unseres Codes notwendig sind (so werden wir das Problem »es hat auf dem Entwickler-Laptop funktioniert, stürzt aber im Produktivumfeld ab« los).

Wir können unsere Anwendung verpacken, um die wiederholte Installation von Code und Konfiguration in einer Umgebung zu ermöglichen, alternativ lassen sich auch frameworkspezifische Packaging-Systeme einsetzen. Statt den Code in Paketen zu verstauen, können wir uns auch dafür entscheiden, unsere Anwendung in deploybaren Containern unterzubringen.

Umgebungen werden damit konsistent und wiederholbar produktivähnlicher.

Leave Comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.