Schriftliche DevOps-Schulung

Wie gestalten Sie Ihre Pipeline für Continuous Delivery und Deployment?

In vielen Organisationen, vermutlich auch in Ihrer, programmieren Entwickler isoliert in getrennten Branches. Diese Arbeitsweise scheint die individuelle Produktivität zu fördern, schadet jedoch der Produktivität des Teams.

Getrennte Branches erschweren das Zusammenführen von Code mehrerer Entwickler. Damit die verschiedenen Codebestandteile zusammenarbeiten und Ihren Kunden Funktionen und Vorteile bieten, müssen meist mehrere Entwickler mitwirken, viel nacharbeiten und Konflikte lösen, die längst hätten geklärt werden müssen.

Ohne kontinuierliche Integration wird die Herausforderung größer

Weil das Zusammenführen von Code anstrengend und anspruchsvoll ist, tun es viele Entwicklungsteams leider erst, wenn sie ihre Anwendung an Integrations- oder Abnahmetester übergeben. Das verschärft das Problem. Sie machen die Qualitätssicherung allein dafür verantwortlich, dass die gemeinsam erstellte Software funktioniert und sich integrieren lässt. Das erklärt, warum Projekte sich verzögern, Budgets massiv überschritten werden, Stimmung und Motivation leiden und Ziele und Zusagen verfehlt werden. Unternehmen weltweit verschwenden jährlich rund 600 Milliarden USD für nicht budgetierte und ungeplante IT-Arbeit, also für Nacharbeit und Behelfslösungen.

Wie hilft trunkbasierte Entwicklung (Entwicklung im Hauptbranch)?

Die Lösung ist trunkbasierte Entwicklung in Verbindung mit kontinuierlicher Integration und Testautomatisierung. Dabei arbeiten Entwickler in der Versionsverwaltung gemeinsam an einem einzigen Branch, dem Trunk. Sie widersetzen sich dem Druck, weitere langlebige Entwicklungsbranches anzulegen.

Trunkbasierte Entwicklung ist die Grundlage für Continuous Integration und damit auch für Continuous Delivery. Wenn Entwickler ihre Änderungen mehrmals täglich in den Trunk übernehmen, lässt sich die zentrale Anforderung von Continuous Integration leicht erfüllen: Jedes Teammitglied führt mindestens alle 24 Stunden einen Commit im Trunk durch. So bleibt die Codebasis jederzeit auf Abruf auslieferbar und Continuous Delivery wird praktisch möglich.

Mit Continuous Integration liefern Sie kleinere, bereitstellbare Codepakete

Häufige Check-ins ermöglichen kleine Entwicklungs- und Lieferpakete. Das verbessert die Qualität und erleichtert die Lösung von Problemen und Konflikten. Tägliche Check-ins motivieren das Team, sinnvolle, bereitstellbare Codepakete zu erstellen, ohne Continuous Integration und Continuous Delivery zu beeinträchtigen. Aktualisierungen im gemeinsamen Quellcode-Repository geben Ihnen und Ihrem Team außerdem Gelegenheit zu schneller Abstimmung, schnellen Entscheidungen und unmittelbarem Feedback.

Bei jedem Check-in führt Ihre Continuous-Integration-Umgebung automatisierte Tests für Funktionen aus, die vom geänderten Modul abhängen oder betroffen sind. Wenn etwas nicht mehr funktioniert, muss die Person, die den Check-in vorgenommen hat, den Fehler mit höchster Priorität beheben. Nichts ist jetzt wichtiger, damit der Rest des Teams seine Arbeit weiter in den Trunk integrieren kann. Bis der fehlerhafte Check-in korrigiert oder zurückgenommen wurde, darf in diesem Modul des Trunks kein weiterer Check-in erfolgen. So schützen Sie Stabilität und Zuverlässigkeit.

Wenn Sie diesen DevOps-Grundsatz anders sehen, beantworten Sie diese Frage: Warum sollten Sie weiteren Code in ein Modul aufnehmen, das bereits Fehler enthält?

Dafür kann es gute Gründe geben. Achten Sie aber darauf, dass keine technischen Schulden entstehen und sich Behelfslösungen nicht stapeln.

Geprüfte Commits als zusätzliche Absicherung für die trunkbasierte Entwicklung

Alternativ kann Ihr DevOps-Team auf geprüfte Commits (Gated Commits) setzen, um die Qualität zu steigern und den Trunk zusätzlich abzusichern.

Wenn ein Entwickler Code einchecken möchte, wird er zuerst automatisch getestet. Erst nach erfolgreicher Prüfung wird der Code offiziell in den Trunk übernommen.

Nutzen Sie in jeder Phase Ihres Software-Wertstroms produktionsnahe Umgebungen

In vielen IT-Organisationen unterscheiden sich Produktion und Vorproduktion, etwa Entwicklung, Integration und Test. Betriebssysteme, Datenbanken, Drittanbieterwerkzeuge und APIs können unterschiedlich konfiguriert sein oder verschiedene Versions- und Patchstände haben. Auch Ihr eigener Code kann in unterschiedlichen Versionen über diese Umgebungen verteilt sein. Schon geringfügige Unterschiede bei der JVM-Version können darüber entscheiden, ob ein Produktions-Deployment gelingt. Wenn Sie Ihre Umgebungen nicht vollständig kontrollieren und nicht wissen, was sie enthalten, können Sie ihre Ergebnisse nicht vorhersagen.

Machen Sie Umgebungsverwaltung zum Teil Ihrer täglichen Entwicklung und Bereitstellung

Vorproduktionssysteme sollten Ihre Produktionssysteme nachbilden. Ermöglichen Sie Ihrem Team, Umgebungen bei Bedarf automatisiert im Self-Service einzurichten. So kann es seine tägliche Entwicklungsarbeit sicher in produktionsnahen Umgebungen ausführen.

Der IT-Wertstrom Ihrer Organisation schafft Nutzen sowohl durch den Softwarecode als auch durch die Umgebungen, in denen er läuft. Entwicklungs- und Betriebsfachleute sollten beide gleich wichtigen Bausteine des Wertstroms berücksichtigen:

1. Code für Software, die internen und/oder externen Kunden Nutzen bringt.
2. Code für die Vorproduktions- und Produktionsumgebungen, in denen die Software ausgeführt wird.

Steuern Sie Software und Umgebungen aus einer verbindlichen Quelle, dem Trunk
(auch Infrastructure as Code, IaC, genannt)

Mit DevOps gehört der Aufbau von Vorproduktions- und Produktionsumgebungen zu Ihrem Trunk. Das entspricht der reinsten Form von Infrastructure as Code (IaC). Entwicklung und Betrieb bauen Ihre Infrastruktur gemeinsam als Code auf. Ein abgeschottetes Betriebsteam kennt die Besonderheiten der Software, die darauf laufen soll, oft kaum.

Speichern Sie den Code für Software und Umgebungen in einer gemeinsamen verbindlichen Quelle, dem Trunk. So behandeln Sie beide als gleich wichtig.

Damit Sie die gesamte Vorproduktion und Produktion sowie Ihre Deployment-Pipeline mit kontinuierlicher Integration und Bereitstellung aufbauen können, speichern Sie im Versionsverwaltungssystem neben dem Softwarecode auch die benötigten Konfigurationen, Skripte und alles Weitere für die durchgängige Bereitstellungskette. Wollen Sie eine Konfiguration dauerhaft ändern, passen Sie die Skripte zum Aufbau der Umgebung an. So muss niemand beim nächsten Erstellen einer Umgebung dieselbe Arbeit wiederholen.

Ausführliche Dokumentation veraltet meist sehr schnell. Investieren Sie Ihre Zeit lieber darin, die Skripte für den Umgebungsaufbau aktuell zu halten. Ohne Self-Service-Umgebungen auf Abruf bleibt Ihre Cloud-Infrastruktur eine schlecht ausgelastete Hostingplattform und Ihre DevOps-Initiative ein wenig genutzter Versuch der Prozessverbesserung. Sie sollten ganze Produktions- und Vorproduktionsumgebungen aus der Versionsverwaltung erstellen können. Mit DevOps ist es leichter und schneller, Umgebungen neu aufzubauen, als sie zu reparieren. Manuelle Änderungen sind nicht mehr zulässig. Nur Code und Konfiguration sollten Ihre Umgebungen aufbauen, konfigurieren und starten.

Sie brauchen eine neue Definition of Done (DoD)

Sobald Continuous Delivery und Deployment-Pipeline laufen, müssen Sie neu festlegen, wann Arbeit laut Definition of Done (DoD) abgeschlossen ist.

Eine Aufgabe gilt nun als „fertig“, wenn die zugehörigen Kundenfunktionen und Vorteile

• automatisch oder mit einem Klick aus dem Trunk erstellt wurden,
• in produktionsnahen Umgebungen mit automatisierten Tests geprüft wurden,
• in produktionsnahen Umgebungen demonstriert wurden,
• zur Bereitstellung bereitstehen oder idealerweise bereits automatisch oder mit einem Klick in laufenden Produktionsumgebungen bereitgestellt wurden.

FAZIT

Mit DevOps integrieren Sie Code während der täglichen Arbeit. Entwicklungs- und Betriebsteams sowie Fachleute für Informationssicherheit proben das Deployment ihrer Arbeit schon während des Softwarelebenszyklus immer wieder. Dadurch gelingen Live-Deployments eher reibungslos.

Mit Continuous Integration steigen auch der Geschäftsdurchsatz, die Stabilität von Software und Umgebungen sowie die Arbeitszufriedenheit. Interne und externe Kunden profitieren von einer höheren Servicequalität.