Achtung – Lücke!Sechs Schritte zum Überbrücken der Lücke zwischen der Softwareentwicklung und dem Betriebsteam durch Release Managementvon Greg Hughes, CEO, Serena Software (jetzt Micro Focus)

White Paper

Inhaltsverzeichnis Seite

Warum Release Management so schwierig ist . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Probleme mit dem Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Änderungsmanagement: notwendig, aber nicht ausreichend . . . . . . . . . . . . . . . 3DevOps: Achtung vor den Puristen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Kontinuierliche Bereitstellung: die eine Hälfte der Lösung . . . . . . . . . . . . . . . . . 4Best-Practices beim Release Management: Sechs Schritte zum Erfolg . . . . . . . 6Erfolgreiches Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Achtung – Lücke! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1www.microfocus.com

Wenn man sich umschaut, ist immer wieder die Softwareentwicklung der treibende Motor

von Innovationen . Etablierte Geschäftsmodelle werden durch Software-Innovationen

durcheinandergebracht, da sie Produkte und Services ermöglichen, die intelligenter und

zielgerichteter sind . Unternehmen investieren hohe Beträge in die Verwaltung ihres Software

Development Lifecycle (SDLC), um sicherzustellen, dass sie diejenigen sind, die den Status-

Quo durcheinanderbringen und nicht diejenigen, die durcheinandergebracht werden .

Es gibt jedoch eine Lücke im SDLC, die die Geschwindigkeit neuer

Anwendungsinnovationen drosselt und zum Ausfall kritischer Geschäftssysteme führt .

Diese Lücke befindet sich zwischen dem Entwicklungs- und dem Betriebsteam: ein

völliges Niemandsland in Bezug auf Verantwortlichkeit, Tools und Fokus . In modernen

Unternehmen muss das Schließen dieser Lücke oberste Priorität haben .

Für stark regulierte Unternehmen (highly regulated large enterprise, HRLE) in Bereichen

wie den Finanzdienstleistungen, Versicherungen, Gesundheitswesen, Luftfahrt, Verteidigung

und Behörden ist der richtige Umgang mit der Lücke sogar von geschäftskritischer

Bedeutung . Ein fehlgeschlagenes Software-Release kann Marken, Ruf, rechtlichen Leumund

und andere Assets für Jahre schädigen .

Immer mehr Unternehmen setzen auf Initiativen, in denen DevOps, Information Technology

Infrastructure Library (ITIL) oder Continuous Delivery (CD) eingesetzt werden, um die

Lücke zwischen Entwicklung und Betrieb zu schließen; trotz der begeisterten Versprechen

ihrer Fans sind diese Ansätze für HRLEs jedoch nicht ausreichend .

Doch welche Möglichkeit haben stark regulierte große Unternehmen, um auf die Lücke

zwischen Entwicklung und Betrieb zu reagieren? Die Antwort könnte die immer beliebter

werdende Methodik des Release Managements liefern .

Warum Release Management so schwierig ist

Am 08. Juli 2015 fiel um 11:32 Uhr morgens die New Yorker Börse (NYSE) aus. Anfänglich

hatten viele Menschen Angst, dass der Ausfall durch eine Cyber-Attacke auf wichtige

Infrastrukturen in den USA verursacht wurde . Es wurde sogar der damalige Präsident

Barack Obama darüber informiert* .

Der Ausfall der NYSE war jedoch nicht böswillig verursacht worden und hätte verhindert

werden können – die Ursache war das fehlgeschlagene Release einer neuer Software .

Laut dem Wall Street Journal bestätigte die NYSE am nächsten Tag, dass „ein Update der

'Matching-Engine' der Börse zu Kommunikationsproblemen zwischen den Händlern und

Wie können stark regulierte große Unternehmen die Lücke zwischen Entwicklung und Betrieb schließen?

__________

* Wenige Stunden zuvor hatte United Airlines Flüge aufgrund eines Routers, der unabhängig ausgefallen war, gestrichen, was noch weiter zur Unsicherheit beigetragen hat.

2

White PaperAchtung – Lücke!

der NYSE geführt hat“ (Hope, 2015). In ihrer offiziellen Aussage erklärte die NYSE, dass „auf

die Kunden-Gateways nicht die richtige Konfiguration geladen wurde, die mit dem neuen

Release kompatibel ist“.

Wenn ein Problem mit dem Release Management dazu führen kann, dass eine der

bedeutendsten Einrichtungen für das reibungslose Funktionieren der Weltwirtschaft

ausfällt, ist dies definitiv ein großes Problem jedes Unternehmens.

Kaum eine Woche vergeht, in der in der Zeitung nicht von irgendeinem Unternehmen

die Rede ist, in dem es aufgrund eines fehlerhaften Software-Releases zu einem Ausfall

gekommen ist . Während des Wochenendes vom 15 . und 16 . August 2015 kam es bei

beinahe 1 .000 Flügen an der Ostküste der USA aufgrund eines fehlgeschlagenen Software-

Upgrades zu Verzögerungen oder Ausfällen . Zahlreiche Sommerurlauber saßen stundenlang

am Flughafen fest und warteten auf ihre Flüge . Das Problem wurde durch einen Fehler

in einer neuen Funktion für das ERAM-System (En Route Automation Modernisation)

verursacht . Nur kurze Zeit zuvor hatte ERAM das bisherige System ersetzt, das die FAA

Flugverkehrskontrollstellen beinahe 40 Jahre lang verwendet hatten (Brown, 2015) .

Probleme mit dem Release Management

In großen IT-Unternehmen gibt es zwei sehr unterschiedliche „Kulturkreise“: die Kultur

der Entwickler und die Kultur der „Betriebler“. Diese Kulturen sind in vielen Bereichen

sehr verschieden: bei ihrem physischen Standort, ihren Fachkenntnissen, Methoden/

Vorgehensweisen, ihrer Erfahrung, ihrem Temperament und ihren Zielen .

Schlägt ein Software-Release fehl, beginnt das Schwarzer-Peter-Spiel .

Das Betriebsteam sagt:

„Wir hatten keine Ahnung, was von der Entwicklung kam.“

Die Entwicklung sagt:

„Auf meinem Rechner hat es funktioniert!“

Die Verantwortlichkeit für das Release einer neuen Software teilen sich zwei sehr

verschiedene Parteien, die Veränderungen aus komplett unterschiedlichen Blickwinkeln

betrachten und für ihre Arbeit vollkommen andere Systeme nutzen . Diese Unterschiede

zusammenzubringen ist nur durch ein effektives Release Management möglich .

Die Verantwortlichkeit für das Release einer neuen Software teilen sich zwei sehr verschiedene Parteien, die Veränderungen aus komplett unterschiedlichen Blickwinkeln betrachten und für ihre Arbeit vollkommen andere Systeme nutzen. Diese Unterschiede zusammenzubringen ist nur durch ein effektives Release Management möglich.

3www.microfocus.com

Änderungsmanagement: notwendig, aber nicht ausreichend

Viele stark regulierte große Unternehmen (HRLEs) haben sich für das Information

Technology Infrastructure Library- (ITIL-)Prozess-Framework entschieden und IT-

Servicemanagementanwendungen implementiert, die mit Änderungsmanagementmodulen

arbeiten, um ihre betrieblichen Prozesse zu unterstützen . Dabei muss beachtet werden,

dass die Begriffe „Änderungsmanagement“ und „Release Management“ zwar oft synonym

verwendet werden, sie aber zwei sehr unterschiedliche und wichtige Bereiche des SDLC

beschreiben . Beim Änderungsmanagement geht es darum, festzulegen, welche Änderungen

akzeptiert, implementiert und bereitgestellt werden . Beim Release Management geht es

hingegen darum, zu entschieden, welche Änderungen kombiniert werden sollten, sie im

Lebenszyklus zu überwachen, ihnen Sichtbarkeit zu verleihen und am Ende sicherzustellen,

dass sie sicher in die Produktion übergeben werden .

Das Release Management ist verantwortlich für die Übergabe und Implementierung der

Änderungsanfrage innerhalb des Entwicklungslebenszyklus der Anwendung . Am Anfang

steht normalerweise die Vergabe eines Namens für das Release, z. B. „Quartal-4-Release“.

Hier werden dem Release Inhalte – zuerst die Änderungsanfragen und dann der Code

und die Anforderungen, Testskripts, Testergebnisse und Freizeichnung – zugewiesen, die

dann von der Entwicklung über die verschiedenen Tests (Systemintegrationstests (SIT)

und Benutzertests (UAT)) in die Vorproduktion / das Staging und dann die Produktion

übergeben werden .

Durch das Release Management wird sichergestellt, dass das Unternehmen den Release-

Prozess während des gesamten Systementwicklungslebenszyklus (SDLC) befolgt

(einschließlich erreichter Meilensteine und eingeholter Genehmigungen) und dass die

richtigen Artefakte vollständig, sicher und schnell von einer Phase zur nächsten übergeben

werden .

Wenn kein stabiles Release Management eingeführt ist, finden HRLE das

Änderungsmanagement und die Kommunikation der Änderungen oft verwirrend und

komplex . Die riesige Anzahl an Änderungen, die jede Woche an die Produktion übergeben

wird, verstärkt dieses Gefühl noch . Indem es mehrere kleinere Änderungen zu einem Satz

zusammenfasst, trägt das Release Management beträchtlich zu einer Verringerung der

Komplexität bei .

Das Release Management ist verantwortlich für die Übergabe und Implementierung der Änderungsanfrage innerhalb des Entwicklungslebenszyklus der Anwendung.

4

White PaperAchtung – Lücke!

DevOps in Reinform fordert eine Vermischung der Rollen und die gemeinsame Übernahme der Verantwortlichkeiten durch die Mitglieder der Entwicklungs- und Betriebsteams. Dies führt in manchen Fällen zu eigenen „DevOps-Abteilungen“, die über ihre eigenen Fachgebiete hinaus geschult werden.

DevOps: Achtung vor den Puristen

Um die Zusammenarbeit und Koordination zwischen Entwicklung und Betrieb zu

verbessern, testen einige Organisationen mittlerweile den Einsatz von DevOps, müssen

jedoch feststellen, dass es für HRLEs nicht das versprochene Wundermittel ist . DevOps

in Reinform fordert eine Vermischung der Rollen und die gemeinsame Übernahme der

Verantwortlichkeiten durch die Mitglieder der Entwicklungs- und Betriebsteams . Dies führt

in manchen Fällen zu eigenen „DevOps-Abteilungen“, die über ihre eigenen Fachgebiete

hinaus geschult werden . In HRLEs gibt es jedoch gute Gründe dafür, die Trennung zwischen

der Entwicklung, der QS und dem Betrieb aufrechtzuerhalten . Beispiele:

Für eine korrekte Einhaltung rechtlicher Vorschriften muss es eine Funktionstrennung zwischen der Entwicklung und dem Betrieb geben. Diese Funktionstrennung ist eine der effektivsten internen Kontrollen, und nur wenige HRLEs würden an dieser Vorgehensweise irgendetwas ändern. Den Entwicklern Zugriff auf die Produktionsumgebung zu verleihen kommt in einem HRLE nicht infrage (Bird, 2014).

Werden die Data Center und Private Clouds in einem gemeinsamen Operations-Team zusammengeführt, während die Entwicklung gleichzeitig bestimmten Geschäftsbereichen zugewiesen ist, führt dies zu Vorteilen bei der Skalierung.

Eine intelligente Aufteilung der Arbeit kann zu mehr Effizienz führen. Die Experten für operative oder technische Fragen (z. B. Lean, Netzwerksicherheit, Oracle-DBA) können produktiver arbeiten, wenn sie ihre Fähigkeiten zielgerichtet einsetzen können, als wenn sie zu „Generalisten“ werden müssten, wie dies bei DevOps angepriesen wird. Und bei der Größe eines HRLE wird es extrem schwierig, sich darauf zu verlassen, derart seltene Exemplare zu finden. Lassen Sie die Entwickler einfach entwickeln!

Einige Kommentatoren haben behauptet, dass DevOps in Großunternehmen „nicht

funktioniert“. So einfach ist es jedoch dann auch nicht (Shannon-Solomon, 2014). Viele

Ideen, die aus der DevOps-Bewegung stammen, haben ihre Berechtigung und sind nützlich .

HRLEs sollten jedoch sehr gut darauf achten, klar zwischen dem, was anwendbar ist und

dem, was schädigend, kostspielig oder undurchführbar ist, zu trennen . Das Konzept eines

„DevOps-Rezeptbuchs“, aus dem HRLEs frei die Ideen auswählen können, die für ihre

Umgebung passend sind, ist verführerisch (Kim, 2015) .

Kontinuierliche Bereitstellung: die eine Hälfte der Lösung

Die kontinuierliche Bereitstellung oder „Continuous Delivery“ (CD) ist ein anderes beliebtes

Verfahren, das von vielen Organisationen eingesetzt wird (Humble & Farley, 2011) . Einer

der wichtigsten Bestandteile der kontinuierlichen Bereitstellung ist die „CD-Pipeline“, die

für eine Automatisierung der Weitergabe des entwickelten Codes innerhalb des SDLC vom

5www.microfocus.com

Building und Testing über das Staging und Promoting bis hin zur Produktion sorgt . Für

die Entwicklung dieser CD-Pipeline setzen Unternehmen Tools zur Automatisierung von

Building, Implementierung und Konfigurationsmanagement ein.

Eine korrekt funktionierende CD-Pipeline spielt eine wichtige Rolle bei der Bereitstellung

eines verbesserten Release Managements . Indem die einzelnen Schritte des SDLC

automatisiert werden, können manuelle Eingriffe vermieden, Fehler verringert und die

Wiederholbarkeit verbessert werden . Besonders bewährt haben sich CD-Pipelines in

Unternehmen, die auf eine einzige Anwendung und eine moderne, einfache Infrastruktur

setzen, z. B. Netflix, Etsy und Box.

In stark regulierten großen Unternehmen ist die Situation jedoch viel komplizierter . Hier

kann es Dutzende, wenn nicht gar Hunderte von Softwareanwendungen mit komplexen

Abhängigkeiten untereinander geben, auf denen einer Unzahl von alten und neuen

Umgebungen (inklusive Mainframe-Systemen) ausgeführt wird . Beispielsweise verwaltet

Generali France, das zweitgrößte Versicherungsunternehmen in Frankreich, insgesamt

470 Anwendungen mit durchschnittlich 200 Produktionsimplementierungen auf dem

Mainframe und 190 in den verteilten Umgebungen .

Aufgrund dieser Komplexität ist es äußerst wichtig für HRLEs, die die kontinuierliche

Bereitstellung einführen, dass sie ihre CD-Pipeline-Initiativen mit einer

Prozessmanagementlösung ergänzen, die es ihnen ermöglicht, die Genehmigungen,

Governance, Umgebungen und die menschlichen Workflows zu kontrollieren, auf denen das

Release Management basiert . Mithilfe von Prozesskontrollen kann sichergestellt werden,

dass die späteren Stage-Umgebungen (z. B. UAT, Vorproduktion und Staging) effizient,

korrekt und verantwortlich verwaltet werden .

HRLEs müssen bei Änderungen in der Produktion sowohl zur Einhaltung rechtlicher

Vorschriften als auch im Sinne der eigenen internen Transparenz nachverfolgen können,

welche Anforderungen, Fehler oder Erweiterungen die Änderung erforderlich gemacht

haben und zu welchen Aktualisierungen des Quellcodes die Änderung geführt hat . Die

CD-Pipelines konzentrieren sich auf die wichtigsten Artefakte (Code, Konfiguration);

eine Komplettlösung muss diese Artefakte mit den restlichen Release-Inhalten (z . B .

Anforderungen, Erweiterungen, Fehler) verknüpfen .

Da ein fehlerhaftes Release mit hohen Kosten verbunden ist, müssen HRLEs in der Lage

sein, die „Reißleine“ zu ziehen, um ein Rollback durchzuführen, sollte in einem Release

etwas schief laufen. CD-Puristen fordern oft die Verfolgung eines „Fix-Forward“-Ansatzes.

Dieser ist jedoch nicht praktikabel, wenn Ausfallzeiten das Unternehmen in die Knie

zwingen können .

HRLEs müssen bei Änderungen in der Produktion sowohl zur Einhaltung rechtlicher Vorschriften als auch im Sinne der eigenen internen Transparenz nachverfolgen können, welche Anforderungen, Fehler oder Erweiterungen die Änderung erforderlich gemacht haben und zu welchen Aktualisierungen des Quellcodes die Änderung geführt hat.

6

White PaperAchtung – Lücke!

Best-Practices beim Release Management: Sechs Schritte zum Erfolg

Wenn aber ITIL, DevOps und kontinuierliche Bereitstellung nicht ausreichend sind: Wie

können HRLEs dann die Lücke zwischen der Entwicklung und dem Betrieb schließen?

Die folgenden sechs Schritte unterstützen HRLEs dabei, die Best-Practices des Release

Managements zu nutzen, um sicherzustellen, dass ihre Anwendungsbereitstellungen

von Erfolg gekrönt sind . Bei einem Vergleich der Vorgehensweisen, die im Folgenden

beschrieben sind, mit denen, die derzeit eingesetzt werden, wird den meisten Unternehmen

bewusst, dass sie noch mehr tun können, um die Lücke zwischen der Entwicklung und dem

Betrieb zu schließen .

Schritt 1: Festlegen eines LeitersDer erste Schritt ist es, einen klaren Leiter festzulegen . Jeder in Frage kommende Leiter

muss als glaubwürdiger und ehrlicher Vermittler gesehen werden, der sich die Probleme

und Bedürfnisse aller Gruppen anhört . Das Unternehmen muss ein Gleichgewicht zwischen

den Zielen der Entwicklung und des Betriebs finden können oder anders ausgedrückt: es

schaffen, schnell zu reagieren, ohne dabei etwas zu zerstören (Hughes, 2015) .

Wenn die Entwicklung verantwortlich für das Release ist, herrscht eine optimistische

Einschätzung bezüglich der Softwareänderungen und einer schnellen Übergabe der

Änderungen in die Produktion . Dies kann jedoch dazu führen, dass die Qualität und die

Produktionsstabilität darunter leiden . Ist der Betrieb verantwortlich für das Release,

herrscht eine eher pessimistische Einschätzung und die Bereitstellungsgeschwindigkeit wird

verlangsamt, um mehr Zeit für Tests zu lassen . Dafür ist jedoch die Produktionsqualität

höher . Aufgrund dieser Differenzen ist in stark regulierten großen Unternehmen oft die

Qualitätssicherheitsabteilung (QS) für das Release Management verantwortlich, da sie sich

„zwischen“ der Entwicklung und dem Betrieb befindet.

Aber aus welchem Bereich die Führungskraft auch stammt: Er oder sie sollte ein gutes

Verständnis des SDLC des Unternehmens, der technischen und prozessbezogenen Aspekte

des Release Managements und des Toleranzrisikos des Unternehmens besitzen (und

versuchen, ein vernünftiges Gleichgewicht zwischen Geschwindigkeit und Vorsicht zu

finden).

Am Wichtigsten ist es, dass der Leiter von der Führungsebene unterstützt und befähigt wird,

Änderungen bei den eingesetzten Entwicklungs-, QS- und Betriebsverfahren umzusetzen .

Der erste Schritt ist es, einen klaren Leiter festzulegen. Jeder in Frage kommende Leiter muss als glaubwürdiger und ehrlicher Vermittler gesehen werden, der sich die Probleme und Bedürfnisse aller Gruppen anhört.

7www.microfocus.com

Eindeutige, messbare Kennzahlen unterstützen dabei, die Entwicklungs- und Betriebsteams bei der Verwirklichung eines gemeinsamen Ziels zusammenzubringen.

Schritt 2: Definieren von Zielen und KennzahlenAls Nächstes müssen die Ziele und Kennzahlen für den Release Management-Prozess

definiert werden. Der Ausgangspunkt ist das Endziel; arbeiten Sie dann heraus, wie Sie

dorthin gelangen . Legen Sie fest, wie Sie Fortschritte auf dem Weg dorthin messen möchten .

Eindeutige, messbare Kennzahlen unterstützen dabei, die Entwicklungs- und Betriebsteams

bei der Verwirklichung eines gemeinsamen Ziels zusammenzubringen . Die Führungsebene

weiß die neue Transparenz des Softwareentwicklungslebenszyklus zu schätzen .

Es gibt viele Möglichkeiten, wie man den Erfolg eines Releases messen kann . Das Vorstellen

möglicher Kennzahlen im Unternehmen unterstützt dabei, für eine gemeinsame Sprache

und das Gefühl von Verpflichtung zu sorgen. So können all die folgenden Beispiele gültige

Ziele sein:

ein größerer Release- (oder Änderungs-) durchsatz

weniger ungeplante Releases

eine bessere Einhaltung des geplanten Umfangs

eine kürzere Vorlaufzeit (die Zeit vom Code-Commit bis zur Produktion)

eine höhere Qualität bei der finalen Lieferung

eine bessere Kenntnis des Timings, des Zeitplans und der Meilensteine des Releases

Dieser Schritt ist abgeschlossen, wenn der Leiter einen Konsens erreicht hat, welche

Reports und Dashboards für den Release Management-Prozess eingesetzt werden sollen .

Im Endeffekt geht es darum, Daten und Berichterstellung in Echtzeit für die Kennzahlen zu

entwickeln, die den Zustand des Release Management-Prozesses messen . Diese Kennzahlen

erfüllen zwei Zwecke: Sie sorgen für eine bessere Sichtbarkeit und ein besseres Verständnis

des Prozesses und ermöglichen die Einführung von Programmen zur kontinuierlichen

Verbesserung .

Schritt 3: Abbilden eines disziplinierten ProzessesDer nächste Schritt ist es, einen disziplinierten, kollaborativen Release Management-Prozess

mit definierten Workflows, Gates, Genehmigungen und Informationsflüssen abzubilden.

Im Allgemeinen besteht ein Release-Prozess aus mehreren Spuren, zum Beispiel einer

schnellen für kleine Notfalländerungen und einer langsameren für große Releases . Auch die

einzelnen Geschäftsbereiche des Unternehmens benötigen immer wieder eigene spezifische

Anpassungen .

8

White PaperAchtung – Lücke!

Abhängig von der Größe des Releases ist es erforderlich, dass viele funktionale Bereiche

im HRLE (z . B . Recht, Compliance, Sicherheit) und die Geschäftsführung das Release

abzeichnen . Hierbei ist es jedoch wichtig, genau darüber nachzudenken, wer wirklich an

dem Genehmigungsprozess beteiligt sein muss, da mehr Genehmiger den Prozess unnötig

verzögern, die Zuständigkeit verschwimmen lassen und das Gefühl von Verantwortlichkeit

verringern . In vielen Unternehmen hat sich herausgestellt, dass durch das Eliminieren von

unnötigen Genehmigungsschritten sowohl die Qualität als auch die Frequenz von Releases

verbessern werden kann, indem die Zuständigkeit auf weniger Personen konzentriert wird .

Es existieren viele mögliche konzeptionelle Frameworks für den Release Management-

Prozess, darunter das Capability Maturity Model (CMM), die CMM-Integration (CMMI),

ITIL Service Transition und die kontinuierliche Bereitstellung, wobei jede dieser Lösungen

ihre eigenen Stärken und Schwächen besitzt . Aufgrund der verschiedenen Reifegrade

innerhalb des Unternehmens müssen HRLEs normalerweise mehrere Prozesstypen

unterstützen können . Um die Anzahl unnötiger Aktivitäten zu verringern, werden oft Lean-

Management-Verfahren eingesetzt .

Für diesen Schritt sollten Unternehmen mindestens sechs bis acht Wochen einplanen . Das

Erlangen eines Verständnisses der vorhandenen Prozesse und die Entwicklung besserer

Prozesse ist ein komplizierter Vorgang, der seine Zeit braucht .

Schritt 4: Kontrollieren der InhalteIm Schritt Vier geht es darum, die Kontrolle über die vorhandenen Inhalte zu

erlangen . Hierzu muss eine Strategie entwickelt werden, die sicherstellt, dass alle

Anwendungsartefakte (und nicht nur der Quellcode) von der Versionskontrolle erfasst

werden und so viel Automatisierung wie möglich innerhalb des Anwendungs-Release-

Prozesses eingesetzt wird . Inkonsistenzen zwischen den verschiedenen Umgebungen

(Entwicklung, Komponententests, Systemintegrationstests, UAT, Vorproduktion und

Produktion) aufgrund von nicht kontrollierten Assets können unnötige Probleme

verursachen . Und im schlimmsten Fall können sie zu Fehlern in späten Phasen der

Implementierung führen .

HRLEs sollten ein einziges, abgesichertes Quellcodemanagementsystem einführen,

um sicherzustellen, dass ihre Software-Assets sicher und kontrolliert sind . Zu viele

Unternehmen lassen ein unkontrolliertes Wachstum der Quellcode-Repositorys zu;

eine Situation, die noch verschlimmert wird, wenn die Repositorys auf Open Source-

Technologien wie GIT und Subversion basieren, die von Entwicklern für Entwickler

entworfen wurden, ohne die Sicherheit und Compliance zu bieten, die von HRLE benötigt

wird .

HRLEs sollten ein einziges, abgesichertes Quellcodemanagementsystem einführen, um sicherzustellen, dass ihre Software-Assets sicher und kontrolliert sind.

9www.microfocus.com

Schritt 5: Entwickeln der unterstützenden InfrastrukturSobald das Unternehmen bei den bisherigen Schritten Fortschritte gemacht hat, kann es

mit der Auswahl der Tools, die das Release Management unterstützen sollen, beginnen .

Kaufinteressenten sollten hierbei nicht nur auf besondere funktionale Kriterien achten,

sondern den potenziellen Anbietern auch immer die folgenden Fragen stellen:

Wie viel Erfahrung besitzt der Anbieter damit, auf die besonderen Anforderungen stark regulierter großer Unternehmen einzugehen? Ist er für seine Erfolge in diesem komplexen Bereich bekannt?

Bietet er mit seinen Produkten vorkonfigurierte Sicherheit und Compliance oder müssten diese Aspekte nachträglich hinzugefügt werden? Können die Produkte über stark verteilte Unternehmensteams hinweg skaliert werden oder sind sie nur für kleinere Arbeitsgruppen geeignet?

Bietet er ein integriertes Portfolio an Produkten – für die Quellcodeverwaltung, die Prozesskontrolle, die Automatisierung der Anwendungsimplementierung – die ohne umfangreiche Anpassung und Maintenance zusammen funktionieren? Funktionieren sie auch zusammen mit den anderen Tools im vorhandenen SDLC? Unterstützt der Anbieter Unternehmen, die unterschiedliche Mainframes und offene Systeme nutzen?

Schritt 6: Einführen eines Governance-AnsatzesAls Letztes muss das Unternehmen einen Governance-Ansatz für das Release Management

einführen . Voraussetzung einer guten Release-Governance ist ein gut funktionierender

Änderungsmanagementprozess inklusive mehrerer hierarchischer Change Advisory Board-

(CAB-) Prozesse . Die CABs der höheren Schichten konzentrieren sich auf Ausnahmen

und prüfen nur die Releases, die von einem niedrigeren Change Advisory Board eskaliert

wurden .

Damit sie funktionieren können, benötigen die CABs genaue Informationen, einen

kontrollierten Prozess und einen lebendigen Release-Kalender . Es muss also das gesamte

Umfeld stimmen, wenn die CABs effektiv funktionieren sollen . In den meisten HRLE gibt es

bereits eine Anwendung, die den Änderungsmanagementprozess in betrieblichen Aspekten

unterstützt . Damit ein Echtzeit-Austausch von Informationen zwischen dem Betrieb und

dem Release möglich wird, müssen die Release Management-Lösung und das vorhandene

Änderungsmanagementtool zusammenarbeiten .

Erfolgreiches Release Management

In Unternehmen, in denen diese sechs Schritte befolgt werden, ist das Release Management

ein gut eingespielter Prozess, der mit den folgenden Attributen beschrieben werden kann:

Sichtbar: Der gesamte Status der anstehenden Software-Releases ist für jeden ersichtlich.

Kontrolliert: Jeder Schritt im Prozess wird umgesetzt und überwacht und Ausnahmen sind eine Seltenheit.

Damit sie funktionieren können, benötigen die CABs genaue Informationen, einen kontrollierten Prozess und einen lebendigen Release-Kalender.

10

White PaperAchtung – Lücke!

Konform: Ein Aufzeichnungssystem liefert alle Daten, die von den Revisoren und Aufsichtsbehörden benötigt werden.

Fehlerlos: Die Software-Updates funktionieren wie gewünscht oder werden sofort repariert.

Schnell: Die Software wird innerhalb von Stunden und Tagen anstelle von Wochen und Monaten veröffentlicht.

Effizient: Sonderschichten in der Nacht und am Wochenende kommen selten vor und Automatisierung wird umfangreich eingesetzt.

Sicher: Der Prozess, das geistige Eigentum und die Anwendung sind vor Bedrohungen geschützt.

Laut Cyril Thenon, Manager des Leistungs- und Industrialisierungs-Skill-Centers von

Generali, hatte Generali France beispielsweise drei Ziele für seine Release Management-

Initiative: „Eine Verringerung der Release-Komplexität; eine Verkürzung des

Bereitstellungszyklus, so dass er in nur wenigen Klicks durchgeführt werden konnte; und die

Einhaltung der neuesten Richtlinien“.

Achtung – Lücke!

Um in der modernen Welt mithalten zu können, muss die Softwareentwicklung in nahezu

allen Unternehmen schneller werden . Die Lücke zwischen der Entwicklung und dem Betrieb

behindert jedoch oft das Ziel, den Softwareentwicklungslebenszyklus zu beschleunigen .

Daher hat das Schließen dieser Lücke oberste Priorität, insbesondere bei HRLEs .

In den stark regulierten großen Unternehmen wird die Lücke zwischen der Entwicklung und

dem Betrieb nicht einfach so verschwinden – den optimistischen Worten der DevOps-Fans,

ITIL-Befürworter und Anhänger der kontinuierlichen Bereitstellung zum Trotz . Vernünftiger

wäre es für die Unternehmen also, die Lücke zu schließen, indem sie zu Experten im Release

Management werden . Wenn sie die sechs in diesem Paper vorgestellten Schritte befolgen,

sind die Unternehmen bereits auf einem guten Weg zum Erfolg .

Nur wenige Unternehmen haben bisher alle sechs Schritte abgeschlossen . In den meisten

Unternehmen gibt es also noch Potenzial für eine kontinuierliche Verbesserung . Wenn Ihr

Unternehmen gerade erst damit beginnt, sich mit dem Thema Release Management vertraut

zu machen, dann besteht der erste Schritt darin, einen Leiter zu definieren. Wenn Sie

bereits über einen Leiter verfügen, sorgen Sie für Konsens bezüglich der richtigen Ziele und

Kennzahlen . Ist dies erfolgt, machen Sie mit den anderen Schritten weiter . Ganz egal, wo Sie

sich gerade auf Ihrem Weg zu einem besseren Release Management befinden: Es gibt immer

mehr, was man tun kann, um die Lücke zu schließen!

Um in der modernen Welt mithalten zu können, muss die Softwareentwicklung in nahezu allen Unternehmen schneller werden. Die Lücke zwischen der Entwicklung und dem Betrieb behindert jedoch oft das Ziel, den Softwareentwicklungsle-benszyklus zu beschleunigen.

11www.microfocus.com

Danksagungen

Ohne die Hilfe meiner Kollegen bei Serena (jetzt Micro Focus), die Experten für die Themen

„SDLC“ und „Release Management“ sind, hätte ich dieses White Paper nicht schreiben

können . Besonders dankbar bin ich Tom Clement, Julian Fish, Steve LeWarne und Kevin

Parker für die wertvollen redaktionellen Kommentare und ihren Input .

Literaturverzeichnis

Bird, J . (09 . Januar 2014) . Developers working in Production . Of course! Maybe, sometimes .

What, are you nuts? Aus „Building Real Software: Developing and Maintaining Secure and

Reliable Software in the Real World“: swreflections.blogspot.com

Brown, L. (17. August 2015). Pressemitteilung: „FAA Statement on Automation Problems at

Washington Center.“ Von der Website der Federal Aviation Administration: www.faa.gov

Hope, B. (10. Juli 2015). NYSE Says Wednesday Outage Caused by Software Update. Wall

Street Journal.

Hughes, G . (2015) . Move Fast Without Breaking Things . San Mateo, CA: Serena Software .

Humble, J ., & Farley, D . (2011) . Continuous Delivery: Reliable Software Releases through

Build, Test, and Deployment Automation . Pearson Education, Inc .

Kim, G . e (2015) . The DevOps Cookbook . Veröffentlichung geplant für das Jahr 2015 –

früher Entwurf, überprüft durch den Autor .

Serena Software, Inc . (n .d .) . Generali France Achieves Greater Agility, Improved

Performance and Enhanced Security in its Release Process with Serena .

Shannon-Solomon, R . (Mai 2014) . DevOps is Great for Startups, but for Enterprises It Won’t

Work—Yet. Wall Street Journal.

162-DE0079-001 | S | 04/17 | © 2017 Micro Focus. Alle Rechte vorbehalten. Micro Focus und das Micro Focus Logo sowie andere Namen sind Marken oder eingetragene Marken von Micro Focus oder Tochterunternehmen bzw. Schwestergesellschaften in Großbritannien, den USA und anderen Ländern. Alle weiteren Marken sind Eigentum ihrer jeweiligen Inhaber.

www.microfocus.com

Micro FocusDeutschlandFraunhoferstraße 7D-85737 Ismaning00 800-58102130

Micro FocusSchweizMerkurstrasse 148953 DietikonSwitzerland00 800-58102130

Micro FocusFirmenhauptsitzVereinigtes Königreich+44 (0) 1635 565200

www.microfocus.com