DevOps einführen
Die Arbeitsweise ändern, mit der Software in Betrieb geht: kleinere Änderungen, häufiger ausgeliefert, mit Rollback statt Hoffnung.
Überblick
DevOps ist ein Arbeitsmodell und kein Werkzeugkasten. Die Werkzeuge zu installieren, ohne die Arbeitsweise zu ändern, ergibt dieselben monatlichen Grossreleases mit besserem Logging, was für die Menschen, die nachts an der Störung sitzen, wenig ändert.
Die Änderung ist in der Sache einfach und in der Umsetzung unbequem: kleinere Änderungen, häufiger ausgeliefert, automatisch getestet, mit einem Rollback, das jemand tatsächlich schon geübt hat. Das senkt das Risiko je Release, weil weniger auf einmal unterwegs ist.
Für wen das gedacht ist
- Teams, die selten und mit hohem Risiko ausliefern
- Firmen, deren Deployments manuelle Schritte und eine Checkliste brauchen
- Organisationen ohne belastbaren Rollback-Weg
Unser Vorgehen bei DevOps einführen
Die konkreten Arbeitspakete eines typischen Projekts. Der Umfang steht vorab fest, nichts davon taucht später als Überraschung auf der Rechnung auf.
Ist-Aufnahme
Wie heute ausgeliefert wird, wie lange es dauert, was von Hand passiert und was zuletzt schiefging.
Automatisierte Auslieferung
Deployment als wiederholbarer Vorgang statt als Abfolge von Schritten, die eine Person im Kopf hat.
Infrastruktur als Code
Umgebungen definiert statt von Hand eingerichtet, damit Test und Produktion sich tatsächlich gleichen.
Umgebungen
Getrennte Umgebungen mit realistischen Daten, weil ein Test gegen eine leere Datenbank wenig aussagt.
Rollback
Ein geübter Rückweg. Ein Rollback, das noch nie ausgeführt wurde, ist eine Annahme und kein Plan.
Bereitschaft und Übergabe
Wer bei einer Störung gerufen wird, in welcher Reihenfolge, und was die Person vorfindet, wenn sie sich einloggt.
Vom ersten Gespräch zum gemessenen Ergebnis
Immer dieselbe Reihenfolge, damit Sie wissen, was als Nächstes kommt.
Aufnehmen
Den heutigen Weg von Commit bis Produktion abbilden, mit den tatsächlichen Zeiten und Handgriffen.
Automatisieren
Die manuellen Schritte ersetzen, beginnend mit denen, die am häufigsten Fehler erzeugen.
Takt erhöhen
Auf kleinere und häufigere Releases umstellen, was das Risiko je Release senkt statt es zu erhöhen.
Üben
Rollback und Störungsablauf durchspielen, bevor sie unter Druck gebraucht werden.
Ergebnisse statt Aktenordner
Ein Stapel Dokumente ist kein Fortschritt. Das hier sind die Veränderungen, die die Arbeit bewirken soll.
Kleinere Releases, weniger Risiko
Wenn wenig auf einmal ausgeliefert wird, ist die Ursache einer Störung in Minuten statt in Stunden gefunden.
Ein Rollback, das funktioniert
Einen Rückweg geübt zu haben ist der Unterschied zwischen einem kurzen Ausfall und einem langen Abend.
Umgebungen, die vergleichbar sind
Definierte Infrastruktur beendet die Fehlerklasse, die nur in Produktion auftritt.
Weniger Abhängigkeit von Einzelnen
Ein automatisierter Ablauf bedeutet, dass Auslieferung nicht davon abhängt, wer im Urlaub ist.
Häufige Fragen zu DevOps einführen
Was Kundinnen und Kunden fragen, bevor sie sich melden. Fehlt Ihre Frage, stellen Sie sie uns direkt.
Erhöht häufigeres Ausliefern nicht das Risiko?
Umgekehrt. Das Risiko steigt mit der Menge an Änderung je Release, nicht mit der Zahl der Releases. Zehn kleine Auslieferungen sind einzeln leicht zu prüfen und zurückzunehmen, ein grosses Monatsrelease enthält Dutzende Änderungen, von denen bei einer Störung keine klar als Ursache erkennbar ist.
Brauchen wir dafür eigene DevOps-Leute?
Nicht zwingend, und für kleinere Teams ist eine eigene Rolle oft die falsche Antwort. Was Sie brauchen, ist ein automatisierter Ablauf, den die Entwicklerinnen selbst bedienen. Eine eigene Rolle lohnt sich ab einer Grösse, in der Plattformarbeit eine dauerhafte Aufgabe ist.
Wie lange dauert die Umstellung?
Erste sinnvolle Verbesserungen in vier bis acht Wochen, meist Automatisierung des Deployments und ein belastbarer Rollback. Die Änderung der Arbeitsweise hin zu wirklich kleinen Releases dauert länger, weil sie Gewohnheiten betrifft und nicht Werkzeuge.
Was, wenn wir stark reguliert sind?
Regulierung verlangt Nachvollziehbarkeit und Freigaben, nicht seltene Releases. Ein automatisierter Ablauf mit protokollierten Freigaben erfüllt Prüfanforderungen meist besser als ein manueller Prozess, weil jeder Schritt dokumentiert und wiederholbar ist.
DevOps einführen im Kopf?
Sagen Sie uns, was sich ändern soll. Passen wir nicht, sagen wir das und nennen Ihnen eine bessere Adresse.
Interessiert Sie das grössere Bild?
DevOps einführen steht meist neben weiteren Themen aus DevOps, Infrastruktur und technischer Betrieb. Sehen Sie sich den ganzen Bereich an.