Voraussetzungen für Continuous Delivery (CD)
Während viele Unternehmen bereits gut vorbereitet sind, müssen andere Firmen noch Teile ihrer Organisation und Implementierungsansätze ändern und verbessern, bevor sie mit den ersten Schritten zu CD beginnen. Werfen wir einen Blick auf die Voraussetzungen, bevor wir mit der Einführung der wesentlichen Konzepte von CD fortfahren.
Der organisatorische Teil von CD
Ich möchte hier nicht ins Detail gehen, da dies ein Tech-Blog ist, aber es gibt organisatorische Einschränkungen, die Ihnen bei der Einführung von CI/CD Probleme bereiten könnten. In vielen Unternehmen gab es eine Trennung zwischen Entwicklung und Betrieb. Wenn Ihr Unternehmen immer noch den Ansatz hat, Software Pakete von der Entwicklungsabteilung über den „Zaun“ zu Operations zu schmeißen, dann werden Sie Schwierigkeiten haben, selbst einfache CI-Mechanismen einzuführen. Wenn Ihr Unternehmen bereits auf grundlegende DevOps-Konzepte umgestellt hat, dann sollte Ihnen die Umstellung einfacher fallen. Sie sollten in der Lage sein, die folgenden Fragen mit JA zu beantworten, um auf der organisatorischen Seite alle Voraussetzungen für die Implementierung von CI und CD zu schaffen:
- Arbeiten Entwickler und Operations-Experten in einem Team oder arbeiten sie zumindest eng zusammen?
- Hat Ihr Team Zugriff auf CI/CD-Tools und darf Builds und Bereitstellungen für Test- und Staging-Umgebungen selbst durchführen?
- Arbeiten Sie nach agilen Entwicklungsmethoden, die es ermöglichen, Software zumindest theoretisch regelmäßig zu releasen?
Mehrere Umgebungen und Entwicklungs-Stages
Um CI/CD zu ermöglichen, müssen mehrere Umgebungen verfügbar sein. Von der lokalen Entwicklungsumgebung für die Entwickler bis hin zur offiziellen Produktionsumgebung kann es verschiedene Umgebungen geben. Es hängt von den Bedürfnissen des Projekts oder des Produkts ab, aber im Allgemeinen ist mindestens eine Entwicklungs-, Test- und Staging-Umgebung erforderlich.
Wenn mehrere Umgebungen vorhanden sind, kann jede für weitere Tests und Integration der Software verwendet werden. Mit jedem Schritt wächst die Reife des Deployment Packages und das Risiko für den Release in Produktion sinkt.
Gut definierte Quality Gates von Stage zu Stage
Um sicherzustellen, dass die Qualität von Stage zu Stage zunimmt, müssen gut definierte Quality-Gates und -Tests implementiert werden. Zu Beginn können die Tests und Kontrollen manuell sein - aber sie müssen jedes Mal ausgeführt werden. Keine Ausnahmen - keine schnelles direktes Release in die Produktion. Auf dem Weg zu CD müssen mehr und mehr Schritte der Quality Gates automatisiert werden. Quality Gates können Komponenten- und Integrationstests, Data Quality Checks, nichtfunktionale Tests, Code Quality Checks und mehr umfassen.
Alle Dokumente müssen eingecheckt sein
Eine der Grundvoraussetzungen für CI/CD ist ein gut integriertes Versionskontrollsystem (CVS) - vorzugsweise eine GIT Distribution. Eine generelle Regel ist zu befolgen: jede Datei, jede Konfiguration, jedes Stück Code oder andere Dinge, die für das Funktionieren der Software relevant sind, müssen eingecheckt werden. Dies ist sehr wichtig. Dadurch garantieren Sie, dass Ihre Tags und Branches alles Notwendige enthalten.
Anspruchsvoller aber ebenso wichtig ist es, größere Systeme in verschiedene Repositories und Ordnerstrukturen aufzuteilen. Es gibt keine allgemeine Regel, aber Sie sollten verschiedene Repositories für verschiedene Systeme und unabhängige Komponenten wie Microservices verwenden. Wenn andererseits eine Datenbank ein wesentlicher Teil eines (Micro-)Services ist, sollten sich die Skripte zum Erstellen und Füllen der Datenbank im selben Repository befinden wie der Microservice. Das Verwalten von Komponenten/Systemen in verschiedenen Repositories führt zu einer losen Kopplung, die es uns ermöglicht, sie unabhängig voneinander zu implementieren.
Klare Regeln für Branching und Feature Switches
Damit CI/CD funktionieren kann, müssen Entwickler mindestens einmal am Tag einchecken – und zwar bevorzugt in den Master Branch. Auf der anderen Seite muss die Codebasis immer in einem Working State sein. Daher müssen Entwickler wissen, wie sie gegen den Master Branch entwickeln können oder wenn nötig mit Release-, Feature- oder Team-Branches umgehen sollen. Aber noch wichtiger: Sie müssen wissen, wie sie Features entwickeln und einchecken können, ohne bestehende Funktionen in Mitleidenschaft zu ziehen. So können Entwickler z.B. Feature Switches für unfertige, neue Funktionen für vorhandene Komponenten verwenden, um sie zu deaktivieren, bis sie für die Veröffentlichung bereit sind.
Alles bereit?
Wenn die Voraussetzungen Sie nicht zu sehr beunruhigen, dann würde ich sagen, dass Sie bereit sind, tiefer in CI/CD einzutauchen. Im nächsten Blog Post werden wir die Grundlagen von CI/CD besprechen und anfangen, an unserer Delivery Pipeline zu arbeiten.
