Was sind DevOps und automatisiertes Deployment?
Was DevOps und automatisiertes Deployment (CI/CD) bedeuten, was sie einem Unternehmen bringen, wann sie sich lohnen und wann nicht: ein klarer Leitfaden.
rabbitclip-TeamVeröffentlicht: 6 Min. Lesezeit
Kurz gesagt
DevOps ist eine Arbeitsweise, bei der die Menschen, die Software entwickeln, und die Menschen, die sie im Livebetrieb halten, in einem gemeinsamen Prozess auf ein gemeinsames Ziel hinarbeiten. Automatisiertes Deployment, meist CI/CD genannt, ist ihr sichtbarster Teil: Sobald eine Änderung gespeichert wird, wird der Code getestet, gebaut und jedes Mal über dieselben Schritte auf die Website gebracht. Für ein Unternehmen bedeutet das ganz einfach: Ein Release hängt nicht mehr vom Gedächtnis einer einzelnen Person oder von Hand kopierten Dateien ab, sondern wird zu einer wiederholbaren Aufgabe, die sich rückgängig machen lässt.
Oft werden diese Begriffe so dargestellt, als sei das ein Thema, das technische Teams unter sich besprechen. Die Fragen einer Geschäftsführung sind jedoch schlichter: Warum dauert eine kleine Korrektur auf der Website zwei Tage? Wer stellt den alten Zustand wieder her, wenn ein Release etwas kaputt macht? Weiß nur eine einzige Person, wie die Website live geht? DevOps bindet die Antworten an eine Gewohnheit und einen festen Ablauf statt an einzelne Personen.
Dieser Artikel hält den Begriff bewusst einfach. Er zeigt, was die Praxis einem Unternehmen bringt, wann sie überflüssig ist und welche Fehler beim Aufbau häufig gemacht werden.
Was ändert DevOps eigentlich?
In der älteren Aufteilung ist die Arbeit zweigeteilt. Eine Seite schreibt die Funktion, die andere bringt sie auf einen Server und hält sie am Laufen. Die Übergabe dazwischen erzeugt Wartezeiten, Missverständnisse und den Satz 'Bei mir hat es funktioniert'. DevOps verkleinert diese Lücke: Wer den Code schreibt, weiß, wie er live geht, und wer den Server betreibt, weiß, was der Code braucht.
Niemandes Stellenbezeichnung ändert sich. Geändert wird, dass die Arbeit auf einer einzigen Linie läuft. Was geschrieben, getestet, veröffentlicht und überwacht wird, gehört zu einem gemeinsamen Ablauf. Für ein kleines Team heißt das nicht, einen neuen Spezialisten einzustellen, sondern die vorhandene Arbeit mit weniger Überraschungen zu erledigen.
Wie funktioniert automatisiertes Deployment Schritt für Schritt?
Automatisiertes Deployment koppelt den Weg vom Rechner der Entwicklerin oder des Entwicklers bis zur Live-Website an ein Skript. Weil derselbe Weg jedes Mal in derselben Reihenfolge gegangen wird, liegt der Spielraum für Fehler beim Ablauf und nicht bei der Person, die gerade den Knopf drückt.
Eine typische Pipeline besteht aus den folgenden Schritten. Scheitert einer davon, hält die Pipeline an, und die Live-Website bleibt genau so, wie sie war.
- Der Entwickler schickt die Änderung an das Code-Repository
- Das System baut den Code und führt automatische Tests aus
- Bestehen die Tests, wird eine neue Version vorbereitet (paketiert)
- Die Version geht zuerst in eine Testumgebung, dann auf die Live-Website
- Nach dem Release wird die Seite geprüft; ist sie defekt, wird die vorherige Version wiederhergestellt
Was bringt es einem Unternehmen konkret?
Der sichtbarste Nutzen ist Tempo, doch der eigentliche Wert liegt in der Planbarkeit. Wenn ein Release auf einen Knopf oder eine einzige Code-Übermittlung zusammenschrumpft, werden kleine Korrekturen nicht tagelang gesammelt: Eine Preisanpassung, eine Kampagnenseite oder ein Tippfehler kann noch am selben Tag live gehen. Je häufiger Sie veröffentlichen, desto kleiner ist jede einzelne Änderung, und je kleiner die Änderung, desto kleiner das Risiko.
Der zweite Nutzen ist die Möglichkeit zurückzugehen. Jede Version ist aufgezeichnet. Geht nach einem Release etwas schief, kehren Sie schnell zur letzten funktionierenden Version zurück. Der dritte ist geteiltes Wissen: Weil der Release-Prozess als Pipeline festgehalten ist, liegt er nicht allein bei einer Person, und die Arbeit bleibt nicht stehen, wenn diese im Urlaub ist oder das Unternehmen verlässt.
Welche Unternehmen brauchen es, und welche nicht?
Nicht jede Website braucht es. Bei einer einseitigen Visitenkarten-Seite, die nur ein paar Mal im Jahr aktualisiert wird, kann der Aufbau einer Deployment-Pipeline in Einrichtung und Pflege mehr kosten, als er einspart. Eine solche Seite ist meist mit regelmäßigen Backups, einem sicheren Veröffentlichungsweg und einem Protokoll der Änderungen gut bedient.
Eine Pipeline lohnt sich in diesen Fällen: Die Website ändert sich oft, mehrere Personen arbeiten am selben Code, es gibt Abläufe wie einen Shop oder Buchungen, bei denen ein Fehler unmittelbar Einnahmen kostet, oder es müssen mehrere Umgebungen (Test und Live) verwaltet werden. Maßstab ist nicht die Größe der Website, sondern wie oft sie sich ändert und was ein Ausfall kostet.
Welche Fehler kommen häufig vor?
Der häufigste Fehler ist, ohne Tests zu automatisieren. Eine Pipeline, die veröffentlicht, ohne irgendetwas zu prüfen, bringt Fehler schneller auf die Live-Website als die Arbeit von Hand. Der Sinn der Automatisierung ist zuerst, eine fehlerhafte Version vom Livegang abzuhalten, und erst danach, Releases zu beschleunigen.
Der zweite Fehler ist, das Werkzeug mit dem Ziel zu verwechseln. Ein beliebtes Tool zu installieren ist noch kein DevOps. Ohne Prozess, ohne Verantwortlichen und ohne Rückfallplan ist es nur eine weitere Schicht Komplexität. Weitere häufige Fehler sind diese.
- Passwörter und Schlüssel in den Code selbst zu schreiben; sie gehören an einen eigenen, geschützten Ort
- Den Rückweg nie zu proben, sodass der erste Versuch mitten in der Krise stattfindet
- Die Testumgebung ganz anders aufzubauen als die Live-Website, sodass die Tests bestehen und die Live-Seite ausfällt
- Keinen Verantwortlichen für die Pipeline zu benennen, sodass niemand hinschaut, wenn sie ausfällt
Wo sollte man anfangen?
Klein anzufangen ist der sicherste Weg. Der erste Schritt ist, aufzuschreiben, wie die Website heute veröffentlicht wird; oft deckt schon die Beschreibung selbst die Lücken auf. Danach folgt, den Code unter Versionskontrolle zu stellen, und dann, eine einfache Pipeline aufzubauen, die die Website nur baut und grundlegende Prüfungen durchführt.
Hat sich das eingespielt, kommen automatische Tests, eine Testumgebung und eine Prüfung nach dem Release hinzu. Der Maßstab für jeden Schritt ist derselbe: Ist das Veröffentlichen entspannter, und geht die Wiederherstellung nach einem Problem schneller? Lautet die Antwort ja, geht es zum nächsten Schritt; lautet sie nein, halten wir an und korrigieren zuerst.
DevOps und automatisiertes Deployment binden Releases an einen festen Ablauf statt an einzelne Personen, und der Nutzen bemisst sich daran, wie oft sich die Website ändert und wie teuer ein Ausfall wäre. Eine Website, die sich selten ändert, ist mit soliden Backups und einem aufgeräumten Veröffentlichungsweg gut bedient, während sich bei einer Website, die sich oft ändert und Geld verdient, eine Pipeline mit Tests und einem Weg zurück auszahlt. Wenn Sie gemeinsam prüfen möchten, wie Ihre Website heute live geht, vereinbart rabbitclip gern ein ruhiges Erstgespräch mit Ihnen.
Häufige Fragen
Was bedeutet CI/CD?
CI steht für Continuous Integration, CD für Continuous Delivery oder Deployment. Jede Änderung am Code wird automatisch getestet und, sobald sie freigegeben ist, über dieselben Schritte vorbereitet oder veröffentlicht.
Braucht die Website eines kleinen Unternehmens DevOps?
Meist keine vollständige Pipeline. Backups, ein sicherer Veröffentlichungsweg und ein Protokoll der Änderungen reichen aus. Automatisierung wird sinnvoll, wenn Aktualisierungen häufiger werden oder ein Ausfall teurer wird.
Macht automatisiertes Deployment eine Website sicherer?
Richtig eingerichtet, ja: Kopierfehler nehmen ab, jede Version ist aufgezeichnet, und ein fehlerhaftes Release lässt sich rückgängig machen. Der Schutz von Passwörtern und das Schreiben von Tests müssen trotzdem gesondert erfolgen, denn Automatisierung allein schafft keine Sicherheit.
Muss ich für DevOps eine eigene Person einstellen?
Für ein kleines Unternehmen nicht. Den Release-Ablauf kann Ihr aktueller Entwickler oder die Agentur einrichten, mit der Sie arbeiten. Wichtig ist, dass der Prozess aufgeschrieben ist und einen Verantwortlichen hat.
