Die Bezeichnung DevOps beschreibt einen Verbesserungsansatz in der Softwareentwicklung. Dabei stehen vor allem die Automatisierung von Softwareübertragungen auf alle gewünschten Rechner (Deployments), das Zusammenfügen von Programmteilen und die fertige Software (Builds) sowie Softwaretests im Vordergrund.
DevOps verwendet in diesem Kontext 3 Buzzwords, die aufeinander aufbauen und eine Automatisierung der wiederkehrenden Tätigkeiten beschreiben: Continuous Integration, Continuous Delivery und Continuous Deployment. Die 3 Prozesse setzen dabei auf eine kontinuierliche Lieferung kleiner Software-Inkremente und ein direktes Feedback bzgl. der Neuerungen.
Abb 1. Die 3 Begriffe beschreiben die Automatisierung von wiederkehrenden Tätigkeiten in der Softwareentwicklung.
Continuous Integration (CI) verfolgt das Ziel, entwickelte Codes so schnell wie möglich auf das Integrationssystem zu bringen und dem Verantwortlichen ein schnelles Feedback durch automatisierte Tests über den geschriebenen Code zur Verfügung zu stellen. Das Integrationssystem testet also die Module und abhängige Software integrativ, wodurch Fehler und Risiken zwischen diesen Modulen und verknüpfter Software schnell sichtbar werden. In vielen Unternehmen werden Integrationstests zu selten ausgeführt. Wie Projekte ohne Continuous Integration häufig ablaufen, zeigt folgendes Beispiel.
Ein Projekt aus der klassischen Softwareentwicklung sieht mehrere Entwicklungs-Stages vor. Die Entwickler-Teams verfügen über ein Codeverwaltungs-Tool, in dem sie ihre Codes einchecken, sowie ein Build-Tool, das aus dem Code ausführbare Software-Artefakte generiert.
Das Stage-System beinhaltet ein Integrationssystem, dessen Abzug, auf dem Entwickler ihre Features separat entwickeln (das sogenannte Featuresystem), eine Pre-Production und die Produktionsumgebung.
Die Entwickler schreiben einen Code, der zuerst auf dem Featuresystem ausgiebig getestet wird. Damit arbeiten sie während der kompletten Entwicklungsphase auf einer Stage, ohne den Code auf das Integrationssystem zu übertragen. Erst wenn das Feature vollständig entwickelt ist, wird der Code ins Integrationssystem eingepflegt – hierbei wird geschaut, ob die entwickelten Features auch im Zusammenspiel mit anderen Modulen oder Systemen funktionieren. Mit dieser klassischen Vorgehensweise verpassen Entwickler jedoch die Chance, ein direktes Feedback zu erhalten. Von möglichen Problemen im Zusammenspiel von ihrem neu entwickelten und dem bereits vorhandenen produktiven Code bekommen sie deshalb womöglich zu spät mit.
Zudem werden auch Probleme beim Zusammenführen von neuen Codes, die in verschiedenen Entwickler-Teams angefertigt wurden und unterschiedliche Software-Stränge (Branches) betreffen, ebenfalls häufig nicht sofort erkannt. Dabei ist Continuous Integration gerade bei verteilten Entwickler-Teams, die gemeinsam an komplexen Systemen arbeiten, hilfreich: Mit einem zentralen Build-Server wird aus dem Code ein Software-Artefakt gebaut, das direkt auf die Integrationsumgebung übertragen wird. Diese erhält dadurch bereits in einer frühen Phase neue Features. Durch häufige integrative Tests erhalten die Teams dabei schnell Feedback zu den einzelnen Änderungen im Zusammenspiel mit abhängigen Modulen im System.
Hierzu müssen Verantwortliche die Testverfahren parallel mit der eigentlichen Programmierung anfertigen. Ein möglicher Entwicklungsansatz ist das Test-Driven Development. Durch eine Automatisierung der gängigen Testarten wie zum Beispiel Unit-Tests, Performancetests, Penetrationstests oder Regressionstests können Testergebnisse frühzeitig an das Entwicklungsteam zurückgespielt werden
Wenn Fehler ohne die Prüfungen unter Umständen zu spät auffallen, können hohe Aufwände entstehen. Sie resultieren zum Beispiel aus nachträglich notwendigen Anpassungen oder Inkompatibilitäten zwischen den unterschiedlichen Software-Strängen. Wird der Fehler früher entdeckt, sind die Kosten in den meisten Fällen erheblich geringer, als wenn der Fehler erst später gefunden wird.
Abb 2. Je früher ein Entwicklungsfehler entdeckt wird, desto weniger Kosten verursacht er.
Mit Continuous Integration verfolgen Unternehmen das Ziel, den eingecheckten Code schneller auszuliefern, die Zusammenarbeit zwischen Entwickler-Teams zu verbessern und dem einzelnen Entwickler ein sofortiges Feedback bereitzustellen. Damit die Methode angewandt werden kann, müssen Unternehmen über ein zentrales Code-Verwaltungssystem und einem Server für Build- und Test-Jobs verfügen.
Die Methode entfaltet großes Potenzial, wenn Verantwortliche sich auf die Automatisierung von Tests, das kontinuierliche Einchecken von Codes und das erzeugte Feedbacks einlassen. Hierdurch wird der Softwareentwicklungsprozess beschleunigt und die Softwarequalität signifikant erhöht.
Die richtige Umsetzung von Continuous Integration bringt Unternehmen folgende Vorteile:
Um Continuous Integration richtig umzusetzen, müssen Unternehmen folgende Aktivitäten durchführen:
Continuous Delivery baut auf Continuous Integration auf und beschreibt eine Methode, die den Softwareauslieferungsprozess verbessert. Ziel ist es, einem Kunden eine fertige Softwareversion per Knopfdruck bereitzustellen.
Continuous Delivery umfasst den Weg von der Integrations- bis zur Produktionsumgebung und reduziert dabei manuelle Schritte auf das notwendige Maß. Nach den erfolgreichen Integrationstests werden die Software-Artefakte ohne manuelles Zutun in die Pre-Production geliefert, wo sie sowohl für automatische Prüfungen als auch für Abnahmetests der Anwender zur Verfügung stehen. Verlaufen diese erfolgreich, wird das Artefakt in die Produktionsumgebung übertragen.
Kleinere Software-Pakete werden öfter in die Pre-Production übertragen. Dabei werden jeweils kleine Änderungen in sinnvoller Stückelung ausgeliefert, wodurch Fachbereiche die Entwicklungen schneller testen und freigeben können. Das Entwickler-Team spart bei den automatischen Auslieferungen Zeit und ist gleichzeitig flexibel, weil es für den Prozess einen beliebigen Zeitpunkt festlegen kann und nicht vor Ort sein muss: Übertragungen können also ohne Mitarbeiter nachts oder am Wochenende durchgeführt werden.
Damit Unternehmen Continuous Delivery umsetzen können, müssen sie Continuous Integration angewandt und Freigabestrukturen für die Software bis zur Produktionsumgebung automatisiert haben. Zudem benötigt der zentrale Branch im Repository (Master-Branch) einer Software einen releasefähigen Code.
Folgende Tools sind für die Deploymentautomatisierung je nach verwendeter Technologie notwendig:
Mit der Umsetzung von Continuous Delivery verbessern Unternehmen die Auslieferungsgeschwindigkeit und -qualität ihrer Software.
Continuous Deployment ist eine Methode, mit der Builds automatisiert auf die Produktionsumgebung aufgespielt werden. Dieser Vorgang ist nur für ausgewählte Softwareentwicklungen sinnvoll einsetzbar.
Continuous Deployment ist die konsequente Weiterentwicklung von Continuous Delivery: Entwicklerteams bekommen das Recht, Änderungen direkt in die Produktionsumgebung zu spielen, solange die entwickelten automatisierten Tests erfolgreich laufen. Deshalb müssen Continuous Integration und Continuous Delivery zuvor richtig umgesetzt worden sein, damit Continuous Deployment funktionieren kann.
Mit Continuous Deployment erhalten Kunden Software-Änderungen direkt im Produktiveinsatz. Hierzu wird der Code nach erfolgreichen Tests auf die Produktionsumgebung gespielt, ohne dass manuell eingegriffen werden muss: Es sind zum Beispiel keine manuellen Freigaben durch den Fachbereich notwendig.
Bei fehlgeschlagenen Tests wird das neue Software-Artefakt nicht auf die Produktionsumgebung gespielt – Stattdessen erhält das Entwickler-Team Testreports als Feedback, um die Fehler zu beheben.
Abb 3. Nach einem Unit-Test, in dem die Software-Stränge einzeln getestet werden, wird die Software in die Pre-Production geliefert. Dort wird sie noch einmal getestet und steht dem Auftraggeber dann zur Übertragung in die Produktionsumgebung zur Verfügung.
Continuous Deployment setzt viel Vertrauen zwischen Kunden, Fachbereichen und Entwickler-Teams voraus, da es möglich ist, dass direkte Änderungen in der Produktionsumgebung auch ungewollt Schäden verursachen, die durch manuelle Abnahmetests vielleicht vermieden worden wären.
Anwender sollten stark in den Entwicklungsprozess mit einbezogen werden, damit sie direkt mit den Software-Änderungen vertraut sind. Auch eine gute Dokumentationsstrategie, die Nutzern die Änderungen vermittelt, hilft dabei, den Übergangsprozess bei der Einführung neuer Software-Funktionen so reibungslos wie möglich zu gestalten.
Mit den 3 Methoden Continuous Integration, Continuous Delivery und Continuous Deployment soll eine Software schneller entwickelt, ihre Qualität gesteigert und ihre Auslieferung beschleunigt werden. Damit alle Maßnahmen erfolgreich umgesetzt werden können, müssen die Beteiligten gut zusammenarbeiten. Hierzu gibt Continuous Integration beteiligten Entwickler-Teams Feedback zu ihren Codes. Continuous Delivery sorgt dafür, dass die Software-Artefakte automatisch in die Pre-Production übertragen werden. Über Continuous Deployment wird die Software dann ebenfalls automatisch auf die Produktionsumgebung gespielt.
Haben Sie weitere Fragen zu Continuous Integration, Continuous Delivery, Continuous Deployment oder DevOps im Allgemeinen? Treten Sie gerne persönlich mit uns in Kontakt, damit wir Ihr Anliegen klären können!
Sie nehmen telefonisch, per Mail oder Formular Kontakt auf und schildern uns Ihr Anliegen.
Zur Klärung von Rückfragen und von Details zum weiteren Vorgehen melden wir uns telefonisch bei Ihnen.
Wir unterbreiten Ihnen ein Angebot und unterstützen Sie gerne auch bei der Präsentation für Ihr Management.
