Die Verbindung von Development und Operations (DevOps) ist in modernen, agilen Entwicklungsprojekten nicht mehr wegzudenken. In klassisch geführten Projekten sind Business-Analyse, Development und Betrieb in der Regel in separierten Abteilungen aufgestellt, die unabhängig voneinander arbeiten, allerdings in massiver Abhängigkeit zueinander stehen. Folgen davon sind lange Produktentwicklungszyklen, ein spätes User-Feedback und daraus resultierend explodierende Kosten.
Um diesem Problem zu begegnen, wird häufig die klassische Projektstruktur aufgebrochen und eine agile Arbeitsweise eingeführt. Dabei werden operative Rollen wie Business Analyst und Developer in einem Team vereint, um iterativ Software am Bedarf des Kunden auszurichten. Das Bestreben einer agilen Arbeitsweise ist es, die vollständige Produktverantwortung zu übernehmen. Eine vollständige Produktverantwortung kann aber erst dann übernommen werden, wenn ein Team in der Lage ist, seine Applikation auf einer Plattform selbstbestimmt zu betreiben. In großen Unternehmen ist die Betreuung der Infrastruktur und die Aktualisierung von Applikationen meist zentral über ein Buildmanagement organisiert. Dies führt häufig zu einem Bottleneck an zentraler Stelle und einem Release-Stau. Um den Stau effektiv aufzulösen, wird die Verantwortung für das Build- und Releasemanagement in die agilen Teams hinein verlagert. Das Development-Team übernimmt damit auch Aufgaben und Verantwortlichkeiten von Operations und entwickelt sich dadurch zu einem DevOps-Team.
Erst damit sind die Teams in der Lage, vollständige Verantwortung für Ihr Produkt zu übernehmen, da sie nun alle Schritte des Application Lifecycle Management (ALM) in ihrer eigenen Verantwortung haben. Damit einher geht die Auflösung von zentralisierten Release-Zyklen, in denen alle Änderungen aller Teams zeitgleich installiert werden, hin zu einem bedarfsgerechten zeitnahen Deployment durch das jeweilige Team.
Durch das Verankern der DevOps-Philosophie in agilen Teams werden schnellere Release-Zyklen qualitativ hochwertiger und robuster Softwarepakete erreicht. Mit dem alleinigen Ownership für die eigene Software übernimmt das Team die vollständige Ende-zu-Ende-Verantwortung bis hin zum Live-System.
Software-Bereitstellung mit Pipelines
Automatisierung dank Continuous Integration / Continuous Delivery / Continuous Deployment
Die Verschmelzung von Operations und Development verändert das Releasemanagement grundlegend. In klassischen Organisationen wird das Releasemanagement meist von einer zentralen Stelle verantwortet und umgesetzt. Beim agilen Ansatz wandern die entsprechenden Aufgaben in die Umsetzungsteams hinein, die letztlich dadurch zu einem DevOps-Team werden.
Ein zentraler Bestandteil hierbei ist es, das Build- und Releasemanagement in den Teams zu verantworten. Sie sind nun selbst dafür verantwortlich, ihre Software zu bauen und das daraus resultierende Build-Artefakt auf einer Umgebung bereitzustellen (Deployment). Eine Aufgabe, die im ersten Moment einschüchternd auf Teams wirken kann, da sie meist Tätigkeiten umfasst, die für das gesamte Team Neuland sind.
Automatisierung
Das höchste Ziel von agilen Teams ist das Schaffen von User Value. Routinetätigkeiten sollen deshalb idealer Weise automatisiert werden, um den Fokus der Teams nicht zu stören.
Eine Software zu bauen (build) und das Build-Artefakt anschließend weiterzuverarbeiten, muss deterministisch sein, also immer in den gleichen Arbeitsschritten und in der immer gleichen Reihenfolge erfolgen. Die sequenzielle Abfolge der Arbeitsschritte wird auch Build-Pipeline (oder kurz: Pipeline) genannt.
Continuous Integration
Bei Continuous Integration (CI) geht die Automatisierung noch einen Schritt weiter. Spezielle Build-Systeme, wie Jenkins, TeamCity oder Azure DevOps sind dafür zuständig, Build-Pipelines selbstständig auszuführen. Dafür sind sie mit der Quellcode-Verwaltung (z.B. GitHub) verbunden und starten automatisch die Pipeline, sobald eine Quellcodeänderung festgestellt wurde.
Somit hat das Team einen automatischen Feedback-Cycle, der aufzeigt, ob ihre Software mit der aktuellen Codeänderungen noch korrekt funktioniert, da ein integraler Bestandteil von Pipelines immer die Ausführung von definierten Tests ist.
Am Ende der Continuous Integration entsteht nach einem erfolgreichen Lauf der Pipeline immer eine neue Version der Software (Artefakt). Diese kann dann auf einem Zielsystem installiert werden.
Continuous Delivery
Continuous Delivery (CD) beschreibt das Installieren eines Artefakts auf einem Zielsystem. Es ist üblich, dass eine neu gebaute Version automatisch auf einem Testsystem eingespielt wird, damit explorative Tests stattfinden können. Deshalb werden Continuous Integration und die erste Continuous-Delivery-Stage meist in einer einzigen Pipeline abgebildet. Nach erfolgreichem Bauen der neuen Version wird diese dann auf dem Zielsystem direkt installiert.
In der Regel durchläuft ein Artefakt mehrere Testsysteme (Stages), bis es auf eine Produktions-Umgebung gespielt und dem Endanwender zur Nutzung bereitgestellt werden kann.
Continuous Deployment
Der Schritt vom letzten Testsystem hin zur Produktionsumgebung wird als Continuous Deployment (CD) bezeichnet. Eine Besonderheit beim Continuous Deployment ist, dass im Moment der Bereitstellung noch Endanwender auf der Plattform aktiv sein können. Deshalb ist es wichtig, die richtigen Deployment-Strategien anzuwenden, um die Software so sanft wie möglich für den Endanwender bereitzustellen. Hier haben sich Blue/Green- und Canary-Deployment bewährt.
Wrap up
Gemeinsam mit Ihnen gestalten wir maßgeschneidert Build- und Deployment-Pipelines. Für einen definierten Zeitraum unterstützen wir Sie direkt in Ihren Teams und festigen so das Verständnis für Build-Systeme, Pipelines und Staging-Konzepte. Wir treten mit dem Ziel an, Ihre Teams soweit zu befähigen, dass sie die Pflege der Pipelines selbständig und ohne externe Unterstützung durchführen können.
Monitoring
Den Zustand der Anwendung stets im Blick
Ein DevOps-Team ist für den operativen Betrieb seiner Anwendung selbst verantwortlich. Dazu gehört neben dem Deployment auch die Überwachung der Applikation im Live-Betrieb.
Dabei genügt es nicht, bei einer eintreffenden Fehlermeldung in eine Log-Datei zu schauen. Im Idealfall bemerkt das Team bereits Auffälligkeiten oder verändertes Verhalten der eigenen Anwendung noch vor dem Nutzer. Zu diesem Zweck existieren aktive und passive Überwachungssysteme, die automatisiert Daten aus der Anwendung auswerten. Spezielle Visualisierungswerkzeuge bilden das Applikationsverhalten für ein definiertes Zeitfenster ab. Verhält sich die Anwendung in dem Zeitraum auffällig, können automatisch definierte Aktionen ausgelöst werden. Darunter fallen Benachrichtigungen über Messaging-Dienste oder akustisch-visuelle Signale. Schwellwerte helfen dabei, adäquate Benachrichtigungen für die eintretende Situation anzustoßen.
Erst mit einem entsprechenden Monitoring ist es einem Team möglich, den Betrieb einer Applikation verantwortungsvoll zu übernehmen. Es muss jederzeit in der Lage sein, die Funktionsfähigkeit der eigenen Anwendung einzusehen.
Korrektes und adäquates Monitoring aufzubauen, ist eine Aufgabe, die Zeit und Erfahrung braucht. Die Applikation selber muss in vielen Fällen erweitert sowie angepasst werden. Zudem müssen Erfahrungen für sinnvolle Metriken und Schwellwerte gesammelt werden. Wir begleiten Sie und Ihr Team bei der Einführung von sinnvollem Monitoring für Ihre Applikationen. Gemeinsam implementieren wir Messpunkte und Log-Ausgaben und verbessern langfristig die Qualität des Monitorings.
Coaching
Die DevOps Philosophie verankern
Die DevOps-Philosophie in einem Team erlebbar zu machen und zu verankern ist oft eine Herausforderung, die sogar zu einer Überforderung des Teams führen kann.
Wir glauben, dass das beste Training in konkreten Projekten stattfindet. Dennoch ist es wichtig, im Vorfeld Kontext und Theorie anhand von Praxisbeispielen zu erlernen, um im Projektalltag Situationen richtig einordnen zu können. Ein gezieltes Coaching in Form von Workshops ist ein guter Einstieg in die Materie, wird aber selten alleinig die maßgeschneiderte Antwort auf alle Situationen im Projekt liefern können.
Deshalb begleiten wir Sie über unsere teamübergreifenden Workshops hinaus. In einem definierten Zeitraum werden unsere Experten in Ihre Teams integriert und bilden Ihr Team on the Job weiter aus. Dabei leiten sie an und helfen bei der Problemanalyse. Ziel unserer Experten ist es, zum Ende ihres Coachings ein funktionierendes Team zu verlassen, welches DevOps-Aufgaben wie Continuous Integration, Continuous Delivery, Continuous Deployment, Monitoring, Cloud Stack etc. gewachsen ist.
CloudOps und DevOps
Die Rolle der Administration neu gedacht
Unternehmen betreiben in der Regel nicht nur eine Software. Ihr System setzt sich meist aus mehreren Softwareteilen zusammen, die miteinander interagieren und harmonieren müssen. Daraus ergeben sich zentrale Vorgaben und Regeln, die von allen Teams eingehalten werden müssen.
DevOps-Teams sind verantwortlich für alle Belange die eigene Software betreffend. Das CloudOps-Team kümmert sich um übergreifende Themen, die für mehrere Teams oder gar das gesamte Unternehmen relevant sind. Häufig fallen in den Aufgabenbereich von CloudOps kritische und sensible Infrastrukturkomponenten, wie die Konfiguration von Firewalls, Netzwerkmanagement, DNS und Routing. Somit bildet ein CloudOps-Team eine unterstützende Einheit für die DevOps-Teams, indem es zentrale Konfigurationsanpassungen für sie vornimmt und diese zügig bereitstellt, damit die DevOps-Teams ausfallfrei arbeiten können. Dazu können Build-Server, Git-Repo und Elastic-Search-Cluster gehören. Die operative Nutzung von Komponenten, wie einem Build-Server, obliegt nach wie vor den Teams, die vollen Zugriff auf ihre Bereiche haben. Die Wartung des Build-Servers hingegen übernimmt das CloudOps-Team. Es ist der Enabler für die Teams aus der Infrastrukturperspektive.
Gemeinsam mit Ihnen erarbeiten wir ein zugeschnittenes Konzept und unterstützen das CloudOps-Team bei der Ausgestaltung ihrer Rolle. Erfahrung ist hier besonders wichtig, um das richtige Mindset und die neue Rolle als Befähiger von Development Teams zu vermitteln. Wir begleiten Sie dabei.
Unsere Kunden
Seit mehr als 35 Jahren entwickeln wir individuelle Softwarelösungen und gestalten nachhaltig den Fortschritt. Kurzfristige Erfolge sind dabei nicht unser einziges Ziel. Wir legen unseren Fokus auf nachhaltige Beziehungen und ein partnerschaftliches Verhältnis. Vertrauen und Kompetenz sind dafür grundlegende Eigenschaften und Transparenz ist Teil unseres agilen Konzepts. Wir bedanken uns bei unseren Kunden für die vertrauensvolle Zusammenarbeit.
VOLLSTÄNDIG DIGITALE ANTRAGSSTRECKE
Full-Stack-Entwickler in der Versicherungssparte Kraftfahrt
Zur Case Study
Unser Kunde hatte den Wunsch, die Digitalisierung im Unternehmen durch diverse Projekte und Umstrukturierungen voranzutreiben. Dazu gehörte ebenfalls die Entwicklung neuer Prozesse, moderner Vertriebswege und Apps. Eine der Anwendungen war eine rein digitale und besonders kundenfreundliche Antragsstrecke in der Versicherungssparte Kraftfahrt.
Der von uns in dem Projekt eingesetzte Full-Stack-Entwickler setzte sie im agilen Team eines Innovationszentrums des Unternehmens mit um.
Ihr Ansprechpartner
Christian Aschoff
Senior IT Consultant
