Das Deployen neuer Releases war früher mit einem hohen zeitlichen Aufwand verbunden. Der Download, das Bauen, das Testen und das Ausliefern neuer Releases für die klasssichen Umgebungen Entwicklung, Staging (Abnahme) und Produktion hatte je nach System eine umfangreiche Anzahl an Schritten zur Folge.
Schritte bei einem Releasewechsel
Ein Releasewechsel bedeutet im allgemeinen
- Umbau der Releaseumgebung im lokalen System, d.h. Download der neuen Releases, Anpassung der Konfiguration, Update einer Datenbank, Anpassung ergänzender Module wie WebProxy (Apache, Nginx), Docker usw.
- Umbau der Stagingumgebung, d.h. Wegwerfen der alten Infarstruktur, manueller Neuaufbau der neuen Infrastruktur mit den geänderten Releases, Konfigurationen, Datenbanken, zusätzlichen Modulen
- Funktions-, Performanz- und Integrationstests auf der Stagingumgebung mit späterer Abnahme
- Wenn Abnahme nicht erfolgt, Wiederholen vom ersten Schritt an, mit den notwendigen abnahmeverhinderten Änderungen
- Wenn Abnahme erfolgt, Umbau der Produktivumgebung, d.h. Wegwerfen der alten Infrastruktur, manueller Neuaufbau der neuen Infrastruktur mit den geänderten Releases, Konfigurationen, Datenbanken, zusätzlichen Modulen
- Funktions-, Performanz- und Integrationstests in Produktion vor Freigabe an den Kunden
- Wenn bereits vor der Freigabe in Produktion Probleme auftreten beginnt man wieder von Anfang an
Diese Darstellung der einzelnen Schritte stellt sicherlich ein theoretisches Konstrukt dar, das im Zuge agiler Vorgehensweisen auch veränderbar sind. Faktisch ist es aber so, dass auch agile Methoden diese Schritte implizit mit umfasst, diese sind nur mit in den Entwicklungsprozess integriert.
Konflikte bei einem Releasewechsel
Die Erfahrung zeigt, dass ein Releasewechsel für ein Team eine BlackBox darstellt. Eigentlich können die Mitglieder eines Teams nicht wissen was sie tun. Die Releaseentwicklung (z.B. eine externe Firma), die das Release bereitstellt, entwickelt selten gegen alle Möglichkeiten des Einsatzes. Die Flexibilität in Bezug zur Laufzeitumgebung (Betriebssystem, Cloud oder OnPrem), die genutzten Module (WebProxy-Software, DBMS im Backend), im Cluster oder als Einzelinstallation, containerisiert oder nicht, der Umfang der Daten usw. stellt eine riesige Hürde dar, das System perfekt lauffähig an einen Kunden auszuliefern.
Je nach Vertrauen und der Erfahrung der beteiligten Personen / Teams, beschäftigt man sich schnell mehr mit Schuldzuweisungen als an einer Lösung von Problemen. Faktisch ist es so, dass irgendwann aus Zeitdruck nicht mehr sauber geabeitet wird und man nur noch versucht, “Schuld” zu deligieren. Fehlgeschlagene Tests werden nicht mehr als das kommuniziert, nur noch Hurrameldungen gestreut usw. bis es am Ende richtig knallt. Kennt man ja alles.
Wie löst man das Problem?
Erfahreneres Personal: Selbst Superexperten sind am Anfang mit den Problem eigentlich überfordert. Auch diese kennen nicht alle problematischen Stellen bei einem Releasewechsel. Die Experten, die das können, sind noch seltener als Einhörner.
Mehr Personal: Mehr Personal heißt nicht zwingend mehr Erfahrung. Die Mischung und vor allem die Art der Zusammenarbeit muss stimmen.
Outsourcen: Outsourcen ist die letzte Maßnahme die man ins Auge fassen muss, wenn es überhaupt Unternehmen gibt, die das im Angebot haben.
Zeit: Zeit ist das kritische Element bei einem Releasewechsel. Erfahrungen müssen aufgebaut werden, Sachen ausprobiert, getestet, verworfen, optimiert werden. Bei einem komplexen System gibt es einen gradlinigen Weg leider nicht. Die oben skizzierten Schritte müssen mehrfach durchlaufen werden, d.h. der gradlinige Weg muss über einen iterativen Weg erst erforscht werden.
Lösung Effective DevOps und IaC
Bei der Flexibilität moderner IT-Infratruktur setzt Effective DevOps an. Mit Infrastructure as Code (IaC) ist der Aufbau einer Umgebung
- parametrisiert und
- automatisiert per Knopfdruck
möglich.
Es sind nur die notwendigen Änderungen in den Code einzutragen und man bekommt per Knopfdruck die Umgebungen für Entwicklung, Staging und Produktion, die man benötigt. Dadurch wird massiv mehr Zeit für Tests und Entwicklung frei, was man in einer
- deutlichen Steigerung der Geschwindigkeit und
- der Qualität
bei einem Releasewechsel merkt. Ein sehr positiver Nebeneffekt ist, dass sich durch die zusätzliche Zeit für Tests und Entwicklung sich eine größere Zufriedenheit bei den Mitarbeitern einstellt. Dadurch dass sie schneller und bessere Lösungen anbieten können, sind auch
- die Kunden zufriedenerund und geben besseres Feedback,
- stellt sich ein größerer Erfolg ein
- was zu mehr Selbstvertrauen und Zufriedenheit
auf allen Seiten führt.
