Best Practices für ein agiles Änderungs- und Release Management von Ben Cody, Julian Fish und Amita Abraham November 2012

White Paper

Inhaltsverzeichnis Seite

Eine Flut von Vorfällen am Service-Desk infolge eines schlechten Änderungsmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Das Dilemma der Dev-Ops-Kluft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Best Practices für ein agiles Änderungs- und Release Management . . . . . . . . . 3Unterm Strich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1www.microfocus.com

Eine Flut von Vorfällen am Service-Desk infolge eines schlechten Änderungsmanagements

Das Dilemma der Dev-Ops-Kluft

Geschäfte werden zunehmend online geführt . Um wettbewerbsfähig zu bleiben, muss Ihre

IT-Organisation kontinuierlich innovative Anwendungen und Dienste bereitstellen, die Ihr

Unternehmen sehr häufig nach außen hin repräsentieren. Die Fähigkeit, Änderungen an

diesen Anwendungen schnell vorzunehmen, ohne an Stabilität der Infrastruktur einzubüßen,

ist nicht mehr nur eine Option, sondern eine Notwendigkeit .

Um wettbewerbsfähig zu bleiben, muss Ihre IT-Organisation kontinuierlich innovative Anwendungen und Dienste bereitstellen, die Ihr Unternehmen sehr häufig nach außen hin repräsentieren.

Abb. 1

Quelle: Forrester/ itSMF Q2 2011 US ITSM Online Survey

Inhaltsverzeichnis Seite

Eine Flut von Vorfällen am Service-Desk infolge eines schlechten Änderungsmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Das Dilemma der Dev-Ops-Kluft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Best Practices für ein agiles Änderungs- und Release Management . . . . . . . . . 3Unterm Strich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2

White PaperBest Practices für ein agiles Änderungs- und Release Management

Entwicklungsunternehmen haben auf dieses Bedürfnis reagiert, indem sie agile Methoden

eingeführt haben . Sie können neue oder aktualisierte Anwendungen und Dienste jetzt

schnell in den IT-Betrieb pushen . Dadurch müssen die IT-Betriebsteams diese Änderungen

jedoch in aller Eile implementieren, ohne dabei zusätzliche Risiken zu verursachen . Da in

den meisten Unternehmen die Übergabe zwischen diesen beiden Teams nicht gerade perfekt

abläuft, überrascht es kaum, dass aktuellen Studien* zufolge mehr als 40 % der an Service-

Desktops gemeldeten Vorfälle das Ergebnis fehlgeschlagener Änderungen an Anwendungen

und der unterstützenden Infrastruktur sind . Eine fehlende Verbindung von Entwickler- und

Betriebsteams im Prozess kann die Fähigkeit der Umsatzgenerierung eines Unternehmens

ernsthaft beeinträchtigen .

Die Tatsache, dass die meisten IT-Betriebsteams für die Verwaltung von Vorfällen,

Problemen und Änderungen in Bezug auf die IT-Infrastruktur ihre eigenen Systeme

nutzen, verschärft die Probleme im Prozess noch weiter . Diese Systeme unterscheiden

sich häufig von denen, die von den Anwendungsentwicklerteams verwendet werden,

um Anforderungen, Vorfälle, Verbesserungen und Änderungsanfragen zu überwachen .

Die IT-Betriebsteams haben für gewöhnlich keinen Zugriff auf oder Einblick in die

Fehlerbehebungen und Änderungen, die von den Anwendungsentwicklerteams

vorgenommen wurden . Auf ähnliche Art haben die Entwicklerteams nur selten Zugriff auf

die Tools, die von IT-Betriebsteams für die Nachverfolgung von Vorfällen, Problemen und

Änderungen verwendet werden. Diese funktionsspezifischen Silo-Systeme verschärfen das

Problem zusätzlich .

Die Probleme, die nicht aufeinander abgestimmte Prozesse und Tools verursachen, werden

im folgenden Beispiel der Freigabe eines neuen Online-Transaktionsportals bei einem

Telekommunikationsanbieter deutlich . Das Entwicklerteam informierte das IT-Betriebsteam

erst wenige Tage vor der Freigabe, dass in der Produktionsumgebung eine andere Version

der Oracle-Datenbank erforderlich war . Da das IT-Betriebsteam nur begrenzt Einblick

in die Versionsdetails hatte, kannte es die Bereitstellungsverfahren nicht und wusste

nicht, dass ein Upgrade der Datenbank erforderlich war . Zusätzlich wurde die Situation

dadurch erschwert, dass die anderen Anwendungen, die die Oracle-Datenbankinstanz

ebenfalls nutzten, mit der neueren Version nicht kompatibel waren . Letztlich war das

IT-Betriebsteam gezwungen, mühsam zusätzliche Hardware aufzutreiben und eine neue

Instanz der Datenbank zu aufzubauen . Dies führte zu einer teuren und verzögerten

Anwendungsfreigabe, die den Umsatz beeinträchtigte und einen tieferen Keil zwischen die

Entwickler- und Betriebsabteilungen trieb .

Die Auswirkungen einer fehlenden Zusammenführung der Personen, Prozesse und Systeme

in Entwickler- und Betriebsteams auf das Unternehmen werden offensichtlich, wenn

Anwendungen, die die Pfeiler eines Unternehmens sind, wegen fehlerhafter Änderungen

und Versionen instabil werden .

40 % der Vorfälle an Service-Desks sind die Folge fehlgeschlagener Änderungen an Anwendungen und ihrer unterstützenden Infrastruktur.

__________

* Forrester/ itSMF Q2 2011 US ITSM Online Survey

3www.microfocus.com

Wie vereinfachen Sie also Prozesse, die Ihre Entwickler- und Betriebsteams umspannen?

Wie verbessern und beschleunigen Sie das Änderungs- und Release Management, ohne die

Stabilität und Steuerung der Umgebung zu gefährden?

Best Practices für ein agiles Änderungs- und Release Management

Nur ein Kanal für alle VorfälleWenn Ihre Kunden Probleme mit einer Anwendung erleben oder neue Funktionen

benötigen, senden sie in der Regel eine E-Mail oder erfassen ihre Bedürfnisse in einem

Tabellen- oder Word-Dokument . Das Problem bei diesem Ansatz besteht darin, dass diese

Anfragen und Probleme durch Lücken im System rutschen können . Ihre Kunden können

den Status ihrer Anfragen nicht einfach überwachen . Ein zentralisiertes Portal, mit dem Ihre

Kunden interagieren können, um Tickets zu übermitteln und ihren Status nachzuverfolgen,

kann die Kundenzufriedenheit enorm verbessern . Bei der Vorbereitung eines Releases

muss ein Manager der Anwendungsentwicklung beispielsweise vielleicht anfordern, dass

das Infrastruktur-Team einem vorhandenen Server-Cluster einen zusätzlichen Web-Tier

hinzufügt, um die Überarbeitung einer Anwendung zu bewältigen .

_______________________________________________________________

Ein einheitliches Portal für Anfragen leitet Vorfälle zur schnellen Problembehebung sowohl an die Entwickler- als auch Betriebsteams weiter.

Abb. 2

Ein zentralisiertes Portal, das Vorfälle kanalisiert und SLAs anzeigt.

4

White PaperBest Practices für ein agiles Änderungs- und Release Management

Ein integriertes Änderungs- und Release Management beschleunigt Anwendungsänderungen bis in die Produktion.

Ein zentrales Portal, in dem die entsprechenden Service-Level-Agreements (SLAs)

angezeigt und die erforderlichen Kostenstellen-Informationen für die Abrechnungen

und Genehmigungen gesammelt werden, kann den Prozess der Einführung von

Anwendungsänderungen weiter optimieren . Darüber hinaus kann ein einheitliches Portal

für Anforderungen, das Vorfälle dann automatisch an die richtigen Teams – ob innerhalb

Ihrer Anwendungsentwickler- oder Betriebsgruppen – weiterleitet, die Teams bei einer

schnellen Reaktion und Behebung von Problemen unterstützen .

Änderungs- und Release Management-Prozesse integrierenDurch die Integration und Automatisierung von Prozessen im Änderungs- und Release

Management ist es nicht mehr erforderlich, komplexe Bereitstellungsskripte zu schreiben .

Auch die Möglichkeit von menschlichen Fehlern bei der Freigabe von Änderungen in die

Produktion entfällt .

Der Schlüssel liegt darin, sowohl den Betriebs- als auch den Entwicklerteams vollständige

Einblicke in die geplanten Änderungen und die geplanten Einführung dieser Änderung

zu geben . Anfragen für Änderungen und Fehlerbehebung werden an die Entwicklerteams

weitergegeben . Um die Einführung dieser Änderungen in die Produktion zu unterstützen,

profitieren diese Teams von klaren Einblicken in verfügbare, vordefinierte Änderungsfenster

für Produktionsumgebungen, sogenannte Release Trains . Release Trains unterstützen

kombinierte Anforderungen sowohl für Anwendungs- als auch Betriebsänderungen in einem

geplantem Fenster und die Einführung zu einem Zeitpunkt, der für beide Teams günstig ist .

Wenn sowohl Entwickler als auch Betriebsteam die verfügbaren Release Trains klar

erkennen, Funktionen ganz einfach mit geplanten Betriebsänderungen kombinieren

und dann den Fortschritt des Releases während der gesamten Entwicklungs-, Test-

und Produktionsumgebung nachverfolgen können, sinkt das Risiko fehlgeschlagener

Änderungen ganz erheblich . Dadurch, dass sie die an der ursprünglichen Anfrage

vorgenommenen Änderungen nachverfolgen können, sind IT-Organisationen besser

dafür gerüstet, ihren entsprechenden Geschäftsabteilungen akkurate und ausführliche

Statusaktualisierungen zu geben .

_______________________________________________________________

5www.microfocus.com

Dank verknüpfter Prozesse können Entwicklerteams die mit einer Anfrage verknüpften

Änderungen auf Quellcode-Ebene nachverfolgen, während sie von der Entwicklung

durch Testumgebungen bis zur Produktion fortschreiten . Sobald eine Anwendung

in der Produktion bereitgestellt wurde, sollten Aktualisierungen automatisch über

den Eintrag in der Definitive Medial Library (DML) der Anwendung erfolgen. Wenn

diese Anwendungsprozesse zur Verwaltung der Infrastruktur mit einer Configuration

Management Database (CMDB) verknüpft sind und Aktualisierungen unmittelbar

nach Freigabe der Änderungen an Komponenten vorgenommen werden, ermöglicht

das eine vollständige und konsistente Aufzeichnung der in der Produktion befindlichen

Komponenten .

Wenn Ihre Entwickler- und Betriebsteams mithilfe integrierter Prozesse an einem Strang

ziehen, sind sie besser in der Lage, Anwendungsänderungen schnell zu veröffentlichen, um

das Unternehmen zu unterstützen, ohne die Stabilität der Betriebsumgebung zu gefährden .

Wenn Ihre Entwickler- und Betriebsteams mithilfe integrierter Prozesse an einem Strang ziehen, sind sie besser in der Lage, Anwendungsänderungen schnell zu veröffentlichen, um das Unternehmen zu unterstützen, ohne die Stabilität der Betriebsumgebung zu gefährden.

Abb. 3

Kombinieren Sie Anwendungs- und Betriebsänderungen in einem einzigen Release Train.

6

White PaperBest Practices für ein agiles Änderungs- und Release Management

Ein einheitlicher Kalender für vollständige TransparenzEin integrierter Kalender, auf den sowohl die Entwickler- als auch die Betriebsabteilung

Zugriff haben und der alle geplanten Änderungen pro Woche oder Monat anzeigt, sorgt

dafür, dass alle Teams über geplante Aktualisierungen für Anwendungen informiert sind .

_______________________________________________________________

Es ist sowohl für Entwickler- als auch für Betriebsteams hilfreich, die verschiedenen

Anwendungen zu sehen, die von einem Freigabeprozess betroffen sind, und weitere

Details einer Anfrage oder Änderung abrufen zu können . Dabei sollten die Details der

Anwendungsänderungen bis hin zu den bereitzustellenden Artefakten sowie Informationen

zu Infrastrukturänderungen berücksichtigt werden . Ein einheitlicher Änderungskalender

bietet Entwicklerteams, Release Managern und Betriebsteams eine konsolidierte Übersicht

aller geplanten Software- und Infrastrukturänderungen .

Ein einheitlicher Kalender bietet Transparenz bei den für die Änderungsfreigabe verfügbaren Fenstern.

Abb. 4

Ein einheitlicher Kalender für vollständige Transparenz in Entwicklung und Betrieb

7www.microfocus.com

Durch die Verknüpfung von Prozessen während der Entwicklung und des Betriebs steigt die geschäftliche Zufriedenheit mit der IT, da Vorfälle und Probleme bis zur Behebung überwacht werden, Anwendungsänderungen frühzeitiger erfolgen und Geschäftsbenutzer proaktiv benachrichtigt werden, wenn Probleme behoben sind.

Durch Nutzung eines einheitlichen Kalenders sind sich die Entwickler- und Release-

Teams der verfügbaren Fenster für Änderungen sowie der geplanten Stillstandszeiten

für die Produktion vollständig bewusst . Dank dieses Wissens können diese Teams dann

die optimalen Zeitpunkte auswählen, um eine Änderung der Infrastruktur anzufordern,

beispielsweise um aktuelle Probleme mit der Anwendungsleistung zu beheben . Sobald eine

Betriebsänderung mit einem Release Train verknüpft ist, sollte die Änderungskontrolle an

diesen Train übergeben werden . Wenn der Train genehmigt und implementierungsbereit

ist, sollten die Betriebsteams automatisch benachrichtigt werden, um die erforderlichen

Änderungen der Infrastruktur vorzunehmen und gleichzeitig die SLAs einzuhalten . Dieser

Prozess sollte fortgesetzt werden, bis alle Änderungen am Release Train implementiert

sind . Nach einer Überprüfung nach erfolgter Implementierung sollten Änderungen am

Configuration Management System (CMS) vorgenommen werden, die die CMDB sowie die

DML umfassen .

Durch die Verknüpfung von genehmigten Entwicklungs-Releases mit bestehenden Fenstern

für die betriebliche Wartung können die Teams Release-Verzögerungen und Verwirrungen

bei der Bereitstellung vermeiden .

Unterm Strich

Großunternehmen führen ihr Geschäft zunehmend online, und ein schnelles

Änderungsmanagement ist dabei ein entscheidender Faktor . Es dient letztendlich dem

Unternehmen, wenn die Teams für DevOps oder Release-Management das Bindeglied sind,

das Entwickler- und Betriebs-Teams zusammenhält . Tools und Systeme, die Menschen

und Prozesse in Entwicklung und Betrieb verbinden, können diesen Teams wirkungsvoll

die erforderlichen Einblicke verschaffen, um Änderungsanfragen für Anwendungen zu

bearbeiten und zu beschleunigen . Eine integrierte Strategie für das Änderungs- und Release

Management verringert zudem die Anzahl von Vorfällen . Studien zufolge sind 40 % aller

gemeldeten Vorfälle das Ergebnis fehlgeschlagener Änderungen . Durch die Verknüpfung

von Prozessen während der Entwicklung und des Betriebs steigt die geschäftliche

Zufriedenheit mit der IT, da Vorfälle und Probleme bis zur Behebung überwacht

werden, Anwendungsänderungen frühzeitiger erfolgen und Geschäftsbenutzer proaktiv

benachrichtigt werden, wenn Probleme behoben sind .

162-DE0086-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