Agile & DevOps

DevOps-Fallstricke und wie man ihnen entkommen kann

Die DevOps-Challenge
Keine Kommentare

Noch vor einigen Jahren wurde die IT in Unternehmen als notwendiges Übel wahrgenommen. Doch in Zeiten von digitalen Geschäftsmodellen und Produkten haben Unternehmen den wahren Wert dieses Bereichs erkannt. Das birgt jedoch eine Menge neuer Herausforderungen, denn der Wettbewerbsdruck steigt stetig und die Entwicklungszyklen werden immer kürzer. DevOps scheint das Allheilmittel zu sein, der Weg dorthin ist aber steinig.

Das „Digital Mindset“ hat unlängst Einzug in große deutsche Konzerne gehalten. Das zeigen diverse Studien und dass die Notwendigkeit erkannt wurde, einen neuen Platz in der Führungsetage für den Chief Digital Officer (CDO) zu schaffen. Der CDO soll Unternehmen erfolgreich durch die digitale Transformation führen. Denn der Wettbewerbsdruck wächst zunehmend und immer mehr Firmen setzen auf die Entwicklung digitaler Produkte und Services. Wer nicht Opfer der Disruption werden möchte, muss sich diesem Trend anschließen und der Konkurrenz immer einen Schritt voraus sein. Interessanterweise beschränkt sich diese Entwicklung nicht nur auf einzelne Branchen, sondern ist nahezu in allen Marktsegmenten erkennbar. Wer hätte vor fünfzehn Jahren schon gedacht, dass Unternehmen aus dem Bereich Automotive einmal Unsummen in die Entwicklung und Bereitstellung digitaler Services investieren würden?

Ein gutes Beispiel hierfür ist der Car-Sharing-Dienst DriveNow des Automobilherstellers BMW. Durch das Car-Sharing-Angebot verlängert sich einerseits die Wertschöpfungskette hin zum Kunden, auf der anderen Seite lassen sich wertvolle Benutzerdaten sammeln. Wie lukrativ Servicemodelle sein können, zeigen Unternehmen wie myTaxi, HRS oder Uber. Diese Firmen sind weder im produzierenden Gewerbe tätig, noch besitzen sie physische Güter. Sie fungieren lediglich als Serviceprovider und bieten die Plattform zur Vermittlung von Dienstleistungen. Doch sind es oftmals diese Unternehmen, die durch hohe zweistellige Wachstumszahlen brillieren und schnell einen Milliardenwert auf die Börsenwaage bringen. Um ein solches produktgetriebenes Wachstum zu erreichen, ist es erforderlich, extrem schnell und agil auf Veränderungen und Anforderungen reagieren zu können. In dieser Disziplin sind die oft „Tanker-ähnlichen“, in Silos organisierten Großunternehmen ganz klar unterlegen.

Letztendlich ist jedoch alles eine Frage der Strategie und des Willens. Im Jahr 2018 hat Klaus Straub, CIO bei BMW, angekündigt, das Unternehmen im Rahmen einer agilen Transformation ganz klar in Richtung Produktorientierung bzw. Agile Operating Model auszurichten. Unter dem Motto „100 % agil“ ist das erklärte Ziel, bis Ende 2019 nicht nur sämtliche laufende IT-Projekte des Unternehmens auf agil umzustellen, sondern auch die IT-Organisation vollumfänglich nach agilen Prinzipien auszurichten. Ein zwingendes Erfordernis stellt die enge Zusammenarbeit zwischen Fachbereichen und der IT-Abteilung dar.

Aber auch hinter den Mauern der IT ist ein enger Schulterschluss gefragt. Gemeint ist damit natürlich DevOps – die Verschmelzung von Entwicklung und Betrieb. Das Schaffen einer DevOps-Kultur ist jedoch viel mehr als nur das Vorhaben, Abteilungen und Bereiche zusammenzuführen. Es handelt sich vor allem um eine Revolution im Kopf aller Beteiligten, einen Umdenkprozess, der von höchster Ebene angeregt werden muss. Vor allem ist es wichtig, die so häufig im Kopf existierenden Silos abzureißen. Doch was genau bedeutet das?

Stellt man sich einmal den klassischen Entwicklungsprozess vor, läuft es meist so, dass die Fachabteilung mit einem Anforderungskatalog an den Entwicklungsbereich herantritt. Dieser entwickelt die Software, um sie anschließend an den Betrieb zu übergeben. Das Betriebsteam wiederum stellt dann fest, dass die Software so nicht den Betriebsanforderungen entspricht oder vielleicht auch einfach nur essenzielle Artefakte wie etwa das Betriebshandbuch fehlen. Indes ärgert sich der Fachbereich über die mangelnde Kompetenz der IT und die Verzögerung bei der Inbetriebnahme. Ist die Software an den Betrieb übergeben, lehnt sich die Entwicklungsabteilung oftmals entspannt zurück, denn ihre Bringschuld ist erfüllt. Kommt es im Betrieb einer Applikation zu Problemen, geht das Fingerzeigen erneut los. Der Betrieb beschuldigt die Entwickler, die Entwickler den Betrieb. In großen Unternehmen können diese Extrarunden schon einmal Wochen oder gar Monate an Verzug bedeuten. Ein Zeithorizont, der sich nicht mit einer agilen Strategie und der Verkürzung von Go-to-Market-Zyklen vereinbaren lässt.

In einem DevOps-Szenario übernimmt das Team, bestehend aus Produktmanagern, Entwicklern und Betriebsleuten, gemeinsam die Verantwortung für einen erfolgreichen Ablauf und Betrieb. Alle verfolgen dieselben Ziele und ziehen am gleichen Strang. Welche kritischen Erfolgsfaktoren neben der Kultur noch existieren und welche Tools und Plattformen bei der Einführung von DevOps hilfreich sein können, werden wir im Folgenden betrachten.

Die Säulen des Erfolgs

Auch wenn einige Unternehmen DevOps nur nutzen, um kurzfristige Effizienzvorteile zu erhalten, wird diese Methodik doch mehr und mehr zu einem unverzichtbaren Bestandteil für sämtliche Wirtschaftsbereiche. Zögerliche Unternehmen riskieren mittel- und langfristig ihre Wettbewerbsfähigkeit. Im schlimmsten Fall werden sie Opfer der Disruption und verschwinden vom Markt. Doch auch Unternehmen, die sich unlängst für eine DevOps-Strategie entschieden haben, kämpfen mit der Umsetzung. Unternehmen buhlen mit allen Mitteln um die Gunst der wertvollen Entwicklerressourcen. Keine Entwickler zu finden, ist für moderne Unternehmen existenzgefährdender als der fehlende Zugang zu frischem Kapital an den Finanzmärkten. Umso wichtiger ist es, eine solide und nachhaltige Basis für einen langfristigen Erfolg zu schaffen. Nachfolgend erläutere ich einige der Grundprinzipien von DevOps.

Kultur der Zusammenarbeit: Das A und O einer erfolgreichen DevOps-Strategie ist das Erlangen einer Kultur der Zusammenarbeit. In einer traditionell ausgerichteten IT verfolgen Entwicklung und Betrieb unterschiedliche Ziele mit unterschiedlichen Prioritäten. Die Entwicklung ist meist agiler und benötigt die Freiheit, Änderungen vornehmen zu können, der Betrieb hingegen schwört auf Stabilität. Eine enge Zusammenarbeit dieser Bereiche ist jedoch einer der wichtigsten Aspekte, wenn es um DevOps geht. Das Schaffen eines Informationsaustauschs in Echtzeit ermöglicht es den Teams, einerseits schnelle Änderungen an einer Applikation vornehmen zu können und andererseits eine stabile und robuste Betriebsumgebung zu erhalten. Tools wie etwa Slack, Yammer oder Microsoft Teams können dazu verhelfen, die Hürden einer klassisch formalen E-Mail-Kommunikation abzubauen.

Einhalten von Architekturrichtlinien: Um die Betreibbarkeit, Stabilität und Kompatibilität einer Software zu sichern, ist es wichtig, Leitlinien zu definieren und diesen zu folgen. Enthält eine Applikation beispielsweise viele direkte Abhängigkeiten zu anderen Applikationen, Datenbanken oder anderen Systemen, kann das schnell zu einem hohen Maß an Komplexität führen. Das kann sich wiederum negativ auf Testaufwände, aber auch Key Performance Indicators (KPIs) wie die Deployment Success Rate auswirken. Probleme im Applikationsbetrieb müssen schnell identifiziert und behoben werden. Hierfür ist eine standardisierte Integration von Logging und Monitoring in die Applikation ebenfalls unabdingbar. Oftmals wird im Kontext dieser Design-4-DevOps-Best-Practices von zwölf Faktoren gesprochen, auf die im späteren Verlauf des Artikels eingegangen wird.

Infrastruktur und Plattform: Die Infrastruktur trägt einen maßgeblichen Teil zu einem stabilen Applikationsbetrieb bei und ist eine essenzielle Komponente in DevOps-Szenarien. Häufig kommen Plattformen wie OpenShift, Clound Foundry oder Azure zum Einsatz, die einen sehr hohen Grad der Automation erlauben und als gemeinsame Basis für das DevOps-Team fungieren. Die Entwickler können sich dadurch voll und ganz auf ihre Aufgabe – das Entwickeln – fokussieren. Die Betriebseinheit des Teams kann zum Beispiel die Entwickler durch das Bereitstellen von Infrastrukturtemplates unterstützen.
Dass jede Applikation auf einer einheitlichen Plattform läuft, trägt zu einer allmählichen Effizienzsteigerung bei, da nicht bei jeder Inbetriebnahme einer Applikation erneut darüber diskutiert werden muss, wo sich die Logs befinden, wie Log-Level zu konfigurieren sind oder wie ein Rollback auf eine frühere Applikationsversion durchzuführen ist.

CI/CD Pipeline: Das Verwenden eines zentralen Code-Repositorys ist für Entwickler ein alter Hut und ein wesentlicher Bestanteil von DevOps. Alle Codeänderungen werden regelmäßig in ein zentrales Repository wie etwa Git zusammengeführt. Nach dem Check-in werden diese Änderungen automatisiert erstellt und getestet. Die Hauptziele von Continuous Integration bestehen darin, Bugs möglichst schnell zu entdecken und zu beheben, die Qualität der Software zu optimieren und den Zeitraum bis zum Go-live auf ein Minimum zu reduzieren. Das übergeordnete Ziel ist, die Entwicklerproduktivität zu steigern und „Stupid Work Tasks“ zu eliminieren bzw. zu automatisieren. Das gelingt zum Beispiel durch Testautomatisierung. Nach einem erfolgreichen Build-Prozess lassen sich beispielsweise Unit-, Komponenten-, UI-, Last- oder API-Tests durchführen. Die Ergebnisse fließen wiederum in Reports ein, mit denen sich der Erfolg des Teams messen lässt. Anhand der Resultate kann ebenfalls eine Entscheidungsgrundlage für z. B. ein automatisiertes Deployment geschaffen werden.

Eine hundertprozentige Testautomatisierung ist jedoch nicht realistisch. Die Kunst liegt darin, unter den Test-Tasks zu identifizieren, welche sich leicht automatisieren lassen und einen hohen Mehrwert für das Team schaffen. Erfahrungsgemäß lassen sich ca. 40–60 Prozent aller Testaufgaben automatisieren. Die Integration von Artefakten wie etwa Testautomatisierung bildet den Continuous-Delivery-Teil einer CI/CD Pipeline ab. Gelegentlich wird in diesem Zusammenhang auch von Continuous Deployment gesprochen. Diese zwei Varianten unterscheiden sich lediglich durch das Vorhandensein einer manuellen Genehmigung. Bei Continuous Delivery erfolgt das Deployment zunächst auf eine nicht produktive Test- oder Integrationsumgebung. Nach erfolgreichem Test und einer Freigabe wird das Release dann in die Produktionsumgebung gestaged. Bei Continuous Deployment wird auf diesen zusätzlichen Prüfschritt verzichtet und die Produktionsumgebung unmittelbar aktualisiert.

Erzeugen von Messbarkeit: Damit ein DevOps-Team maximal erfolgreich wird und sich die Erfolge auch belegen lassen, spielt das Erzeugen von Messbarkeit eine große Rolle. Dadurch, dass viele Prozesse zentral und automatisiert ablaufen, lassen sich jede Menge Daten erzeugen, die sich dann wiederum auswerten lassen und aus denen Optimierungspotenziale abgeleitet werden können. Da eine Vielzahl von KPIs existiert, ist eine projektindividuelle Festlegung durchaus sinnvoll, denn nicht jede KPI hat für jedes Projekt die gleiche Relevanz. Gute Beispiele für Metriken im Kontext von DevOps sind die Bereitstellungsfrequenz sowie die Bereitstellungszeit. Ein häufig definiertes Ziel ist es, möglichst viele, kleine Deployments durchzuführen. Dadurch sinken die Testaufwände für ein Release, und potenzielle Fehler lassen sich leicht eingrenzen.

In diesem Zusammenhang spielt natürlich auch die für eine Bereitstellung benötigte Zeit eine große Rolle: Je kürzer die für ein Release benötigte Zeit, desto schneller lassen sich im Fehlerfall Korrekturen auf dem System einspielen. Die allgemeine Servicequalität kann zum Beispiel durch die Verfügbarkeit der Systeme und die Anzahl an Benutzertickets gemessen werden. Im Idealfall werden Störungen und Probleme behoben, bevor sie bis zum Benutzer vordringen, zum Beispiel durch ein intelligentes Application Monitoring. Hierzu eignen sich Tools wie Retrace, Grafana oder App Dynamics, die wiederum eine Vielzahl von Parametern wie etwa Application-Performance, Bandbreiten oder Applikationsfehler überwachen. Neben den hier beispielhaft aufgeführten Metriken existieren natürlich noch eine ganze Reihe mehr KPIs.

Um eine kontinuierliche Verbesserung der Werte zu erreichen, ist es empfehlenswert, einen regelmäßigen Austausch innerhalb des DevOps-Teams anzustreben. Das kann zum Beispiel in Form von Meetings erfolgen, bei denen die Beteiligten darüber sprechen, welche Faktoren sich ihrer Meinung nach besonders negativ auf einzelne KPIs oder den gesamten Service auswirken. Diese Punkte lassen sich dann wiederum gezielt verbessern oder gar eliminieren.

DevOps-kompatible Softwarearchitektur

Da es sich bei DevOps in erster Linie um eine Philosophie handelt und nicht um eine Technologie, ergeben sich vielleicht zunächst Fragen, inwieweit DevOps die zugrunde liegende Technologie beeinflusst oder sie gar voraussetzt. Die im Mittelpunkt stehenden Ziele von DevOps sind meist die Erreichung maximaler Effizienz und größtmöglicher Ökonomie. Um diese Ziele zu erreichen, bedarf es neben dem richtigen Mindset und einer DevOps-kompatiblen Organisation auch der Wahl eines fortschrittlichen Technologiestacks. Die Basis hierfür bildet in der Regel eine DevOps-Plattform wie etwa OpenShift, Cloud Foundry oder Azure DevOps. Diese Plattformen bieten integrierte Funktionen wie ein Containermanagement, die notwendige Containerlaufzeitumgebung, Lastenausgleichsmodule, Integration von Source-Code-Management und Build-Tools, CI/CD Pipelines sowie weitere nützliche Features.

Mit der Festlegung auf eine DevOps-Plattform wird also in gewisser Weise auch die Entscheidung für einen Basistechnologiestack gefällt, der in der Regel auch ein Containerkonzept mit sich bringt. Die aktuell wohl bekannteste Implementierung der Containertechnologie ist Docker, die aufgrund ihrer Einfachheit und Benutzerfreundlichkeit den Begriff überhaupt erst populär gemacht hat. Die Idee hinter Containern ist eigentlich recht einfach: Ein Container fasst eine einzelne Anwendung mitsamt allen notwendigen Abhängigkeiten wie etwa Bibliotheken oder statische Inhalte in einer Image-Datei ohne Overhead zusammen. Im Gegensatz zu einer virtuellen Maschine enthält ein Container aber kein komplettes Betriebssystem und benötigt daher auch weniger Ressourcen. Ein bedeutender Vorteil der Docker-Container ist die gute Skalierbarkeit: Werden aufgrund des Lastverhaltens zusätzliche Instanzen einer Anwendung benötigt, lassen sich nach Belieben neue Container auf Basis eines Image erzeugen. Nach dem Stoppen sind die Container wieder vollständig aus dem System verschwunden und alle Ressourcen werden freigegeben. Die Konfiguration ist soweit wie möglich bereits im Container-Image eingerichtet. Zusätzlich notwendige Anpassungen sollten skriptbasiert erfolgen.

Um das volle Potenzial der Containertechnologie auszunutzen, müssen die darin ausgeführten Applikationen verschiedene Architekturrichtlinien berücksichtigen. In diesem Kontext wird häufig von 12-Faktor-Applikationen gesprochen. Hinter diesem Konzept verbergen sich zwölf Punkte, die Entwicklern dabei helfen sollen, Applikationen so zu designen und zu entwickeln, dass sich diese als SaaS (Software as a Service) und letztendlich auch problemlos in Containern betreiben lassen. Ein wichtiges und zugleich selbstverständliches Kriterium der zwölf Faktoren ist, dass der Quellcode einer Applikation stets in einer Versionsverwaltung wie zum Beispiel Git verwaltet wird. Dabei besteht immer eine eindeutige Korrelation zwischen einer Codebasis und einer App. Zwei Applikationen können sich nach diesem Konzept also einen Quellcode teilen. Das Vorhalten des Quellcodes ist ebenfalls ein wesentliches Erfordernis für den Aufbau einer CI/CD Pipeline. Applikationen sollten keine direkten Abhängigkeiten untereinander aufweisen. Durch das Verwenden eines Package Managers lässt sich sicherstellen, dass Abhängigkeiten zentral aufgelöst werden. Auch Problemen, die durch eine Diskrepanz in den Versionen entstehen, lässt sich so vorbeugen. Das gleiche Paradigma gilt für Services oder Ressourcen, die von einer Applikation verwendet werden. Dazu zählen zum Beispiel Datenbank- oder SMTP-Dienste sowie APIs. Eine App muss stets so entwickelt werden, dass es für die Einbindung und Nutzung der Services und Ressourcen unerheblich ist, von welchem Anbieter sie zur Verfügung gestellt werden. Im Rahmen eines Bereitstellungsprozesses ist es üblich, dass pro Umgebung eine eindeutige Konfiguration festgelegt wird. Diese Konfigurationsparameter müssen sich zwingend von außerhalb der Applikation ändern lassen. Ein Hinterlegen dieser Konfiguration im Code durch Konstanten, zum Beispiel für Systemzugangsdaten oder Datenbankverbindungsfolgen, stellt einen klaren Verstoß in einer 12-Faktor-Architektur dar.

In einer 12-Faktor-App wird strikt zwischen Build-, Release- und Run-Phase unterschieden. Checkt der Entwickler neuen Code ins Repository ein, wird mit der Build-Phase die Transformation des Codes in ein ausführbares Paket angestoßen. Im nächsten Schritt, der Releasephase, wird das Build-Ergebnis mit der zum Deployment passenden Konfiguration kombiniert. In der Run-Phase, der sogenannten Laufzeit, wird die Applikation dann ausgeführt. Aufgrund dieser strikten Trennung sind Codeänderungen zur Laufzeit nicht möglich, weil es keinen Weg gibt, die Änderungen zurück in die Build-Phase zu übernehmen. Es empfiehlt sich, jedes Release separat mit einem eindeutigen Identifier und Erstelldatum und -uhrzeit abzulegen. Das ermöglicht im Fehlerfall ein schnelles Rollback der Lösung. Eine 12-Faktor-App sollte immer zustandslos sein. Alle Daten werden in unterstützenden Diensten, in der Regel einer Datenbank, gespeichert. Der RAM oder das lokale Dateisystem können als kurzzeitiger Cache für eine Transaktion verwendet werden. Es darf aber niemals davon ausgegangen werden, dass Daten für einen längeren Zeitraum vorgehalten werden oder durch eine andere Transaktion nutzbar sind. In einer skalierbaren Umgebung ist es ebenso denkbar, dass ein künftiger Request von einer anderen Instanz als der ursprünglich angefragten und somit in einem anderen Transaktions-Scope bearbeitet wird. Da diese Flexibilität ein wesentlicher Teil der Grundidee ist, müssen Prozesse so ausgelegt werden, dass sie eine möglichst geringe Startzeit haben. Im Idealfall ist ein Prozess innerhalb weniger Sekunden hochgefahren und einsatzfähig. Eine kurze Start-up-Time verleiht dem System noch mehr Agilität und Robustheit. Gleiches gilt natürlich für das Herunterfahren eines Prozesses.

Um das Verhalten einer laufenden Applikation sichtbar zu machen, ist Logging unabdingbar. Häufig werden Logs gezielt an einem bestimmten Ort, wie dem Dateisystem oder einer Datenbank, abgelegt. Dieses Verhalten wird oftmals durch die Applikation bestimmt. Im Fall einer 12-Faktor-App ist es nicht mehr Aufgabe der Applikation, sich um einen Ablageort zu kümmern. Stattdessen werden sämtliche Ereignisse ungepuffert in den stdout-Stream geschrieben. Die weitere Verarbeitung dieser Ereignisinformationen obliegt dem Hostsystem. Es entscheidet alleinig, ob und wohin die Logs persistiert werden. Das Einhalten der hier aufgezeigten Leitlinien trägt zu einer sauberen und skalierbaren Applikationsarchitektur bei. Auch wenn dies prinzipiell für jede Applikation gilt, sollte dem Thema im Kontext von DevOps eine besondere Bedeutung zugemessen werden.

Azure DevOps

Die Zeichen, die Microsoft aussendet, sind deutlich: Schon länger versucht der Konzern ein Open-Source-freundlicheres Image aufzubauen. Ein großer Schritt in diese Richtung war der Beitritt Microsofts zum Open Innovation Network (OIN) und der damit verbundenen Bereitstellung von 60 000 eigenen Patenten. Ein weiterer bedeutender Schritt ist das Aufgeben der Marke „Visual Studio“. Die Cloud-Dienste für Entwickler, ehemals Visual Studio Team Services (VSTS), laufen ab sofort unter dem Brand „Azure DevOps“. Auch das lokal installierbare Gegenstück zu den VSTS, das seit 2005 unter dem Namen „Team Foundation Server“ (TFS) auf dem Markt ist, erhält ab der Version 2019 einen Brand: „Azure DevOps Server 2019“. Dieses Rebranding soll vor allem dafür sorgen, die Assoziation in den Köpfen vieler Entwickler zwischen Visual Studio und den klassischerweise damit verbundenen Programmiersprachen C++, C#, F# etc. zu lösen. Neben dem neuen Markennamen spendiert Microsoft natürlich auch noch ein paar neue Features wie etwa die „Azure Pipelines“. Hierbei handelt es sich um eine leistungsstarke CI/CD Pipeline Engine, die mit nahezu jeder gängigen Programmiersprache und einer Vielzahl von Projekttypen arbeitet. Natürlich gab es auch in der altbekannten Version bereits eine CI/CD Pipeline, doch vor dem Hintergrund immer größer werdenden Leistungsdrucks stellt die CI/CD Pipeline eine Komponente dar, die sicherlich noch viel Potenzial für Optimierung bietet. Azure Pipelines bieten die Möglichkeit, verschiedenste Zielsysteme für Bereitstellungsszenarien zu adressieren. Dazu gehören neben den Azure-eigenen Services, wie „Azure App Services“ oder „Azure Kubernetes Service“ (AKS), auch virtuelle Maschinen, klassische Container Registries oder Deployments zu Amazon Web Services. Eine neue Pipeline kann einfach über den Menüpunkt Pipelines auf der linken Seite der Azure-DevOps-Weboberfläche erstellt werden (Abb. 1).

Abb. 1: Azure DevOps Pipelines

Abb. 1: Azure DevOps Pipelines

Für das Erstellen einer Build Pipeline ist es zunächst erforderlich, eine Quelle auszuwählen, von der aus der Source Code abgerufen werden soll. Kompatible Quellcodeverwaltungssysteme sind zum Beispiel GitHub, Azure Repos Git, Subversion etc. Anschließend erfolgt die eigentliche Build-Konfiguration, die aber nicht jedes Mal aufs Neue manuell durchgeführt werden muss. Stattdessen kann der Benutzer aus einem Templatekatalog auswählen. So ist es mittels weniger Klicks beispielsweise möglich, eine Build Pipeline für eine Azure Web App for ASP.NET zu konfigurieren. Sind Container das präferierte Zielmodell, ist eine direkte Containerisierung mit anschließender Bereitstellung in einer Container-Registry ebenfalls mit einem überschaubaren Aufwand realisierbar. Wer sich in der Welt von YAML, einem JSON-ähnlichen deklarativen Format, wohlfühlt, ist eingeladen, die Build-Konfiguration auf Basis dieses Formats festzulegen. Das Erstellen einer Release-Pipeline fühlt sich ähnlich komfortabel an. End-to-End gedacht, dient die Release-Pipeline dazu, den Code für die Benutzer auf einem System verfügbar zu machen. Ihre Konfiguration erfolgt mittels eines grafischen Editors (Abb. 2).

Abb. 2: Konfiguration einer Release-Pipeline

Abb. 2: Konfiguration einer Release-Pipeline

Als Ausgangsbasis dient ein sogenanntes „Artifact“. Hierbei handelt es sich vereinfacht gesagt um den bereitstellbaren Teil einer Applikation, der in der Regel durch die Build Pipeline erzeugt wird. Am Artefakt selbst lässt sich wiederum das Verhalten über sogenannte Trigger festlegen. Der Bereitstellungsprozess wird somit zum Beispiel automatisch gestartet, sobald ein neuer Build zur Verfügung steht. Auch ein manueller Eingriff mittels Pull Request lässt sich einstellen. Über die Stages wird definiert, welche Umgebung zu welchem Zeitpunkt mit welchen Voraussetzungen deployt wird. Um den Konfigurationsprozess so einfach wie möglich zu gestalten, existieren auch hierfür zahlreiche vorgefertigte Templates für eine Bereitstellung auf Azure, Kubernetes, IIS etc. Das Deployment einer Stage kann an verschiedene Pre- und Post-Conditions geknüpft werden. Hierbei kann es sich beispielsweise um ein automatisch ausgelöstes Event oder eine benutzergetriebene Aktion handeln. Gates ermöglichen eine Integration von REST APIs, Azure Monitor Alerts oder Azure Functions. Sollte beim Deployment doch mal etwas schieflaufen, erlaubt die History eine transparente Einsicht in Änderungen sowie ein kontrolliertes Zurückrollen des Release.

Fazit

In Zeiten zunehmenden Wettbewerbsdrucks ist es wichtiger denn je, der Konkurrenz immer einen Schritt voraus zu sein. Dies trifft auf die Entwicklung physischer Güter, aber vor allem immer stärker auf digitale Services und Produkte zu. Mit der klassischen Unternehmensorganisation fällt es jedoch vor allem großen Konzernen mit ihrer Silostruktur schwer, mit dem vorherrschenden Tempo mitzuhalten. Doch immer mehr Unternehmen passen sich an und vollziehen einen Strukturwandel oder gründen Start-ups aus, um der heutzutage geforderten Agilität gerecht zu werden. Ein gutes Beispiel ist der Automobilkonzern BMW, dessen Vorstand einen radikalen Wandel in Richtung „Agile Operating Model“ bis Ende 2019 angekündigt hat. Das Zauberwort für das Erreichen all dieser Ziele lautet DevOps. Hierzu gehört jedoch viel mehr als nur das Einführen neuer Technologien und Plattformen. Es gehört ebenfalls mehr dazu als nur das Vorhaben, Abteilungen und Bereiche zusammenzuführen. Es handelt sich erst einmal um eine Revolution im Kopf aller Beteiligten, einen Umdenkprozess, der von höchster Ebene angeregt werden muss. Dabei ist es vor allem wichtig, die häufig im Kopf existierenden Silos abzureißen. Auch wenn bei DevOps die Technik nicht im Vordergrund steht, bedarf es natürlich entsprechender Konzepte und einheitlicher Plattformen, um die größtmögliche Effizienz bei der Entwicklung zu erzielen. Finden all diese Punkte Berücksichtigung und gelingt der Schulterschluss zwischen Entwicklung, Betrieb und Fachbereichen, steht einer erfolgreichen DevOps-Organisation nichts mehr im Weg.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -