DevOps – kein neues Web 2.0

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Das Internet ist voll nutzloser Diskussionen, die DevOps und seine Schlüsselkonzepte verkomplizieren. Ist DevOps jedoch zu kompliziert, schwächt dies das Vertrauen des Teams und verhindert somit den Fortschritt.

Bereits in den frühen 2000er-Jahren brannten viele frisch gebackene Ingenieure auf Neuigkeiten rund um neue Technologien. Dabei gab es hier nur einige wenige Themen, die eher abstrakt waren und jede Diskussion tief philosophisch gestalteten.

Das beste Beispiel dafür war wohl „Web 2.0“. Was war es wirklich? Es gab immer jene, ob in einem Blog, in einem Interview oder in einem Meinungsartikel, die behaupteten, dass alles, was man über das Web 2.0 zu wissen glaubte, falsch war.

Das „echte“ Web 2.0 sei nicht dieses trivialisierte Etwas, von dem allgemein die Rede war. Es folgte dann eine Reihe neu erschaffener Begriffe, die entweder darauf abzielte, die Einzigartigkeit der Anbieter hervorzuheben oder das Profil eines anspruchsvollen Sprechers zu schärfen, anstatt wirklich zu klären, worum es im Web 2.0 ging.

Nun scheint dasselbe mit DevOps zu geschehen. Fast täglich werden neue Artikel mit der Behauptung „Dies ist NICHT DevOps“, „Sie verstehen es nicht: Bei DevOps handelt es sich um etwas anderes“ oder „So geht Continuous Delivery nicht“ veröffentlicht.

Obwohl gut gemeint und oft mit einem präzisen mentalen Modell ausgestattet, helfen diese Artikel nicht wirklich weiter, sondern stiften eher Verwirrung. Unternehmen müssen unterdessen ihre Zuversicht stärken, dass sie die digitale Transformation umsetzen können. Zudem scheinen die Experten, die mit dieser Aufgabe betraut sind, bereits im Bilde zu sein.

DevOps einfach halten

Bei DevOps geht es im Kern darum, die in der IT und im Unternehmen existierenden Silos zu durchbrechen. Dazu sollten vertikale Teams und Abteilungen im alten Stil visualisiert werden, etwa Engineering, Qualitätssicherung, IT-Operations oder Product Owner. Jede Abteilung hat dabei ihre eigene Richtlinie sowie klar definierte Schnittstellen, die beschreiben, wie ein Entwicklungsteam neuen Code in QA-Umgebungen verschiebt oder wie und wann dieser Code in die Produktion übertragen werden kann.

Hierbei werden nun die horizontalen Schichten dieser Teams mit einer Scheibe pro Produkt visualisiert. Team A konzentriert sich auf den Erfolg von Produkt A und definiert die Art der Zusammenarbeit für diesen Bereich und tauscht Fachwissen aus, um seine Ziele zu erreichen. Dabei werden einige Rollen zusammengeführt, andere Teams wiederum werden unterschiedliche Rollen behalten.

Unternehmen leben DevOps dann, wenn ihre funktionsübergreifenden Teams das Gefühl haben, dass ihr „erstes Zuhause“ ihr Produktteam und nicht ihre Abteilung ist. Hier kann entweder das Werkzeug A oder das Werkzeug B mit der bevorzugten Methodik verwendet werden. Die richtige Methodik ist diejenige, die zur DNA des Unternehmens passt und die richtige DevOps-Bewegung verstärkt. Dabei ist es nicht so relevant, ob Schritte nun DevOps entsprechen oder nicht, letztendlich kommt es immer auf die positive Veränderung an.

CI/CD

Anschließend liegt der Fokus auf Continuous Integration und Continuous Delivery (CI/CD). Wo beginnt dabei die CD und wo endet die CI? Was ist eine „echte“ CD? Hier bedeutet „kontinuierlich“, schnelle Iterationen auszuführen, was natürlich zu Reibungsverlusten führt. Aus diesem Grund ist es sinnvoll, diese Reibung durch Automatisierung zu beseitigen.

Im Continuous XYZ ist die Automatisierung entscheidend. Wenn ein Unternehmen jedoch über kein neues „Hello World“-Projekt verfügt, kann das dazu führen, dass der Prozess nicht vollautomatisch beginnt.

Dies ist fast immer ein schwieriges Unterfangen. Sei es, weil ein Projekt schwierig zu automatisieren ist, oder weil die Übergabe von Aufgaben in einer Organisation zu Problemen führt, diese etwa noch einen langen Weg bis zur Einführung von DevOps vor sich hat und die Automatisierung nur schrittweise vonstattengehen kann.

Häufig ist es einfacher, bis zum Beginn des Prozesses zu automatisieren, wie es seit mehr als einem Jahrzehnt der Praxis entspricht. Üblicherweise werden Entwicklungswerkzeuge dann für die Automatisierung erstellt.

Der Beginn der Implementierungsprozesse wird als „Continuous Integration“ oder „CI“ bezeichnet. Je weiter die Automatisierung fortschreitet, desto mehr wird sie zur „Continuous Delivery“ (CD). Durch diese befinden sich Unternehmen technisch gesehen ständig in einer Release-fähigen Phase. So können Teams bei Bedarf neue Updates in der Produktion vorantreiben.

Wollen Unternehmen jedoch die Produktion nicht forcieren, dann müssen sie das auch nicht. Beispielsweise wenn technische Gründe dagegensprechen, etwa bei dem Hochladen einer Anwendung in einen App-Store oder bei der Aktualisierung physischer Geräte in der Medizintechnik.

Wichtig ist nur, dass Teams in der Lage sein sollten, bis zur Endphase so viel wie nötig zu automatisieren. Der nächste Schritt wäre die Continuous Delivery, bei der die eigentlichen Module mit jedem validierten Commit in den Produktionszyklus gebracht werden, etwa auf einem Server, auf einem Gerät oder in einem App Store.

Continuous Delivery erfordert dabei ein System, das mit der „letzten Meile“ zum Zielserver/Gerät/Speicher umgehen kann, die daraus resultierenden Effekte misst und bei Misserfolg rückgängig macht. Es gibt es keinen Königsweg, denn der Prozess selbst ist wie eine Reise.

Verschiedene Ansätze

Wie verhält es sich aber mit der Automatisierung der Anwendungsfreigabe (Application Release Automation, ARA) oder mit der Orchestrierung der Anwendungsfreigabe (Application Release Orchestration, ARO)? Sind diese Ansätze mit CD identisch oder nicht? Die CD kann verschiedene Modelle verfolgen, vom „Chef/Puppet“-Verfahren bis hin zur Verwendung von selbst erstellten Skripten.

Kurz gesagt, ist ARA eine weitere Methode, um die kontinuierliche Bereitstellung und den kontinuierlichen Einsatz anzugehen (Forrester beispielsweise nennt ARA „Continuous Delivery and Release Automation“ – CDRA). Es ist zudem ein Verfahren, das CD zu Organisationen bringt, in denen der Betrieb tendenziell formaler ist. Auch die Vorhersagbarkeit, die vollständige Auditierbarkeit, die Fähigkeit zur formalen Abnahme und die Koordination zwischen mehreren Teams ist hier erfordert.

ARA/ARO wird tendenziell in Organisationen bevorzugt, in denen die „Ops“-Seite des Hauses für die Freigabe verantwortlich ist, während in Organisationen, in denen „Dev“ mehr Kontrolle hat, Lösungen à la Jenkins X bevorzugt werden.

Bei der Fülle nutzloser Diskussionen, die das Vertrauen in das, was ein Team aufzubauen versucht verletzen, müssen sich Unternehmen auf die kontinuierliche Verbesserung durch Zusammenarbeit, schnelle Iteration und Automatisierung konzentrieren. Nur so gehen sie in die richtige Richtung – gleichgültig, wie sie den Prozess nennen.

* Sacha Labourey ist CEO und Co-Gründer von CloudBees.

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

(ID:46603385)