Kapitel 5. Wie man Continuous Integrationund Continuous Delivery einrichtet
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
In Kapitel 4 hast du verschiedene Werkzeuge kennengelernt, die Entwicklern bei der Zusammenarbeit helfen, darunter Versionskontrolle, Build-Systeme und automatisierte Tests. Aber es reicht nicht aus, eine Sammlung von Tools zu haben. Du musst auch wissen, wie du sie zu einem effektiven Software Delivery Lifecycle (SDLC) zusammensetzt. Jedes Unternehmen hat seinen eigenen SDLC, von denen einige besser funktionieren als andere.
Bei LinkedIn zum Beispiel basierte unser SDLC vor Project Inversion (über das du im Vorwort gelesen hast) auf einemRelease Train-Modell: alle zwei Wochen verließ ein "Zug" den Bahnhof mit neuem Code, der für die Produktion bestimmt war. Damals arbeiteten die Teams in isolierten Feature Branches, und um auf den Zug zu kommen, musste man seinen Code in einen Release Branch bringen. Einige Wochen vor einer geplanten Veröffentlichung führten wir die Integration durch, indem wir die Funktionszweige zu einem Veröffentlichungszweig zusammenführten, gefolgt von der Bereitstellung, d.h. dem Ausrollen des Veröffentlichungszweigs in die Produktion.
Der Integrationsprozess stieß häufig auf Probleme. Wenn Dutzende von Funktionszweigen zusammenkamen, mussten die Entwickler feststellen, dass sie monatelang auf der Grundlage falscher Annahmen kodiert hatten. Die API, ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access