So bringen Sie Licht ins Dunkle Ihrer IBM ICS Updates

Kollaborative Umgebungen von IBM, wie auch von anderen Herstellern, erfordern heutzutage ein hohes Maß an Planung und Koordination, wenn man sie permanent auf dem aktuellsten Stand halten will. Der Trend zu einem Continuous Delivery erspart inzwischen zwar große Migrationsprojekte, dafür liefern die Hersteller allerdings häufig Updates. Neben Security Patches enthalten diese dann regelmäßig auch funktionale Erweiterungen, die über die regulären Updatepakete in die Produkte einfließen.

Für das IBM WebSphere Portal zum Beispiel veröffentlicht IBM seit dem Release der Version 8.5 (im Juni 2014) neben kleineren Updates und Hotfixes nur noch “ Combined Cumulative Fixes“ – inzwischen in der 13. Version. Diese sogenannten CFs enthalten ein breitgefächertes Sammelsurium von Änderungen, die sich prinzipiell auf alle Bereiche einer Portal-Installation auswirken können. Die Idee des Herstellers war es dabei ursprünglich, ein solches Updatepaket problemlos einspielen zu können und funktionale Erweiterungen zunächst schlafend zur Verfügung zu stellen. Erst später sollte sich der Portal-Kunde dann entscheiden können, welche Erweiterungen er wann gezielt aktivieren möchte.

Die Praxis ist allerdings häufig eine andere: bei laufenden Änderungen im komplexen Gefüge kollaborativer Software und im Zusammenspiel der verschiedenen Komponenten bleiben unerwünschte Auswirkungen auf bestehende und notwendige Kundenanpassungen leider nicht aus.

Dies kann folgende Komponenten betreffen:

•     ein Portal-Theme,
•     Änderungen an angepassten Social Rendering Schablonen,
•     die Einbettung von Drittanwendung über die Web Application Bridge
•     und vieles mehr.

Letztlich ist es also für den Betreiber einer solchen Umgebung erforderlich, die Auswirkungen eines anstehenden Updates auf Herz und Nieren zu prüfen, bevor es auf die produktive Realität losgelassen wird. Die Prüfung muss dabei auf verschiedenen Ebenen erfolgen. Je nach Kundengröße können die Anforderungen ans Staging sehr unterschiedlich sein.

Grundsätzlich gilt aber immer:

1. Das Theming und weitere Bereiche zunächst in einer isolierten, kundenspezifischen Umgebung prüfen zu lassen.
2. Nachgelagert kann dann eine Testumgebung, in der bereits notwendige Randsysteme über Testmandanten angebunden sind, in die Tests einbezogen werden.
3. Schließlich muss auch in der Produktiv-/Wirkumgebung selbst nach Durchführung des Updates noch eine Prüfung und Abnahme durch tatsächliche Benutzer erfolgen. Beliebt bei manchen Updates ist es beispielsweise, Berechtigungen und die Sichtbarkeit von Seiten in einem Portal wieder in den Originalzustand zu versetzen, der im Kundenkontext nicht immer gewünscht ist. Auch auf solche Änderungen sollte man jede Aktualisierung prüfen.

Die Struktur der Updateplanung spielt eine wichtige Rolle

Eine Steuerung ist koordiniert nur möglich, wenn im Vorfeld klar definiert ist, welche Tätigkeiten und Tests in welcher Reihenfolge durch wen auf welchen Ebenen erfolgen müssen. Erkenntnisse müssen dabei ggf. an nachgelagerte Phasen weitergegeben werden. Wenn beispielsweise bereits bei der Installation eines Fixes in einer Produktreferenzumgebung auffällt, dass besondere technische Schritte ausgeführt werden müssen, so muss dies auch in den nachfolgenden Schritten berücksichtigt werden. Eine solche Erkenntnis kann noch zusätzliche, spezifische Tests erforderlich machen, um die die standardisierten Abläufe ergänzt werden. Hilfreich ist es, die Beschreibung aller Testabläufe (Standard und Update-spezifisch), sowie alle weiteren Besonderheiten des Updates technisch und funktional gebündelt und zentral festzuhalten und zu dokumentieren. Hierzu bieten sich Kollaborationsumgebungen wie beispielsweise IBM Connections an.

Wie läuft ein Update aus Sicht eines IT-Dienstleisters ab?

Nicht nur für die Portalbetreiber selbst sondern auch für einen Dienstleister wie die agentbase AG ist es notwendig, im Detail zu prüfen, an welchen Schrauben bei jedem Update gedreht wird, um dann in den verschiedenen Kundenprojekten entsprechend kompetent und individuell beraten und reagieren zu können. Bevor wir mit einem Update auf einen Kunden zugehen, führen wir selbst intern in Produktreferenzumgebungen diese Updates durch. Kunden profitieren dadurch dann davon, dass mögliche Stolpersteine und Besonderheiten schon bekannt sind und man direkt in das Testen der kundenspezifischen Umgebungen einsteigen kann.

Zusammenfassung und Fazit

Das Aufsetzen von Ablauf- und Testplänen für die verschiedenen Ebenen mag auf den ersten Blick als aufwendig erscheinen. Die Ersparnisse sind aber immens, da bei der späteren Durchführung immer wiederkehrende Aufgaben deutlich schneller von der Hand gehen. Die Gefahr, dass Punkte vergessen werden ist außerdem deutlich geringer, als wenn solche Vorgänge improvisiert durchgeführt werden. Im Übrigen erleichtert die Durchführung von Updates nach festen Schemata eine lückenlose Dokumentation und somit die Erfüllung rechtlicher Vorschriften. Die Standardisierung der Abläufe kann außerdem noch optimiert werden, falls eine Anbindung an ein Ticket-System erfolgt. Für Atlassian Jira beispielsweise kann über das optionale und kostenlose Plugin „Quick Subtasks for JIRA“ eine Struktur von Untertask-Schablonen angelegt werden. Über solche Schablonen lassen sich dann einfach komplette Durchführungs- und Testpläne erstellen, die dann je Vorgang einfach nur aufgerufen werden können. Das Durchführen der Updates bereitet dann oft viel weniger Kopfschmerzen, als man es bisher vielleicht erlebt hat.