DevOps

An einer größeren Software arbeiten traditionell zwei getrennte Gruppen. Die eine schreibt den Programmcode und baut neue Funktionen. Die andere sorgt dafür, dass das Programm auf den Servern läuft, erreichbar bleibt und nicht abstürzt. Server sind dabei einfach leistungsfähige Computer, die im Rechenzentrum stehen und Anfragen aus dem Internet beantworten. Zwischen beiden Gruppen entsteht leicht Streit: Die einen wollen möglichst viele Neuerungen ausliefern, die anderen wollen Ruhe, weil jede Änderung etwas kaputtmachen kann. DevOps ist der Versuch, diese Trennung aufzulösen und beide Aufgaben in einem gemeinsamen Team zu bündeln.

Warum Firmen ihre Software täglich ändern wollen

Früher war eine neue Programmversion ein großes Ereignis. Ein Unternehmen sammelte Änderungen monatelang und lieferte sie in einem einzigen Paket aus. Ging dabei etwas schief, war die Fehlersuche mühsam, weil hunderte Änderungen gleichzeitig neu waren. Solche Auslieferungen fanden deshalb oft nachts oder am Wochenende statt.

Heute veröffentlichen große Internetfirmen mehrmals am Tag neue Versionen. Amazon und Google liefern nach eigenen Angaben tausende Änderungen pro Tag aus. Jede einzelne ist winzig, deshalb ist das Risiko klein und ein Fehler schnell gefunden. Wer eine Idee morgens hat, kann sie abends bei echten Nutzern testen.

Für Unternehmen ist das ein wirtschaftlicher Vorteil, nicht nur ein technischer. Wer schneller reagiert, findet früher heraus, was Kunden wirklich wollen. Außerdem entfällt viel Wartezeit, in der fertige Arbeit ungenutzt herumliegt. Deshalb taucht DevOps in Geschäftsberichten und Stellenanzeigen so häufig auf.

Die Kette vom Code bis zum Server

Das Herzstück von DevOps ist eine automatisierte Kette, die Pipeline genannt wird. Ein Entwickler speichert seine Änderung in einem gemeinsamen Code-Archiv. Danach startet automatisch ein Ablauf: Der Code wird zusammengebaut, geprüft und getestet. Erst wenn alle Tests bestanden sind, geht die neue Version auf die Server.

Diese Tests schreiben die Entwickler selbst mit. Ein Test prüft zum Beispiel, ob die Anmeldefunktion nach der Änderung noch funktioniert. Fällt ein Test durch, stoppt die Kette und niemand muss von Hand eingreifen. Man nennt dieses ständige Prüfen und Ausliefern Continuous Integration und Continuous Delivery, kurz CI/CD.

Auch die Server selbst werden nicht mehr von Hand eingerichtet. Ihre Konfiguration steht als Textdatei im gleichen Archiv wie der Programmcode. Ein Werkzeug liest diese Datei und erzeugt daraus die passende Umgebung. Der Vorteil: Man kann eine identische Kopie jederzeit neu aufbauen, statt mühsam zu rekonstruieren, was jemand vor zwei Jahren eingestellt hat.

DevOps im Alltag und in KI-Projekten

Man bemerkt gute DevOps-Arbeit vor allem daran, dass man sie nicht bemerkt. Apps auf dem Smartphone aktualisieren sich still im Hintergrund. Onlineshops und Streamingdienste ändern ihre Oberfläche, ohne je für Wartungsarbeiten offline zu gehen. Wenn ein Dienst dagegen stundenlang ausfällt, ist das oft eine fehlgeschlagene Auslieferung.

In Stellenanzeigen taucht der Begriff als Berufsbezeichnung auf, etwa als DevOps-Engineer. Häufig genannte Werkzeuge sind Docker, Kubernetes, Jenkins und GitHub Actions. Ein verbreiteter Irrtum ist, DevOps sei einfach der neue Name für Systemadministration. Gemeint ist aber in erster Linie eine Arbeitsweise, bei der ein Team für sein Produkt vom Code bis zum laufenden Betrieb verantwortlich bleibt.

Im KI-Bereich gibt es eine eigene Variante namens MLOps. Sie überträgt dieselben Ideen auf Modelle des maschinellen Lernens, also auf Programme, die aus Daten lernen statt fest programmiert zu sein. Dort kommen zusätzliche Fragen dazu: Welche Daten wurden zum Training benutzt, und wird das Modell mit der Zeit schlechter? Die Grundhaltung bleibt aber dieselbe: automatisieren, messen, in kleinen Schritten ausliefern.