Letzthin wurde ich in eine Diskussion mit dem Thema “Warum wählst Du ausschliesslich LTS(B)-Releases? Da sind ja die ganzen schönen neuen Features nicht drin!” verwickelt. Nun…

Ich versuche, immer eine Art “Change and Release Management” zu betreiben. Nicht nach irgendwelchen IT-Architekturen (wobei sich beispielsweise ITIL durchaus darauf abbilden lässt), sondern nach den Regeln des “gesunden Menschenverstandes”.

Das Release eines neuen Produkts oder einer aktualisierten Version eines bestehenden Produktes muss meiner Meinung nach angedacht, geplant, ausgearbeitet und getestet werden. Das benötigt relativ viel Zeit.

Hau-Ruck-Übungen (ein Upgrade einfach über das bestehende, möglicherweise produktive System ziehen und mal schauen, was dann passiert) und sind etwas vom schlimmsten, was man auf meiner Branche machen kann. Trotzdem arbeiten viele Firmen, gerade Fachpartner, so.

Nehmen wir das Beispiel von Ubuntu Server: Dieses Produkt gibt es als Langzeitversion, für welche der Hersteller einen Lifecycle von 5 Jahren angibt, und als “normale” Version mit einem Lifecycle von 8 Monaten.

Für den Einsatz von LTS(B)-Versionen sprechen:

• Angenommen, ich habe 150 Applikationen in meinem Unternehmen mit 1000 Computern, pro Jahr kommen 10 Applikationen hinzu. Die LTSB-Version den Client-Betriebssystem garantiert mir, dass die 150 Applikationen während dem Lebenszyklus des Client-Betriebssystems funktionieren. Vorausgesetzt, natürlich, dass zum Release des Client-OS alle 150 Applikationen kompatibel waren.
• Mit einer LTSB-Version habe ich genügend Zeit und finanzielle Ressourcen für fundiertes Change-and-Release-Management – Planbarkeit und Verringerung des Kostendrucks.
• Es ist möglich, ein Produkt relativ lange zu betreiben, wenn Abhängigkeiten dies Erfordern.
• Sie sind meistens stabiler bzw. verlässlicher.
• Dadurch, dass neueste Features nicht verfügbar sind, verringert sich möglicherweise die Angriffsfläche.
• Der Wissensaufbau in den IT-Abteilungen kann fundierter geschehen, da die Releases nicht im Halbjahres-Rhythmus abgearbeitet werden müssen.

Gegen den Einsatz von LTSB-Versionen sprechen:

• Neue Features werden lange zurückgehalten oder kommen gar nicht (Bsp. Microsoft Edge ist auf Windows 10 LTSB nicht verfügbar)
• Gewisse Apps und Applikationen lassen sich nicht installieren oder funktionieren auf der LTSB-Version eines Betriebssystems nicht

Microsoft definiert, dass die LTSB-Versionen ihrer Client-Betriebssysteme nur für missionskritische Systeme empfohlen sind. Dem stimme ich nicht zu. Mal abgesehen davon, dass ein Client-OS meiner Meinung nach auf einem missionskritischen System nichts zu suchen hat, ist diese Definition meiner Meinung nach zu “kurz gedacht”:

Das Change für ein Release eines neuen Client-OS lässt sich grob in folgende Aufgaben aufteilen:

• Release- und Rollout-Konzept ausarbeiten, Anforderungen aus der Produktion abbilden
• Lizenzen und Medien akquirieren
• Policies ausarbeiten
• Ersten Release-Kandidat ausarbeiten und erste Schritte damit machen
• Leistung des ersten Release-Kandidaten ausmessen (Bsp.: Logon-Zeit)
• Eventuell mehrere Release-Kandidaten erstellen und testen bis ein Kandidat Produktionsqualität erreicht
• Applikationen paketieren
• Testfälle definieren und Key-Users für Applikationstests aufbieten
• Applikationen testen
• Eventuell mehrfach wiederholen, bis für jede Applikation ein Paket mit Produktionsqualität erstellt wurde
• Falls für eine Applikation kein Paket mit Produktionsqualität erstellt werden konnte: Applikation aktualisieren oder dekommissionieren
• Release auf ausgewählten Clients testen
• Release durchführen

Die Periodizität dieser Prozesse beträgt bei LTS(B)-Versionen mutmasslich Jahre, bei “Bleeding Edge” Monate. Sofern nicht grosse Teile dieser Prozesse automatisiert werden können ist der Einsatz von “Bleeding Edge”-Versionen nicht ohne massive Abstriche in der Qualität möglich.

Ausgenommen sind natürlich Kleinfirmen, dort ist es vermutlich durchaus machbar, aber ob es sich finanziell lohnt, ist fraglich.

Ach ja, was natürlich früher oder später kommen wird, wenn’s um Client-Betriebssysteme geht:

Anfrage (aus dem Kader): “Können wir nicht fürs Kader das Bessere (!) und für die Arbeiter LTS(B) haben?”

Das ist meiner Meinung nach abhängig davon, wie gut durchstrukturiert die IT-Abteilung oder der Dienstleister ist. Generell ist es keine gute Idee, zwei ähnliche Baustellen zu betreiben. Wenn Du und Deine Abteilung gut durchstrukturiert sind kann es funktionieren. Implementiere DevOPS!

Ich höre gerade: AC/DC – Hells Bells