Release hängt an einer Person: So machen Unternehmen ihr Software-Deployment nachvollziehbar

1. Woran erkennen Unternehmen eine kritische Release-Abhängigkeit?

Solange ein erfahrener Mitarbeiter verfügbar ist, fällt ein unzureichend dokumentierter Release-Prozess möglicherweise kaum auf. Schwierigkeiten entstehen erst bei Urlaub, Krankheit, Personalwechsel oder einer dringenden Fehlerkorrektur.

Typische Warnzeichen sind:

• Nur eine Person kennt die vollständige Reihenfolge der Deployment-Schritte.
• Wichtige Einstellungen werden vor jedem Release manuell angepasst.
• Die produktive Umgebung unterscheidet sich von der dokumentierten Konfiguration.
• Zugriffsrechte und Verantwortlichkeiten sind nicht eindeutig geregelt.
• Nach einem Update ist unklar, wer die Anwendung fachlich prüfen soll.
• Bei einem fehlgeschlagenen Release gibt es keinen vorbereiteten Handlungsplan.

Das Problem ist nicht die Kompetenz des einzelnen Mitarbeiters. Kritisch wird es, wenn notwendiges Wissen ausschließlich bei dieser Person liegt und das Unternehmen den Ablauf nicht unabhängig nachvollziehen kann.

Eine ähnliche organisatorische Abhängigkeit kann bei der Serverbetreuung entstehen. Wie Unternehmen nach dem Weggang eines Administrators vorgehen können, beschreibt der Beitrag Linux-Administrator nicht mehr verfügbar.

2. Welche Schritte gehören zu einem nachvollziehbaren Software-Release?

Ein Release beginnt nicht erst mit dem Kopieren neuer Dateien auf den Server. Er umfasst mehrere Schritte, die zusammen dafür sorgen sollen, dass eine geprüfte Softwareversion kontrolliert bereitgestellt wird.

1. Version festlegen: Eindeutig bestimmen, welcher Code veröffentlicht werden soll.
2. Build durchführen: Die benötigten Dateien oder ausführbaren Komponenten erzeugen.
3. Tests ausführen: Vereinbarte technische Prüfungen durchführen und Ergebnisse dokumentieren.
4. Freigabe erteilen: Festlegen, wer den Release für die vorgesehene Umgebung autorisiert.
5. Deployment durchführen: Die geprüfte Version nach dem vorgesehenen Verfahren bereitstellen.
6. Ergebnis kontrollieren: Technischen Zustand und wichtige Anwendungsfunktionen prüfen.
7. Abschluss dokumentieren: Veröffentlichten Stand, Ergebnisse und offene Probleme festhalten.

Die einzelnen Schritte können je nach Anwendung unterschiedlich aussehen. Eine kleine interne Software benötigt möglicherweise weniger Prüfungen als ein System, das Bestellungen verarbeitet oder mit mehreren Geschäftsanwendungen kommuniziert.

Wichtig ist, dass der Ablauf zur tatsächlichen Anwendung passt und nicht bei jedem Release neu erfunden werden muss.

3. Was muss dokumentiert werden, damit ein anderer Mitarbeiter übernehmen kann?

Eine gute Release-Dokumentation ist keine möglichst lange technische Beschreibung. Sie muss einem berechtigten Mitarbeiter helfen, den vorgesehenen Ablauf sicher nachzuvollziehen.

Passwörter und andere Geheimnisse gehören dabei nicht ungeschützt in die Dokumentation oder den Quellcode. Der Zugriff sollte über geeignete Berechtigungen und eine sichere Verwaltung sensibler Werte erfolgen.

Bei CI/CD-Systemen lassen sich Zugriffe und Variablen abhängig von der vorgesehenen Umgebung einschränken. Die offizielle GitLab-Dokumentation zu Environments und Deployments beschreibt entsprechende Möglichkeiten für GitLab CI/CD.

Die Dokumentation sollte dort liegen, wo das Team sie bei Bedarf tatsächlich findet und aktuell halten kann.

4. Wann lohnt sich die Automatisierung mit CI/CD?

Wenn dieselben Schritte regelmäßig von Hand ausgeführt werden, kann eine CI/CD-Pipeline den Prozess vereinheitlichen. Beispielsweise lassen sich Builds und bestimmte Tests automatisch starten, sobald eine dafür vorgesehene Änderung bereitsteht.

Auch Deployments können unter geeigneten Voraussetzungen automatisiert werden. Für produktive Umgebungen kann weiterhin eine bewusste Freigabe erforderlich sein.

Automatisierung ersetzt keine Zuständigkeit

Eine Pipeline kann zuverlässig technische Schritte ausführen und trotzdem ein fachlich falsches Ergebnis bereitstellen. Deshalb müssen auch bei automatisierten Releases Verantwortlichkeiten und Abnahmekriterien bestehen bleiben.

Unternehmen sollten vor der Automatisierung klären:

• Welche Schritte wiederholen sich tatsächlich?
• Welche Prüfungen lassen sich technisch automatisieren?
• Welche Entscheidungen benötigen eine Freigabe?
• Wie werden Fehler sichtbar und zuständigen Personen zugeordnet?
• Was passiert, wenn das Deployment erfolgreich ist, die Anwendung aber nicht korrekt arbeitet?

Nicht jeder Prozess benötigt sofort eine umfangreiche Pipeline. Bei seltenen Änderungen kann zunächst eine zuverlässige Dokumentation sinnvoll sein. Bei regelmäßigen Releases und mehreren beteiligten Entwicklern wird ein standardisierter Ablauf häufig wichtiger.

Wie Softwareänderungen grundsätzlich kontrolliert eingeführt werden können, erläutert der Beitrag Software-Updates mit weniger Ausfallrisiko.

5. Beispiel: Ein Release soll trotz Abwesenheit des Entwicklers stattfinden

Angenommen, ein mittelständisches Unternehmen betreibt eine individuell entwickelte Anwendung zur Auftragsbearbeitung. Neue Funktionen werden regelmäßig ergänzt. Bisher führt ein Entwickler die Veröffentlichung manuell durch.

Vor jedem Release erstellt er den Build, überträgt Dateien auf den Server und passt bestimmte Einstellungen an. Anschließend öffnet er die Anwendung und prüft, ob sie startet.

Als dieser Entwickler nicht verfügbar ist, kann das Team ein notwendiges Update nicht ohne Weiteres veröffentlichen.

So wird der Prozess übertragbar

Das Unternehmen lässt den vorhandenen Release-Ablauf aufnehmen. Die verwendete Codeversion, benötigten Werkzeuge und Zielumgebung werden dokumentiert. Wiederkehrende Build- und Testschritte werden soweit sinnvoll standardisiert.

Für die produktive Veröffentlichung wird eine verantwortliche Person bestimmt. Außerdem legt das Team fest, welche Funktionen nach dem Deployment kontrolliert werden müssen.

Dazu gehört beispielsweise nicht nur die Anmeldung, sondern auch die Übertragung eines Testauftrags an das ERP-System. Die fachliche Prüfung erhält einen benannten Verantwortlichen und ein erwartetes Ergebnis.

Anschließend führt ein zweiter berechtigter Mitarbeiter den dokumentierten Ablauf unter geeigneten Testbedingungen durch. Dabei zeigt sich, ob wesentliche Informationen fehlen oder einzelne Schritte weiterhin vom Wissen des ursprünglichen Entwicklers abhängen.

Erst durch diese praktische Übergabe wird erkennbar, ob der Release-Prozess tatsächlich von einer weiteren Person übernommen werden kann.

6. Wann ist externe DevOps-Unterstützung sinnvoll?

Externe Unterstützung kann sinnvoll sein, wenn ein Unternehmen seine bestehenden Release-Abläufe dokumentieren, wiederkehrende Schritte automatisieren oder eine schwer nachvollziehbare Pipeline überarbeiten möchte.

Für die erste technische Einordnung helfen Angaben zur eingesetzten Software, zum Repository, zum bisherigen Build- und Deployment-Verfahren sowie zu den verwendeten Zielumgebungen.

Ebenso wichtig ist das gewünschte Ergebnis: Soll zunächst der vorhandene Ablauf dokumentiert werden? Müssen technische Fehler behoben werden? Oder soll ein wiederholbarer Release-Prozess entstehen?

Kubertino unterstützt Entwicklungsteams bei vereinbarten DevOps-Aufgaben, darunter Build-, Test- und Deployment-Prozesse, bestehende Pipelines und die Abstimmung von Umgebungen.

Weitere Informationen zum Leistungsumfang finden Sie unter DevOps-Outsourcing.