der praktische leitfaden für enterprise devops und ...€¦ · devops wird von organisationen...

1

Der praktische Leitfaden für Enterprise DevOps und Continuous Delivery

2

Inhalt

Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Das Geschäftsproblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Continuous Delivery: Schnellen, wettbewerbsfähigen Änderungen angepasste Bereitstellung . . . . . . . . . . . . . . . . . 11

3 Continuous Delivery: Die Herausforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Automatisierung der Bereitstellungs-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3

Julian Fish ist Micro Focus Director of Products für Release- und Bereitstellungsmanagementlösungen. Julian verfügt über mehr als 15 Jahre Erfahrung in der IT-Branche. Er begann in der Qualitätssicherung, bevor er sich in so verschiedenartigen Domänen wie Infrastrukturverwaltung, Datenbankadministration, Softwareentwicklung, Release-Engineering und IT-Operationen betätigte. In den letzten Jahren hat Julian zahlreiche große Organisationen bei der Transformation ihrer Entwicklungs- und Release-Managementprozesse unterstützt. Julian besitzt einen Abschluss in Angewandter Geologie mit Auszeichnung der University of Leicester.

Über den Autor

4

Einleitung

Wahrscheinlich interessiert Sie diese Broschüre, weil Sie ein besseres Verständnis für die Einführung von

kontinuierlicher Bereitstellung (Continuous Delivery, CD) und DevOps im Enterprise Software-Segment

erwerben möchten . Sie und Ihr Unternehmen haben Bedenken im Hinblick auf die sich beschleunigende

Änderungsrate in dem Markt, in dem Sie wettbewerbsfähig bleiben müssen . Daher sind Sie ständig auf

der Suche nach Möglichkeiten, Volumen und Geschwindigkeit Ihrer Änderungen zu erhöhen, um die

Markteinführungszeit zu verkürzen . Die IT-Landschaft ist zunehmend dienstleistungsbezogen geworden .

Mehr als je zuvor erwarten Kunden bessere Services . Die Interaktion zwischen Verbraucher und

Unternehmen läuft heute in praktisch jedem Unternehmen zunehmend auf digitaler Ebene ab . Weil sich

Verbraucher an die kontinuierliche Änderung und Verbesserung der von ihnen verwendeten Apps gewöhnt

haben, müssen Sie in der Lage sein, die Erwartung Ihrer Kunden zu erfüllen .

Diese Broschüre ist für Vordenker in Unternehmen, die beabsichtigen, die Geschwindigkeit und das Volumen

von Änderungen zu erhöhen, die bei kritischen und umsatzgenerierenden IT-Services relevant sind . Da sie

gleichzeitig bemüht sind, die Stabilität, Sicherheit und Verfügbarkeit der von ihnen gelieferten Services zu

wahren, ist dieses Ziel schwierig zu erreichen . Diese Broschüre zeigt, wie Unternehmen zahlreiche Wege

erkunden, um die sichere Bereitstellung strategischer Geschäftslösungen zu beschleunigen . Dabei suchen

sie nach Möglichkeiten, Neuerungen schneller einzuführen, um mit agileren Konkurrenten Schritt zu halten,

oder in einem überfüllten Markt die Führung zu übernehmen . Diese Unternehmen wollen mehr als nur die

beschleunigte Bereitstellung von Releases . Sie möchten ihre bisherige Unternehmenskultur in eine Kultur

ändern, in der Anwendungen kontinuierlich weiterentwickelt werden . Damit nehmen sie Abschied von

dem Konzept sequenzieller, serieller Versionen mit langen Vorlaufzeiten und geringer Bereitstellung von

Funktionen .

Wenn Sie beabsichtigen, als Teil Ihres DevOps-Transformationsprogramms eine Strategie kontinuierlicher

Bereitstellung für Unternehmensanwendungen einzuführen, lesen Sie bitte weiter – diese Broschüre ist

für Sie .

„Früher ging es bei geschäftlichem Erfolg nur um Größe: Die Großen fressen die Kleinen. Heute geht es um Geschwindigkeit:Die Schnellen fressen die Langsamen.“

Daniel Burrus

Futurist

5

Was versteht man unter Continuous Delivery?

Bei der kontinuierlichen Bereitstellung (Continuous Delivery) handelt es sich um einen Software

Engineering-Ansatz, der den gesamten Prozess der Veröffentlichung von Software beeinflusst . Zwar

stellt die Automatisierung von Prozessen für das Entwickeln, Testen und Bereitstellen von Anwendungen

eine wesentliche Komponente der kontinuierlichen Bereitstellung dar, aber eine wahrlich kontinuierliche

Bereitstellungslösung ist nicht ohne größeren Konfigurationsaufwand umzusetzen . Eine solche Lösung

kann ein gewisses Maß an organisatorischen Veränderungen erfordern . Alle, die mit dem Prozess der

Veröffentlichung von Unternehmenssoftware zu tun haben, müssen dies berücksichtigen – nicht nur die

Entwicklung, sondern auch Qualitätssicherung, IT-Operationen und das Unternehmen als Ganzes spielen hier

eine Rolle .

In den vergangenen zwei Jahrzehnten hatte die Einführung agiler Entwicklungsverfahren eine drastische

Auswirkung auf das Bereitstellen von Software durch Unternehmen . Entwicklungsteams können

Anwendungen jetzt viel schneller erstellen und aktualisieren . Das Produkt wird als eine sich ständig

weiterentwickelnde, ständig zu verbessernde Code-Basis betrachtet, die sich an den Anforderungen des

Unternehmens orientiert . Bis vor Kurzem allerdings wurde diese neu erworbene Agilität von fachbezogenen

Teams nicht immer mit der gleichen Bereitschaft angenommen .

Continuous Delivery ist ein Mechanismus, der sowohl die Agilität als auch die Geschwindigkeit des

Bereitstellungsprozesses erhöht . Ihr Erfolg hängt letztlich von der Auflösung der Grenzen zwischen

Entwicklung, Qualitätssicherung und IT-Operationen ab, sodass der gesamte Software-Lebenszyklus

kontinuierlich in einer unternehmensorientierten Weise abläuft .

Was ist DevOps?

Zum Begriff „DevOps“ gibt es unzählige widersprüchliche Informationen . DevOps wird von Organisationen

aller Arten als Teil der „neuesten IT-Mode“ betrachtet und zur Vermarktung ihrer Bücher, Software, Hardware,

Services und Seminare eingesetzt . Ein DevOps-Logo lässt sich leicht auf einem Produkt anbringen, aber das

allein macht DevOps nicht aus .

Wikipedia beschreibt DevOps als eine „Kultur, Bewegung oder Praktik, die die Bedeutung der

Zusammenarbeit und Kommunikation sowohl zwischen Softwareentwicklern als auch anderen IT-Experten

betont, und dabei gleichzeitig Praktiken für die Automatisierung der Softwarebereitstellung und Änderungen

an der Infrastruktur unterstützt . Das Ziel besteht darin, eine Kultur und Umgebung zu schaffen, in der

Software schnell, regelmäßig und zuverlässig entwickelt, getestet und veröffentlicht werden kann .“1 Außerdem

handelt es sich bei DevOps um eine Kombination aus Entwicklungs- und Operationspraktiken, Richtlinien,

Prozeduren und Prozessen . In der Welt der Unternehmenssoftware bietet DevOps ein Instrument für den

organisatorischen Wandel von isolierten, traditionell gegnerischen Gruppen zu kollaborativen Teams mit

geteilter Eigentümerschaft, einem gemeinsamen Ziel und kollektiver Verantwortung .

1Entnommen von https://en .wikipedia .org/wiki/DevOps

https://en.wikipedia.org/wiki/DevOps

6

Die vorige Generation von Projekten zur Unternehmenstransformation entsprang der schnellen Einführung

agiler Praktiken in den 2000er Jahren . Heute beginnen DevOps-Initiativen häufig, wenn ein Executive-

Sponsor Geschichten von erfolgreichen Implementierungen in Organisationen von hohem Wert bei niedrigem

Ressourcenbedarf hört . Wenn DevOps von Netflix, Facebook und Google erfolgreich implementiert werden

kann, um eine neue Funktion schneller auf den Markt zu bringen, fragt der Sponsor, warum sie nicht das

Gleiche tun können . DevOps definiert Praktiken, Prozesse und Strategien zur Förderung der Zusammenarbeit,

Effizienz und Kommunikation zwischen Teams, die End-to-End in der DevOps-Landschaft involviert sind .

Davon sind benachbarte Teams betroffen, die eine Rolle bei der Initiative spielen . Diese umfassen (sind

aber nicht beschränkt auf) Architektur-, Infrastruktur-, Qualitätssicherungs-, Produktionsunterstützungs-,

Änderungs- und Freigabeteams . Diese Teams sollen zusammengefasst und hinsichtlich Prozess und

Technologie aufeinander abgestimmt werden, damit Unternehmen den End-to-End-Prozess ihrer

Anwendungsbereitstellung optimieren können . Dies führt zu schnelleren, hochwertigeren Releases mit

geringerem Risiko und niedrigeren Kosten .

In dieser Broschüre wird DevOps aus einer Software-/Anwendungsentwicklungs- und Bereitstellungs-

Perspektive behandelt, aber es gibt eine Reihe weiterer wichtiger Disziplinen, die Teil jeder größeren DevOps-

Initiative sein müssen . Dazu zählen:

• Codieren – Tools für die Entwicklung und Überprüfung von Code, statische Codeanalyse und kontinuierliche Integration (CI)

• Erstellen – Tools für Versionskontrolle, Codezusammenführung und Build-Status

• Testen – Kontinuierliche Tests, Testautomatisierung und Ergebnisse zur Ermittlung der Leistung

• Verpacken – Artefakt-Repository, Anwendungs-Staging vor der Implementierung

• Veröffentlichen – Änderungsmanagement, Release-Genehmigungen, Release-Automatisierung, Provisioning

• Konfigurieren – Konfiguration und Verwaltung der Infrastruktur, Tools für Infrastruktur als Code

• Überwachen – Überwachen der Anwendungsleistung, Arbeitsumfeld des Endbenutzers

Die wichtigsten Themen in dieser Broschüre sind Codieren, Erstellen, Testen, Verpacken und Veröffentlichen .

Konfigurieren und Überwachen gehen über ihren Umfang hinaus .

7

Was Ihnen diese Broschüre bietet

Viele Unternehmen benötigen Hilfe beim Wandel ihrer Organisation zur Unterstützung von kontinuierlicher

Bereitstellung, und zwar nicht einfach durch einen Softwareanbieter, sondern über einen Partner für

die Bereitstellung . Dieser Partner muss ein umfassendes Verständnis des Unternehmens und seiner

geschäftlichen Initiativen erwerben . Außerdem muss er wissen, wer diese Initiativen leitet und welche Art von

Hilfe benötigt wird .

Für ein typisches Großunternehmen ist die Einführung von echten DevOps-Praktiken und Verfahren zur

kontinuierlichen Bereitstellung ein schwieriges und komplexes Unterfangen . Mit dieser Broschüre möchte

Micro Focus Ihnen das Umdenken erleichtern, indem Sie Einblick in unsere umfangreichen Erfahrungen in

einigen der fortschrittlichsten IT-Unternehmen der Welt erhalten . Von unserer strategischen Perspektive aus

können Sie erfahren, was moderne Unternehmen tun müssen, um die Einführung von DevOps reibungslos zu

gestalten, seine Effektivität aufrecht zu erhalten und eine ständige Verbesserung zu gewährleisten .

Beginnen wir also am Anfang.

8

Das Geschäftsproblem

Unternehmen konkurrieren in Märkten, die sich aufgrund der zunehmend technologischen Art von Produkten

und Services schneller verändern als je zuvor . Heutzutage sind selbst die alltäglichsten Produkte digitaler

Art oder werden über digitale Kanäle vermarktet . Die zwei Triebfedern für schnelle Veränderung sind die

Erwartungen digitalaffiner Kunden und das Wettrennen um revolutionäre Innovation, mit der Konkurrenten

überflügelt werden . Der Wettbewerbseffekt wird durch die Globalisierung und die minimalen Kosten des

Einstiegs in einen Markt verstärkt . Mit neuartigen Geschäftspraktiken und globalisierten, digitalbasierten

Lieferketten können neue Mitbewerber in wenigen Wochen und manchmal sogar Tagen Märkte zerrütten

oder zerstören, die über Jahrhunderte hinweg aufgebaut wurden .

Veränderung in Ihrem Unternehmen zu beschleunigen, damit es diese Bedrohungen abwehren und

diese Chancen nutzen kann, bedeutet einen Wechsel zu neuen Paradigmen . Dazu gehören soziales und

mobiles Marketing und der Umstieg auf dynamische Lieferketten, vorübergehend Beschäftigte und kleine,

spezialisierte, unabhängige Zulieferer (deren Existenz möglicherweise morgen selbst bedroht ist) .

Vor allem jedoch wird Ihnen die digitale Transformation Ihrer Softwareentwicklung und Ihres

Bereitstellungsprozesses den Vorsprung geben, den Sie zum Markterfolg benötigen.

Mit der Verbreitung von Web- und mobilen Anwendungen, und jetzt dem Internet der Dinge (IoT), hat sich im

vergangenen Jahrzehnt die Art der Software selbst verändert . Im Apple App Store (im Juni 2008 eröffnet)

gibt es 1,5 Millionen Apps, im Google Play Store (im Dezember 2009 eröffnet) sogar 1,8 Millionen . In

jedem Marktsektor und vertikalen Segment wird heute verstanden, wie wertvoll Apps für Organisationen

sein können . Der Wechsel zu einer auf Apps basierenden Lieferung von Wert an den Kunden hat dazu

geführt, dass Software zunehmend in Komponenten zerlegt wird und ihrer Architektur serviceorientierte

Modelle zugrunde liegen . Viele Legacy-Anwendungen sind bereits überarbeitet und in Bibliotheken von

standardisierten Widgets und Komponenten angelegt . Leider lassen sich die technischen Vorteile einer

Überarbeitung von Anwendungen, die eine schnellere, funktionsbasierte Bereitstellung ermöglichen soll,

nur mit großem Kosten- und Zeitaufwand erzielen . Projekte scheitern häufig, sind oft nur von kurzer Dauer

und liefern selten einen differenzierenden Wert . Sie können Trost aus der Tatsache schöpfen, dass Ihre

Konkurrenten wahrscheinlich vergleichbare Initiativen unternommen haben und die gleichen Erfahrungen

damit machen wie Sie .

Durch die Einführung agiler Praktiken für Anwendungs- und Software-Projektmanagement konnten

Unternehmen immer feinere (inkrementelle) Änderungen an vorhandenen Anwendungen verlangen .

Entwicklungsteams haben die Erwartung gefördert, dass sie in einem inkrementellen, schnellen „Just-in-

Time“-Bereitstellungsstil entwickeln können, wenn Änderungen benötigt werden . Durch diesen Ansatz wurden

Entwicklungskosten gesenkt, die Qualität erhöht und das Geschäftsrisiko reduziert, das jeder an einem

stabilen System vorgenommenen Änderung innewohnt . Das von diesem Ansatz erzeugte Änderungsvolumen

jedoch hat den nachgelagerten Prozess der Freigabe von Software in die Produktion überwältigt . Außerdem

hat dies zu einer Steigerung der komponenten- und anwendungsübergreifenden Abhängigkeit um mehrere

Größenordnungen geführt, dass diese jetzt so komplex ist, dass sie sich unmittelbar und nachteilig auf die

Bereitstellung von vorgeschlagenen Änderungen auswirkt .

Ihr wichtigstes kommerzielles Unterscheidungsmerkmal ist Ihre Fähigkeit, die vom Markt

gewünschten Funktionen schnell und sicher bereitzustellen, nicht die Geschwindigkeit, mit der Sie

die Änderungen am Code vornehmen können.

1

9

Das gemeinsame Ziel: Bewege dich schnell, ohne etwas kaputt zu machen; aber wenn du etwas kaputt gemacht hast, repariere es schnell

Wenn schnelle Entwicklung kein Unterscheidungsmerkmal ist, was ist es dann? Befürworter der

kontinuierlichen Bereitstellung argumentieren, dass der Schlüssel eine schnelle Bereitstellung ist, d . h . die tatsächliche Zustellung der Software in die Produktion, schnell und frei von Fehlern, die einen geschäftlichen

Mehrwert liefert . Von welchem Nutzen ist die neueste und großartigste Funktion in Ihrer Software, wenn sie

sich in einem Qualitätssicherungslabor befindet anstatt auf einem Kundengerät?

Das Hauptziel jeder Branche, ob Engineering, Fertigung oder Software-Bereitstellung, besteht in der

Verkürzung der Markteinführungszeit . Das bedeutet die Bereitstellung fertiger Software für Endbenutzer,

die sie wiederum dazu einsetzen, ihren Kunden neue oder aktualisierte Services zu liefern oder schnelles

Feedback zum Produkt anzubieten . Wer würde nicht lieber schon nach den ersten drei Monaten der neuesten

Innovation Ihrer Produktmanagement-Organisation herausfinden, dass Kundenanforderungen nicht erfüllt

werden, als erst zwölf Monate später? Die Prinzipien und Praktiken von kontinuierlicher Bereitstellung

ermöglichen es Unternehmen, die Ineffizienzen zwischen Geschäft, Entwicklung, Qualitätssicherung und

Operationen anzusprechen, indem Zykluszeiten verkürzt und unwirtschaftliche Praktiken des End-to-End-

Prozesses beseitigt werden . Durch Anwendung von Lean-Prinzipien und -Zyklen2 – wie der von Deming

vorgeschlagenen – haben viele Organisationen entdeckt, dass höhere Lieferungsraten und eine frühzeitige

Identifizierung von Problemen zu Kostensenkung und Qualitätssteigerung führen . Jede Software-Führungskraft möchte Lieferungsraten, Mengen und Genauigkeit erhöhen, ohne dass es zu Qualitätseinbußen oder höheren Kosten kommt.

2 https://www .lean .org/WhatsLean

Bei einer nationalen Apothekenkette…

Die Kernanwendung für Rezeptverarbeitung wurde traditionell einmal im Jahr

aktualisiert. Die Dynamik dieses wettbewerbsintensiven Markts jedoch zwang

das Unternehmen zu einer häufigeren Aktualisierung, um mit den Initiativen

von Konkurrenten Schritt halten zu können. Daher wurde eine DevOps-

Initiative speziell zu dem Zweck unternommen, drei Hauptversionen pro Jahr

möglich zu machen.

https://www.lean.org/WhatsLean

10

Eine Hauptherausforderung bei den erforderlichen organisatorischen Veränderungen liegt darin, wie die

Teams bewertet werden . In der Vergangenheit wurde Ops auf der Grundlage von Service Level Agreements

(SLAs) bewertet . Konkret erfolgte dies anhand von Messungen der Systembetriebszeit, Anzahl von Vorfällen

und Zeit zur Wiederherstellung von Services, aber nicht auf Grundlage der Anzahl der an die Produktion

gelieferten Änderungen . Die Entwicklerteams werden zwar für verspäteten und unvollständigen Code

getadelt, aber nicht an der Qualität oder Produktionsstabilität von Anwendungen gemessen . Praktiken

des IT Service Management (ITSM), die von vielen Unternehmen gefördert und mit wesentlichen Folgen

übernommen wurden, stehen oft in direktem Konflikt mit den agilen Mantras der kontinuierlichen

Bereitstellung funktionstüchtiger Software . Das meinen dazu die „Principles Behind the Agile Manifesto“

von agilemanifesto .org: „Unsere oberste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche

Bereitstellung wertvoller Software zufriedenzustellen .“ Tatsächlich ist dies zwar nicht der Fall, aber ITSM-

Administratoren nehmen ihr bisheriges Ziel einer Verfügbarkeit von 100 Prozent ernst und wissen, dass

Änderungen die Traumnote verderben .

Wie sollen Sie dann mit einem Startup konkurrieren, der Ihren Markt stört, indem er inkrementelle Kapazitäten

in Veröffentlichungszyklen von zwei Wochen anbietet und sofort Feedback vom Kunden erhält?

Beginnen Sie mit kontinuierlicher Bereitstellung .

11

Continuous Delivery: Schnellen, wettbewerbsfähigen Änderungen angepasste Bereitstellung

Die Einführung der kontinuierlichen Bereitstellung (Continuous Delivery, CD) kann als eine Reise betrachtet

werden, aber keine, die man leichtfertig unternimmt . Die organisatorischen Auswirkungen und politischen

Implikationen von CD-Praktiken sind fast so erheblich wie die Vorteile, die sie liefern . Wer dieses Wissen von

Anfang an besitzt, ist in der Lage, angemessene Erwartungen festzulegen und auf ein klar definiertes Ziel

fokussiert zu bleiben .

Jez Humble, ein Technikexperte und Berater im Silicon Valley, wird allgemein der Verdienst zugesprochen, die

Ziele und Prinzipien von CD in seinem 2010 erschienenen Buch Continuous Delivery: Reliable Software

Releases through Build, Test, and Deployment Automation (Humble, Farley 2010) konkretisiert zu haben .

Das Hauptziel der kontinuierlichen Bereitstellung, schreibt Humble, besteht darin, hochwertige, wertvolle

Software auf effiziente, schnelle und zuverlässige Weise bereitzustellen . Dies kann auf die Ziele des im Jahr

2000 veröffentlichten Agile Manifesto zurückgeführt werden, in dem erklärt wurde: „Unsere oberste Priorität

ist es, den Kunden durch frühzeitige und kontinuierliche Bereitstellung wertvoller Software zufriedenzustellen .“

In Unternehmen gibt es drei Arten von Prozessen: dokumentierte Prozesse, undokumentierte Prozesse und

die alltägliche Arbeitspraxis . Viele Unternehmen verlassen sich auf undokumentiertes Wissen sowohl in

App Dev als auch in IT Ops . Schlüsselfiguren fungieren als Helden, weil sich das gesamte Wissen in ihren

Köpfen befindet und sie die einzigen Personen sind, die eine versagende Version retten können . Wenn jede

Anwendung von einem derartigen Helden abhängt, ist ein Freigabefenster üblich, bei dem Dutzende, wenn

nicht Hunderte von Teilnehmern benötigt werden, damit Code erfolgreich die Produktionsphase erreicht .

Es gibt einen effizienteren und praktischeren Weg zur Bereitstellung von Produktionscode .

2

Allianz: DevOps und Ressourceneinsatz

Die Allianz sah sich mit Herausforderungen im Zusammenhang

mit den Ressourcenkosten und der Markteinführungszeit der

Hauptgeschäftsanwendung des Unternehmens konfrontiert. Das AMOS-

Team (Shared Services) rollte für diese Anwendung täglich bis zu drei

Releases aus, die sowohl Oracle-Datenbanken- als auch WebSphere-

Bereitstellungen erforderten. Die Allianz implementierte eine „Einzelklick“-

Bereitstellungslösung, um den Bedarf an teuren technischen Ressourcen

zu beseitigen, die an diesen Bereitstellungen beteiligt waren. Mithilfe von

Deployment Automation konnte die Allianz zwei hochqualifizierte Ressourcen

pro Release umfunktionieren, die Veröffentlichungszeit verkürzen und die

Bereitstellung von geschäftlichen Veränderungen erhöhen.

Klicken Sie hier, um die vollständige Allianz-Fallstudie zu lesen.

https://www.microfocus.com/media/success-story/allianz_uk_ss.pdf

12

Jez Humble nennt die folgenden sieben Grundprinzipien zur Gewährleistung einer effektiven Einführung von

DevOps:

• Erstellen eines wiederholbaren, zuverlässigen Prozesses

• Automatisieren aller möglichen Prozesse

• Versionskontrolle für alles (sogar die Automatisierungsskripte)

• Wenn es wehtut, tu es häufiger

• Qualität integrieren

• „Fertig“ bedeutet freigegeben

• Alle sind für den Bereitstellungsprozess verantwortlich

Wir werden diese Grundsätze genauer untersuchen, um die CD-Herausforderungen anzugehen . (In Kapitel 3

untersuchen wir, wo man bei der Einführung der kontinuierlichen Bereitstellung am besten anfängt . In

Kapitel 4 tauchen wir tiefer in die Automatisierung der Bereitstellungs-Pipeline ein .)

Erstellen eines wiederholbaren, zuverlässigen Prozesses

Wahrscheinlich haben Ihre Entwicklungs-, Qualitätssicherungs- und Bereitstellungsteams das Ziel des

wiederholbaren Prozesses bereits formuliert – jedes Team in seiner eigenen Abteilung . Dies hat zu drei

verschiedenen Prozessen und Mechanismen geführt, um den Code in die richtigen Umgebungen zu bringen .

DevOps-Teams konzentrieren sich auf die Erweiterung des agilen Prozesses von Entwicklung zu Testen und

Bereitstellung . Eine effektive Einführung von kontinuierlicher Bereitstellung sollte in einem Prozesskontinuum

resultieren, das diese Teams vereint und sie zu einem kontinuierlichen agilen Prozess verschmelzen lässt .

Die von Ops und dem Unternehmen benötigten Kontrollen und Konformitätsprinzipien werden beibehalten

(und sofern möglich automatisiert), und etablierte Praktiken und Arbeitsabläufe werden beibehalten, sofern

sie angemessen sind . Alles dreht sich um die Optimierung der Prozesse und um die Beseitigung von

Prozessgrenzen .

So viel wie möglich automatisieren

Code von der Entwicklung über die Testphase und Tests zur Benutzerakzeptanz (UAT) in die Produktionsphase

zu überführen, muss nicht schwierig oder komplex sein . Allerdings ist Irren menschlich, und bei der

Veröffentlichung oder Bereitstellung von Anwendungen für die Produktion trifft das Sprichwort häufiger

zu, als es der Fall sein sollte . Kunden bemerken oft, dass die meisten Produktionsausfälle nicht auf Fehler

bei der Bereitstellung oder Konfiguration, sondern auf eine minderwertige Code- oder Anwendungsqualität

zurückzuführen sind . Ein Release-Engineer, der am späten Freitagabend 200 Schritte in einer

Tabellenkalkulation abarbeiten muss, wird nicht jeden Schritt jedes Mal richtig ausführen . Die meisten Fehler

und Ineffizienzen, die eine Verzögerung von Bereitstellungen verursachen, beruhen auf menschlichen Fehlern .

Humbles Rat, der von Gartner und anderen führenden Analysten bestätigt wird, ist dieser: Auch wenn Sie nichts anderes tun, starten Sie die Automatisierung Ihrer Bereitstellungen. Ob Sie in der Entwicklung oder im Betrieb beginnen, spielt dabei keine Rolle . Automatisieren Sie an einem Ende der Bereitstellungs-Pipeline, und

arbeiten Sie sich dann zum anderen Ende vor . Die Automatisierung vereinfacht und beschleunigt Entwicklung,

Testen und Bereitstellung, während die häufigsten Fehler eliminiert werden .

13

Wenn Projekte der kontinuierlichen Bereitstellung oder DevOps-Transformation in die Praxis umgesetzt

werden, ist die Realität, dass die Automatisierung am häufigsten in der Entwicklung beginnt und

kontinuierliche Integration (CI) implementiert wird . CI ist das Erstellen der Anwendung bei jeder Änderung,

für die ein Entwickler ein Commit im Quellcode-Repository ablegt . In der Regel wird dies mit einem

automatisierten Build- und Unit-Test erreicht . Dies bedeutet, dass Feedback sofort geliefert wird, wenn der

Entwickler den Build beschädigt oder wenn neuer Code die Reihe automatisierter Tests nicht besteht . Auf

diese Weise kann die Reparatur oder Fehlerbehebung sofort stattfinden, bevor sich der fehlerhafte Code

schädlich auf andere Entwickler oder die Testteams auswirkt .

Die sofortige Identifizierung von Problemen und die Ermittlung, wer den Build beschädigt hat, führt zu einer

radikalen Veränderung des Entwicklungsparadigmas . Statt wie früher einmal täglich Code zu erstellen,

und dann Stunden mit dem Versuch zu verbringen, 50 oder mehr Code-Commits aufzuheben, um den

Übeltäter ausfindig zu machen, wissen wir es jetzt sofort – und der betreffende Entwickler ebenfalls . Viele

Organisationen ringen mit der Aufgabe, einen einzigen, allen Teams gemeinsamen Erstellungsprozess zu

schaffen . Erfahrenere Teams wenden etablierte CI-Praktiken an, während andere Teams nicht einmal über einen

gemeinsamen Prozess für das Erstellen verfügen . Durch die Standardisierung der Erstellungsprozesse und die

anschließende Implementierung von CI wird die grundlegende Entwicklungsanforderung für kontinuierliche

Bereitstellung erfüllt . Dies kann als der unerlässliche erste Baustein betrachtet werden, der als Grundlage

für CD-Implementierungen dient . Viele CI-Erstellungstools dehnen ihre Möglichkeiten sogar in Richtung

erweiterter Automatisierung und Pipeline-Management aus . Momentan setzen sich viele Unternehmen mit der

Herausforderung auseinander, wie CD-Komponenten übergreifend über Qualitätssicherung und IT-Operationen

eingeführt werden können . Man hat eine Reihe von technologischen Lösungen mit unterschiedlichem Erfolg

ausprobiert .

Versionskontrolle für alle Artefakte

„Versionskontrolle bietet eine zentrale Informationsquelle für alle Änderungen.

Wenn eine Änderung fehlschlägt, kann dadurch die Ursache des Scheiterns

genau bestimmt werden und ein Rollback auf den letzten intakten Status

problemlos durchgeführt werden, sodass die Wiederherstellung beschleunigt

wird. Außerdem fördert die Versionskontrolle die Zusammenarbeit

zwischen Teams. Die Vorteile der Versionskontrolle sind keineswegs auf

Anwendungscode beschränkt. Tatsächlich zeigt unsere Analyse, dass

Organisationen, die Versionskontrollen sowohl für System- als auch für

Anwendungskonfigurationen nutzen, eine bessere IT-Performance aufweisen.“

State of DevOps Report (Puppet Labs), 2014

14

Versionskontrolle für alles

Entwickler sollten die Commits ihrer Codeänderungen in einem gemeinsamen Repository ablegen, bei der jede

Änderung versioniert wird . Je mehr Entwicklungsteams es in Ihrer Organisation gibt, desto mehr Repositorys

wird es geben . Unkontrollierte Repository-Ausbreitung entwickelt sich momentan zu einem erheblichen

Mehraufwand und Risiko, während große Unternehmen vor der Herausforderung stehen, Kontrollen

einzurichten und die Überwachung und Steuerung des Quellcodes aufrecht zu erhalten . Entwicklungstools,

die früher unter der Steuerung einer zentralen IT-Funktion standen, befinden sich jetzt auf dem Server eines

Entwicklers unter dessen Schreibtisch . Unter dem Deckmantel der Agilität haben Entwicklungsteams die

Kontrolle über ihr Repository übernommen und sich dadurch vom Entwicklungskollektiv und der Sicherheit

der Unternehmens-IT getrennt . Entwicklungs-Führungskräfte haben die Kontrolle über Projekte verloren, es

fehlt ihnen der Einblick in den Status der Aufgaben, und ihr wertvolles geistiges Eigentum wandert frei und

unsicher irgendwo auf dem WAN herum .

Damit einfache Versionskontrolle in ein kontinuierlicheres Build-Modell umgewandelt werden kann,

werden alle durchgeführten Änderungen auf mindestens täglicher Basis auf dem Hauptentwicklungszweig

zusammengeführt und einem gemeinsamen Build unterzogen . Die Ausgabe jenes Builds ist eine ausführbare

Datei, die ebenfalls im Repository versioniert wird . Eine echte DevOps-Einführung erfordert ein Engagement

zur Versionierung aller Artefakte von einem Ende des Lebenszyklus der Anwendung zum anderen, z . B .

Anforderungen, Testskripte, Release-Skripte, UI-Spezifikationen, Prototypen, Build, Baselines und so weiter .

Wenn es wehtut, tu es häufiger

IT-Mitarbeiter sind auch nur Menschen . Sie neigen dazu, vor Prozessschritten zurückzuschrecken, die schwierig

oder fehleranfällig sind, oder wahrscheinlich kritisiert werden . Zur DevOps-Arbeitsmoral gehört es, diese

anspruchsvollen Aufgaben wiederholt auszuführen, bis sie einfacher werden und die „Schmerzen nachlassen“ .

Dieser Ansatz macht eine Änderung der Denkweise unumgänglich und fordert, wie so vieles bei DevOps, eine

Kombination von Zuckerbrot und Peitsche, um die Einführung sicherzustellen .

Qualität integrieren

DevOps verwendet Ideen sowohl von agilen Entwicklungspraktiken als auch von der Lean-

Prozessverbesserung . Diese konzentrieren sich auf die Vermeidung von Fehlern und Verschwendung und

werden gleichermaßen auf Entwicklung und IT-Operationen angewandt . Mit diesen Grundsätzen werden

Prozesse entworfen, die Fehler vorhersagen und vermeiden, bevor sie auftreten . Paar-Programmierung

und kontinuierliche Integration identifizieren Fehler, bevor diese das Entwicklungsteam verlassen . Eine

kontinuierliche Überwachung und Validierung der Prozessschritte hilft bei der Beseitigung von Engpässen und

der Optimierung von Aufgaben . Menschen verhalten sich wie Elektronen im Stromfluss – sie nehmen den Weg

des geringsten Widerstands . Dafür zu sorgen, dass Ihre Prozesse ohne Qualitätseinbuße den kürzesten Weg

unterstützen, ist für eine erfolgreiche Softwarebereitstellung von entscheidender Bedeutung .

„Fertig“ bedeutet freigegeben

Dev und QA sehen ihre Prozesse und Ziele als separat von denen anderer Teams an . DevOps erfordert ein

Zusammenführen dieser Prozesse in den Köpfen von Einzelpersonen, sodass Entwickler ein Gefühl von

Eigentümerschaft am Code behalten, bis IT-Operationen die Freigabe an Endbenutzer abgeschlossen haben .

Ops muss informiert sein, wenn Builds aus Dev hervorgehen, und diese müssen zur sofortigen Freigabe bereit

sein . Was aus einer Entwicklungsperspektive als agiler „Fertig“-Status betrachtet wird – d . h ., die Geschichte

ist abgeschlossen und wird an die nächste Prozessphase übergeben – ist in einem CD/DevOps-Modell

ungeeignet . „Fertig“ bedeutet in diesem Fall „sicher zur Produktion geliefert“ .

15

Alle sind für den Bereitstellungsprozess verantwortlich

Obwohl das Ideal darin besteht, Hierarchien abzuflachen, Abteilungen aufzubrechen und Teams zu

integrieren, ist es nicht immer möglich, die Dev-, QA- und Ops-Abteilungen zu einem integrierten Team

abzuflachen – häufig aus Kompetenzgründen . Entwicklerressourcen, die betriebliche Sachzwänge und

Architekturen verstehen, sind so selten wie betriebliche Ressourcen, die Anwendungsarchitekturen und Code

verstehen . Andererseits führt die Erstellung eines DevOps-Teams von Grund auf nicht zwangsläufig zu einer

erfolgreichen Implementierung . Wir haben gesehen, wie dedizierte DevOps-Teams erstellt und zwischen

Entwicklung und IT-Operationen eingefügt wurden . Dadurch wurde aber bloß eine weitere Abteilung zur

Organisation hinzugefügt, die zusätzliche Probleme verursachte . Die Schaffung des gemeinsamen Ziels, die

Software so schnell wie möglich in die Produktion zu bringen, führt kurzfristig mit größerer Wahrscheinlichkeit

zum Erfolg, während Ressourcenprobleme angegangen werden .

Das einfache DevOps-Mantra „Wenn ich wach bin, bist du wach“ kann die Zusammenarbeit zwischen Teams

auf unkomplizierte Weise erhöhen, obwohl sie nicht als Möglichkeit betrachtet werden sollte, Hauptbeteiligten

mehr Arbeit zuzuweisen . Wenn Entwickler stets verfügbar sind, nimmt die Wahrscheinlichkeit einer

erfolgreichen Bereitstellung zu . Wenn der Entwicklungsprozess vollständig in den Prozess bis zur Freigabe

integriert ist, erhöht sich die Erfolgswahrscheinlichkeit weiter .

Die obigen sieben Prinzipien bieten eine Zusammenfassung der Ziele für die kontinuierliche Bereitstellung .

In den nächsten zwei Kapiteln dieser Broschüre liegt der Schwerpunkt auf Prozess und Tools, um

grundlegendere Fragen anzusprechen:

• Wie wird die in der Entwicklung realisierte Flexibilität auf formelle Qualitätssicherungs-, Informationssicherheits- und IT-Operations-Teams erweitert?

• Wie kann man stets die Produktionsbereitschaft des Codes sicherstellen, damit funktionsbasierte Versionen möglich sind?

• Wie kann man die Qualität von Änderungen in der Bereitstellungs-Pipeline sichtbar machen?

• Wie werden Erkenntnisse aus der Produktionsphase wieder der Entwicklungsphase zugeführt?

Wie lange dauert es, eine Zeile Code zur Produktion zu bringen?

Bei den meisten Organisationen, die keine kontinuierliche Bereitstellung

mit langen Release-Zyklen anwenden, lautet die Antwort wahrscheinlich

„Monate“.

Der Leser dieser Broschüre sollte sich diese Frage überlegen, um den für die

Freigabe von Code erforderlichen Aufwand zu verstehen.

16

Continuous Delivery: Die Herausforderung

Alle Organisationen, die Geschäfts- oder kundenseitige Anwendungen erstellen, profitieren von der

Einführung von Praktiken der kontinuierlichen Bereitstellung . Es gibt aber eine Reihe von Voraussetzungen,

die implementiert werden müssen, um erfolgreich zu sein:

• Verständnis der geschäftlichen Ziele – Die Digitalisierung von Produkten und Services sowie der Kanäle, über die sie vermarktet und verkauft werden, macht es unerlässlich, dass die IT versteht, was für das

Unternehmen wirklich wichtig ist . Was sind die Ziele und Vorgaben des Unternehmens? Wie ist der Plan zur

Erfüllung dieser Ziele? Und wie passen Entwicklung und IT-Operationen in den Kontext der Bereitstellung?

Viele IT-Organisationen beschäftigen qualifizierte Mitarbeiter, deren alleinige Verantwortung darin

besteht, als Mittelsmann zwischen Engineering und Geschäft zu fungieren . Diese Personen arbeiten

mit den Interessenvertretern zusammen, um Feedback und Input von ihnen zu erhalten . Aber warum

soll nur eine begrenzte Teilmenge von Ressourcen an diesem Prozess beteiligt werden? Je kleiner die

Anzahl der beteiligten Personen, desto größer die Wahrscheinlichkeit, dass Vorurteile – bewusst oder

nicht – in die Transformation der geschäftlichen Anforderungen einfließen . Wenn jedoch Mitglieder der

Teams für Anwendungsentwicklung und -sichtung, IT-Operationen, Produktionsunterstützung und Vorfall-

und Problemmanagement in den Prozess einbezogen werden, kann ein wesentlich größerer Grad an

Verständnis und Klarheit der geschäftlichen Anforderungen erreicht werden .

Dies bedeutet nicht, dass die IT ihre gesamte Zeit in Konzept- oder Planungsbesprechungen verbringen

sollte, sondern dass ein besseres Verständnis der geschäftlichen Anforderungen zu einer besseren finalen

Bereitstellung führt . Ein einzelner Product Manager, der „alles weiß, was der Kunde möchte“, wird nicht

zu einem erfolgreichen Produkt führen . Bei größerer Beteiligung kann die IT ein Verständnis der Vision,

Richtung und Ziele des Unternehmens erwerben und eine Kultur implementieren, die eine schnelle und

erfolgreiche Bereitstellung von hochwertigen, zielgerechten Anwendungen unterstützt . Dieser integrierte

Ansatz führt häufig zu vollständigeren und erfolgreicheren Implementierungen, weil längerfristige Ziele bei

Design, Definition und Umsetzung berücksichtigt werden .

• Unterstützung aus der Führungsebene – Wie jede andere Initiative hat DevOps Erfolg mit einem Fürsprecher in der Unternehmensleitung, der Befugnisse zu Änderungen der geschäftlichen Abläufe

besitzt . Dieser Förderer muss nicht der CIO sein, aber mit dem aktuellen Medienrummel um DevOps

mag der CIO für diese Initiative empfänglicher sein . Geschäftlicher Druck allein kann bedeuten, dass

der Förderer aus der Unternehmensleitung bereit ist, eine Initiative ins Leben zu rufen, bei der Releases

beschleunigt und häufigere Anwendungsbereitstellungen ermöglicht werden . Und es ist möglich, dass der

Begriff „Continuous Delivery“ oder „DevOps“ zur Beschreibung verwendet wird .

• Kontinuierliche Integration – CI ist im Wesentlichen eine Entwicklungspraktik, aber weil sie auch ein bestimmtes Maß an automatisiertem Testen von Software umfasst (zumindest Einheitentest),

gerät sie zunehmend in den Bereich der Qualitätssicherung . Gewöhnlich werden bei agilen Ansätzen

Entwicklungs- und Testressourcen integriert . Daher dürfen Teams die Einbindung des Einheitentests in

den Entwicklungszyklus nicht als neues Konzept betrachten . Indem CI-Modelle die Lieferung von Build-

Artefakten weiter nach rechts – in Richtung der IT-Operationsteams – zu verlagern suchen, machen sich

die Auswirkungen auf Qualitätssicherungsteams stärker bemerkbar . Befürworter von CD stimmen meist

darin überein, dass es wenig Sinn hat, DevOps in einer Organisation zu fördern, die CI noch nicht eingeführt

hat und mindestens diesen Einsatz zur Prozessautomatisierung gezeigt hat .

3

17

• Änderungsmanagement – Viele Unternehmen sind bereit, ITSM/ITIL-Prozesse für die Organisierung von IT-Bereitstellung und Problemverfolgung umzusetzen . Zwar bedeutet die Einführung von ITIL eine

Implementierung von formellen Release Management- oder Service-Übergangsprozessen, doch ist eine

effektive Bereitstellung von Software auf sorgfältig definierte betriebliche Änderungsmanagement-

Praktiken angewiesen, wozu ITIL eine gute Anleitung bietet . ITIL-Praktiken, und DevOps-Praktiken

generell, übersehen oft den Wert der Verfolgung von Änderungen auf Entwicklungsebene im Vergleich zu

Änderungen auf Betriebsebene . Wenn sowohl ein gut definierter, ITIL-konformer Betriebsprozess als auch

ein gut definierter Entwicklungsprozess auf agiler Basis vorhanden ist, zwischen denen wenig bis keine

Interaktion stattfindet, führt dies sofort zu einer Trennung von Dev und Ops .

Auf Unternehmensebene gibt es häufig mehrere Tools . Bedenken Sie aber, dass erstklassige Tools

für Betriebsänderungen und das für Entwicklungsänderungen bevorzugte Tool möglicherweise zwei

vollständig isolierte Produkte mit wenig bis keiner Prozessüberlappung sind . Eine einfache Möglichkeit,

die Mauern zwischen Dev und Ops zu überwinden, besteht in der Entwicklung eines gemeinsamen

Änderungsmanagement-Prozesses für die gesamte Bereitstellungs-Pipeline . Dabei ist zu beachten, dass

es sich beim Änderungsmanagement um eine Risikobegrenzungsstrategie handelt . Viele CD-Befürworter

betrachten einen formellen Änderungsmanagement-Prozess in einer erfolgreichen Bereitstellungs-Pipeline

als unnötig . Folgende Frage muss für Ihr Unternehmen gestellt werden: Reicht es aus, Bereitstellungen

schnell in Ihre Umgebung zu bringen, oder wünschen Sie auch die Möglichkeit zur Validierung und

Erklärung, welche spezifischen Dev- und Ops-Änderungen als Teil der Bereitstellung geliefert wurden?

• Automatisierung – Die Automatisierung von Code- und Konfigurationsbereitstellungen mit nur einem Satz von umgebungsübergreifenden Bereitstellungsprozessen unter Verwendung von Parametrisierung hilft

sicherzustellen, dass umgebungsspezifische Einschränkungen und Anforderungen erfüllt werden . Setzen

Sie Code nicht einfach auf verschiedene Weise ein, weil Sie von der Testphase zur Produktionsphase

wechseln . Wiederholbarkeit und Konsistenz sind der Schlüssel zu einer erfolgreichen, präzisen und

schnellen Bereitstellung . Stellen Sie sicher, dass alle Artefakte vom gleichen Speicherort oder Artefakt-

Repository bereitgestellt werden .

Eine Bereitstellung auf gleiche Weise über alle Umgebungen hinweg ist sowohl zeit- als auch

kosteneffizient . Die Anwendung des gleichen Prozesses gewährleistet konsistenteres Testen, und

umgebungsspezifische Probleme lassen sich einfacher bestimmen . Je automatisierter dieser Prozess

ist, desto wiederholbarer und zuverlässiger ist er . Dies schlägt sich in schnelleren Bereitstellungen,

reduzierten Ausfallzeiten und größerem Vertrauen seitens des Unternehmens nieder, dass Änderungen auf

zuverlässige Weise bereitgestellt werden .

Eine Möglichkeit, die Mauern zwischen Dev und Ops zu überwinden, ist die

Entwicklung eines gemeinsamen Änderungsmanagement-Prozesses

für die gesamte Bereitstellungs-Pipeline. Dazu gehören integrierte Prozesse

sowohl für Entwicklungs- als auch für Betriebsänderungen.

18

Andere Tools und Prozesse können Bedingungen schaffen, die für CD günstig sind, die aber nicht als

Voraussetzungen betrachtet werden müssen . DevOps überlappt zum Beispiel Application Lifecycle

Management (ALM) und Enterprise Service Management (ESM), die Kette von Disziplinen, mit denen

Organisationen Anwendungen „von der Wiege bis zur Bahre“ verwalten: Anforderungsmanagement,

Softwarearchitektur, Entwicklung, Testen, Softwarewartung, Änderungsmanagement, Projektmanagement,

Release-Management sowie Servicemanagement . Bei einigen Organisationen gehört Product Lifecycle

Management (PLM) ebenfalls dazu . ALM kann verschiedene Grade der Prozesssteuerung aufweisen,

und jede Organisation verfügt über einen Anwendungslebenszyklus (ALM), auch wenn es dort unter

einen anderen Namen bekannt ist . Man kann Continuous Delivery und wiederum DevOps, als eine

Weiterentwicklung der Idee von ALM (oder der von Forrester 2010 aufgestellten Definition von ALM 2 .0+3)

betrachten . Es gibt keine bestimmte Implementierung von ALM-Tools oder -Produkten, die vorhanden sein

muss, bevor eine DevOps-Transformationsstrategie erfolgreich eingeführt werden kann .

Kontinuierliche Bereitstellung ist ein überzeugender erster Schritt für praktisch jede Art von Unternehmen,

obwohl Befürworter zu der Ansicht neigen, CD sei für bestimmte Arten von Anwendungen besser

geeignet als für andere . Tatsächlich wird bei der lautstarken Forderung nach Einführung von DevOps und

CD auf Unternehmensebene oft übersehen, dass bestimmte Anwendungen in einer Weise ausgelegt

und implementiert sind, bei der CD unpraktisch ist . Angesichts des Volumens und der Geschwindigkeit

von Änderungen in der Entwicklung von webbasierten oder mobilen Anwendungen ist die kontinuierliche

Bereitstellung bei diesen Arten von Anwendungen höchst angemessen . Höchstwahrscheinlich hat

jedes Unternehmen, das die Entwicklung von Java- oder .NET-Anwendungen vornimmt, bereits die

kontinuierliche Integration oder gemeinsame Build-Prozesse implementiert . Ältere „Legacy“-Technologien

sind möglicherweise weniger geeignete Ziele für CD . Trotzdem versuchen viele Unternehmen, ihre

Leistungsfähigkeit zu beweisen, indem sie die schwierigste Herausforderung zuerst bewältigen . Dieser

Ansatz führt häufig zu Fehlern oder schlechten Einführungsraten und einer geringen Investitionsrentabilität .

Gartner spricht von „Bimodaler IT“4 – agil und kontinuierlich für manche Anwendungen, stabil und

sequenziell für andere . In Wirklichkeit ist diese Praktik „multi-modale IT“, weil Anwendungen verschiedene

Geschwindigkeiten von Bereitstellung und Änderung haben . Abhängig von einer Reihe von Faktoren, z . B .

organisatorischer Reife und Fähigkeiten des Anwendungsentwicklungs-Teams, begegnen sich Agile und

Risikoscheue in verschiedenen Phasen . Anwendungen, die architektonisch als ungeeignet für CD gelten,

können als Kandidaten für die Implementierung zu einem späteren Zeitpunkt identifiziert werden .

Ein Portfolio von Unternehmensanwendungen kann zu einem ausschlaggebenden Faktor für die DevOps-

Bereitschaft einer Organisation werden . Eine wichtige Frage zu einer geschäftskritischen Anwendung ist, ob

sie diese neue Welt des schnellen Wandels unterstützen kann . Wenn nicht, könnte dies ein Signal dafür sein,

dass es Zeit ist, die betreffende Anwendung zu überarbeiten oder durch eine Anwendung zu ersetzen, deren

Architektur für CD geeignet ist, auch wenn dies ein kostspieliges und zeitaufwendiges Unterfangen sein

kann . Unternehmen können die Leistungsfähigkeit von Anwendungen über eine realistische Portfolioanalyse

bestimmen, und diese mit einer detaillierten Geschäftsanalyse des Werts der Anwendung überlagern .

Hoher geschäftlicher Wert, geringe Komplexität und Produkte mit guter Architektur bilden den natürlichen

Ausgangspunkt für jede CD-Strategie eines Unternehmens . Zuerst müssen die richtigen Anwendungen

ausgewählt und Zugkraft gewonnen werden . Zu einem späteren Zeitpunkt kann das Projekt auf den Rest des

Unternehmens ausgedehnt werden . Auf diese Weise sorgt Erfolg für Erfolg .

3 Carey Schwaber et al . Forrester 2008-2010 https://www .forrester .com/report/ALM+20_Getting+Closer+But+Not+There+Yet/-/E-RES46166

4 http://www .gartner .com/it-glossary/bimodal

http://www.gartner.com/it-glossary/bimodal

19

Continuous Delivery und der Bereitstellungsprozess

Die Bereitstellungs-Pipeline stellt die wichtigste Funktion des CD-Prozesses dar . Wenn ein Entwickler-

Commit stattfindet, oder wie man früher sagte, wenn ein Entwickler eine Codeänderung eincheckt, bindet

ein CI-Prozess die Änderung in den Rest der im Repository gespeicherten Code-Basis ein, und die Software

wird aufgebaut und einheitengetestet . Ein erfolgreicher Build und Einheitentest führen zur Instanziierung der

Bereitstellungs-Pipeline, wobei es sich einfach um eine modellierte Darstellung der logischen Umgebungen

handelt, in der die neu bereitgestellten Artefakte bereitgestellt werden sollten . Dieser Prozess wird immer

dann wiederholt, wenn ein Entwickler eine Codeänderung übergibt .

Wenn der neue Build den Einheitentest abgeschlossen hat, stellt die Bereitstellungs-Pipeline den Code

automatisch in der nächsten Umgebung bereit, wo er in der Regel einigen Integrationstests unterzogen

wird . Sobald eine Bereitstellungs-Pipeline initiiert worden ist, gewinnt automatisiertes Testen an Bedeutung .

Wenn die Erstellung des Builds fehlschlägt, werden die Entwickler sofort benachrichtigt und können den

Fehlerbehebungsprozess in Gang setzen . Wenn eine Codeänderung bereitgestellt wird, und Probleme im

Build identifiziert werden, kann die zum Beseitigen der Probleme benötigte Zeit deutlich verkürzt werden .

Statt darüber zu streiten, wer den Build beschädigte und welche Änderungen das Problem verursachten,

können Entwickler dies sofort ermitteln (das letzte Commit beschädigte den Build) . Um sicherzustellen,

dass hochwertiger Code bereitgestellt wird, durchläuft jeder Build die Pipeline und verschiedene Ebenen

von automatisierten Tests, einschließlich Performance-, Kapazitäts- und Sicherheitsdurchdringungstests .

Schließlich kann der Build einem manuellen Prüfprozess, gewöhnlich einer Form von UAT, unterzogen

werden, der zur geschäftlichen Freigabe führt . In diesem Fall kann die Bereitstellung als eine technische

Entscheidung zur Freigabe einer Funktion in der Software betrachtet werden, wohingegen ein Release mit

einer geschäftlichen Entscheidung verbunden ist, die Funktion oder Funktionen in die Produktionsphase

einzuführen, oder sie dem Endbenutzer zur Verfügung zu stellen .

Eine interessante Frage, die nur von der Organisation beantwortet werden kann, die versucht, eine DevOps-

Strategie zu implementieren, ist, ob die DevOps-Initiative der IT-Organisation eine ideale Struktur und

einen idealen Prozess auferlegen sollte, oder ob sie sich an vorhandenen Prozessen orientieren sollte . In

der Realität spielt dies meist keine Rolle, solange die Voraussetzungen für die Einführung erfüllt sind . Die

für die erfolgreiche Einführung eines DevOps-Transformationsprogramms erforderlichen Prozess- und

Tooländerungen bedeuten, dass es kein Patentrezept gibt . Eine vernünftige Antwort lautet: was immer in Ihrer

Unternehmenskultur am besten funktionieren könnte .

Wie ändert sich Ihr Anwendungsfreigabe-Prozess, wenn Sie kontinuierliche Bereitstellung implementiert und

eine Bereitstellungs-Pipeline aufgebaut haben?

20

Einem häufigen Missverständnis zufolge erfordert CD den Abbau der isolierten Organisation von IT-

Abteilungen sowie eine Änderung der Reporting-Struktur, um sie aufnahmefähig für einen kontinuierlichen

Prozess zu machen . In Wirklichkeit ist die Erwartung, dass eine organisatorische Änderung sofort auftritt,

unrealistisch . Eine solche Änderung ist keine unabdingbare Voraussetzung für die Durchführung einer

DevOps-Transformation oder die Implementierung von CD . Der Erfolg des Transformationsprojekts hängt von

der Fähigkeit und Bereitschaft der Entwicklungs-, Test- und Bereitstellungsteams zur Zusammenarbeit an

einem gemeinsamen optimierten Prozess ab .

In der Entwicklung wurden möglicherweise seit mehr als einem Jahrzehnt agile Methoden angewandt, und

ausgereifte und gut laufende Prozesse können vorhanden sein . Agilität kann auch bei IT-Operationen erreicht

werden, doch ist dies auf Unternehmensebene nicht typisch, insbesondere nicht in US-Unternehmen .

Scrum, eine gängige Herangehensweise an agile Bereitstellung, gestattet Entwicklern die Teilnahme an

Analyse, Design und Erstellen einer Anwendung . Der Vorteil liegt in schnellen Feedback-Zyklen, die oft die

kontinuierliche Integration, Feedback-Schleifen und automatisiertes Testen umfassen . Dies erlaubt es dem

Entwicklungsteam, am Ende eines jeden „Sprints“ oder engen Bereitstellungszeitraums eine funktionierende

oder bereitstellbare Software zu produzieren . Leider laufen Testen und Bereitstellung in vielen Unternehmen

in Wasserfallmanier ab, da diese Phasen nicht zur Entwicklung gehören und die Qualitätssicherungs- und

Release Management-Teams den laufenden Datenfluss steuern möchten . Bis Verbesserungen in Qualität

und Geschwindigkeit nachgewiesen werden können, lassen sich vorhandene Abteilungen und Barrieren nur

schwer beseitigen .

In einem auf kontinuierlicher Bereitstellung basierenden Modell besteht das Ziel, dass jeder Sprint

Analyse › Design › Build ›Test › Bereitstellung beinhaltet . Zuerst wurde in der Fertigung und später in der

Softwareentwicklung nachgewiesen, dass eine Bereitstellung in kleineren Batches mit kontinuierlichem Fluss

zu höherer Qualität und schnellerer Bereitstellung führt . Ohne Hindernisse oder Mauern wird der Fluss von

Daten und Anwendungen reibungsloser .

Analyse Design Build Test Bereits- tellung

21

Nach Abschluss des Builds liegt das Problem im Lebenszyklus immer bei der Übergabe . Die primären Lücken

entstehen zwischen Build und Bereitstellung . Dieser Zeitpunkt ist in der Regel durch die Übergabe an eine

spezielle Testorganisation gekennzeichnet, die für Verwaltung und Bereitstellung der Testumgebungen

verantwortlich ist, und dann in diesen die Bereitstellung vornimmt . Während dieser Übergaben geht jedes

Team davon aus, dass seine Verantwortlichkeiten umgesetzt wurden, und verliert die allgemeinen Ziele des

Release aus den Augen .

In einem herkömmlichen Modell wurde die Übergabe von der Entwicklung zum Betrieb von Projekt- oder

Freigabemanagern gehandhabt, aber die beiden Organisationen blieben getrennt . In einem CD-Modell

funktioniert diese Trennung von Aufgabengebiet und Prozess nicht . Entwickler müssen sich mehr an

betrieblichen Bedenken orientieren, während sich IT-Operationsteams zumindest an nachgelagerten

Aspekten der Entwicklung beteiligen müssen . Das bedeutet nicht, dass IT-Operationsteams plötzlich über

ein Verständnis komplexer Anwendungsarchitekturen verfügen müssen . Sie sollten aber zumindest die

Abhängigkeiten und Ausrichtung von Anwendungen verstehen .

An allen Punkten auf dem Weg zur Produktion gibt es Herausforderungen, die bewältigt werden müssen .

Beispielsweise muss das Qualitätssicherungsteam möglicherweise einen Änderungsauftrag oder ein

Änderungsticket mit der IT-Operationsgruppe protokollieren, bevor die neue Version einer Anwendung

bereitgestellt werden kann . Dieses Ticket gibt lediglich an, dass die Anwendung zu einem bestimmten

Zeitpunkt in Umgebung X bereitgestellt werden muss . Bei dieser Umgebung kann es sich um einen

einzelnen Server oder mehrere Server mit vielen Abhängigkeiten handeln . In manchen Organisationen

wird dieser Prozess für jede Umgebung wiederholt . Dazu wird nicht das gleiche Ticket verwendet, sondern

jedes Mal ein neues Ticket erstellt . Die richtigen Anwendungsversionen und Leistungen, einschließlich des

Bereitstellungsauftrags, werden hinzugefügt .

Wenn Unternehmen Code erneut in verschiedenen Umgebungen mit einem unterschiedlichen

Anweisungssatz und potenziell anderen Binärdateien bereitstellen, kann man sich dann wundern, dass

Produktionsbereitstellungen die Ursache von bis zu 85 Prozent5 aller Produktionsprobleme sind? Im

Gegensatz dazu ermöglicht der Einsatz eines CD-Modells, bei dem der Prozess der Bereitstellung in

anderen Umgebungen automatisiert ist, hoffentlich auf Self-Service-Ebene, dem Qualitätssicherungsteam

zu sagen: „Ich möchte, dass diese bestimmte Anwendungsversion zu diesem bestimmten Zeitpunkt in dieser

bestimmten Umgebung bereitgestellt wird .“ Da diese Bereitstellung auf eine vollständig automatisierte Weise

erfolgt, wird ein Ressourcen-Engpass beseitigt und ein potenzieller Fehler und Risikobereich durch einen

interaktionsfreien Prozessablauf ersetzt .

5 Gartner: How IT Operations Can Set Up an Effective, Centralized Release Management Process . Veröffentlicht: 3 . Juni 2013; Analysten: George Spafford, Ronni J . Colville .

22

Eine wirklich DevOps-zentrische Organisation befasst sich auch mit der Bereitstellung der Infrastruktur für

Entwicklung, der Infrastruktur für Tests sowie der Infrastruktur für Bereitstellung, während die Integration

dieser Infrastrukturen in die Anwendungsbereitstellungs- und Testprozesse ebenfalls berücksichtigt

wird . Der neue Prozessablauf und das neue Interaktionsmodell wiederum treiben neue Tool- und

Prozessverbesserungen voran . Letztendlich sieht die Bereitstellungs-Pipeline eher wie in Abbildung 1

gezeigt aus .

Wie die Grafik zeigt, können Automatisierungs-Tools die Rollen von Mitarbeitern im Bereitstellungsprozess auf

vielerlei Weise beeinflussen .

Bei den Tools zur Implementierung der kontinuierlichen Integration sollte es sich um den ersten Teil der

Bereitstellungs-Pipeline handeln . Der Betrieb mag kein direktes Interesse am CI-Erstellungsprozess haben,

aber da dieser Prozess Tests und nachfolgende Bereitstellungen auslöst, ist das Ergebnis der CI-Erstellung

von direktem Interesse für den letztendlichen Bereitstellungsprozess .

IT-Operationsteams sind mehr als vertraut mit dem Konzept der Ausführung eines Skripts in einer bestimmten

Umgebung . Jedoch könnte das Konzept der Modellierung eines gesamten Bereitstellungsprozesses, der sich

durch eine Automatisierung des Prozesses auszeichnet, neu für sie sein .

Abbildung 1: DevOps-Bereitstellungs-Pipeline

Einheitentests werden in der Regel als Teil der

kontinuierlichen Integration automatisiert, aber

Organisationen quälen sich noch mit der Automatisierung von

Integration und Akzeptanztests. Manuelles Testen kann nicht

automatisiert werden.

23

Auswirkungen auf den Testprozess

In vielen Organisationen entwickelt sich die Qualitätssicherungsfunktion vom traditionellen

wasserfallbasierten, übergabebezogenen Ansatz zu einem stärker integrierten, voll umfassenden Prozess .

Während Entwicklungsteams für die Erhöhung des Grades von Einheitentests durch Implementierung

von CI die Verantwortung übernommen haben, mussten sich Qualitätssicherungsteams an eine erheblich

schnellere Lieferungsrate und Verfügbarkeit von neu erstellten oder geänderten Funktionen anpassen . Der

von Entwicklungsteams einheitengetestete Code wird anschließend – hoffentlich mithilfe von automatisierten

Prozessen – in einer Integrationstest-Umgebung bereitgestellt . Dort wird er unter Einsatz einer beliebigen

Anzahl von automatisierten Testtools getestet . Vor seiner endgültigen Freigabe wird er der Produktion

bereitgestellt und in der UAT-Umgebung validiert . Allerdings führt ein Mangel an Transparenz in diesem End-

to-End-Prozess zu Prozessineffizienzen und zu fehlender Echtzeit-Rückverfolgbarkeit und -Status-Accounting .

In vielen Fällen ist die Qualitätssicherungsorganisation dafür verantwortlich, dass ein Zusammenhang

zwischen diesen verschiedenen Umgebungen hergestellt wird . Beispiel: die physische

Einheitentestumgebung, die Eigentum der Entwicklung ist und von dieser bereitgestellt wird;

die Integrationstest- und UAT-Umgebungen im Besitz des Qualitätssicherungsteams; und die

Produktionsumgebung im Besitz von IT-Operationen . Jedes Team kann seinen eigenen Prozess für die

Bereitstellung dieser Umgebungen haben, die in einer idealen Welt im Hinblick auf Einrichtung und

Konfiguration identisch sind . Um den Code vom Einheitentest zum Integrationstest zu bringen, kann

die Entwicklung dem Qualitätssicherungsteam einen Änderungsantrag zuweisen und warten, bis die

Qualitätssicherung die Umgebung als verfügbar markiert oder sogar eine Infrastruktur bereitstellt . Die

nachfolgende Übergabe von UAT zur Produktion kann ähnlich sein, aber der Operationsprozess ist ein eigener

und kann sich vom Prozess nach der Qualitätssicherung unterscheiden .

Die Implementierung von DevOps- oder CD-Praktiken erfordert eine weit engere Orientierung der

Qualitätssicherungsorganisation sowohl an der Entwicklungsorganisation, um ein gründliches und

vollständiges Verständnis dessen sicherzustellen, was aus der Pipeline erwartet wird, als auch am IT-

Operationsteam, um sicherzustellen, dass die endgültige Übergabe an die Produktion auch wirklich erfolgreich

ist . Testteams benötigen ein wesentlich besseres Verständnis vieler Automatisierungstechnologien .

Diese reichen von Automatisierungstools für Anwendungsfreigabe, die die Dateien auf den verwalteten

Umgebungen bereitstellen, über automatisierte Testtools, die die Anwendung validieren, bis hin zu

Infrastruktur-Bereitstellungstools, die zum Erstellen neuer Umgebungen und physischer Infrastruktur

eingesetzt werden, wo diese benötigt werden . Die Anzahl von Umgebungen, die zur Unterstützung der

funktionsbasierten CD benötigt werden, macht auch das Konzept von Container und containerbasierten

Images attraktiv, wobei sich der Durchsatz der Testkapazität entsprechend den Entwicklungssteigerungen

erhöht .

24

Automatisierung der Bereitstellungs-Pipeline

Wie wir in Kapitel 1 gesehen haben, plädieren Befürworter der kontinuierlichen Bereitstellung für die

Automatisierung von möglichst vielen Prozessen – von einem Ende des Freigabeprozesses zum anderen . Eine

Automatisierung, die effektive Entwicklungsprozesse unterstützt (z . B . Peer-Review, statische Analyse und

Einheitentests), gewährleistet eine höhere Entwicklungsqualität am Anfang der Bereitstellungs-Pipeline .

Dafür gibt es eine einfache Begründung: Die „Bits“ sollten nicht von Menschen bewegt oder bereitgestellt

werden . Bei der Bereitstellung von Anwendungen arbeiten Systeme besser und konsistenter als Menschen .

Eines der ersten Dinge, die Sie sich auf dem Weg zu kontinuierlicher Bereitstellung anschauen sollten, ist die

Automatisierung von manuellen Aufgaben und Übergaben . Mit Automatisierung können Sie schnelle Erfolge

erzielen . Dieser Ansatz kann auf eine Weise durchgeführt werden, bei der die einfachsten oder wertvollsten

Anwendungen zuerst anvisiert werden . Danach kann der Vorgang schnell und ohne größere organisatorische

Änderungen wiederholt werden .

4

Abbildung 2: Toolketten-Integration mit der Bereitstellungs-Automatisierungstopologie von Micro Focus

Integrationstest Tests zur Benut-zerakzeptanzVorproduktion/

StagingProduktion

Repository- Bereitstellung

Konfigura-tionsinforma-

tionen

Umgebungs- Provisioning

Testautomati-sierungen

Bereitstellungsautomatisierung

Build und CIAnwen-

dungsüber-wachung

BereitstellungSecurity Gate-

keeper

25

Durch gemeinsame Technologielösungen können die Mitglieder von Entwicklungs- und IT-Operationsteams

zusammenarbeiten, um die Änderungsgeschwindigkeit im ganzen System zu erhöhen, Best Practices

durchzusetzen, Konformität zu gewährleisten und sicherzustellen, dass Releases wiederholbar, zuverlässig

und vorhersagbar sind . Wie bereits erwähnt, je früher Entwicklungsfehler entdeckt und identifiziert werden,

desto wahrscheinlicher kann das Team Überarbeitungen beseitigen, die Qualität verbessern und die

Freigabebereitschaft des Codes sicherstellen .

Ergänzende aufgabenspezifische Tools werden in Verbindung mit leistungsfähigen Source-, Build- und

Implementierungs-Tools zur Automatisierung der Bereitstellungs-Pipeline eingesetzt . Diese sogenannte

DevOps-Toolkette kann viele Tools verschiedener Anbieter integrieren und unterschiedliche Integrationen

innerhalb des Freigabe- und Bereitstellungsprozesses verwenden . Zu den Haupttools in der DevOp-Toolkette

gehören:

• Quellcodeverwaltungs-Tools – Idealerweise mit integrierten Funktionen für Änderungsmanagement, Arbeitselementverwaltung, Fehlernachverfolgung oder Anforderungsbearbeitung ausgestattet, gestatten

Quellcodeverwaltungs-Tools die Nachverfolgung und Genehmigung mehrerer funktionsbasierter

Bereitstellungen .

Diese Tools lassen sich vollständig in die geeigneten Build-/CI-Tools integrieren .

• Tools für kontinuierliche Integration (CI) – Zur Überwachung von Änderungen an der Code-Basis und Verwaltung des automatischen Re-Building- und Einheitentests vorgesehen, benachrichtigen CI-Tools den

Entwickler automatisch, falls der Build oder Einheitentest fehlschlägt . CI-Tools können Funktionen für die

Integration von Artefakt-Verwaltung enthalten .

• Tools für Continuous Delivery (CD) – Indem sie einen automatisierten Bereitstellungsmechanismus bieten, der in der Regel ohne menschlichen Eingriff ausgelöst wird, um Code am nächsten Bereich

in der Bereitstellungs-Pipeline bereitzustellen, geben CD-Tools den Interessengruppen an allen

Berührungspunkten im Freigabeprozess Feedback .

• Tools für Automatisierung der Bereitstellungs-Pipeline – Pipeline-Automatisierungstools, die entwickelt wurden, um digitale Artefakte in einer vordefinierten oder dynamischen Reihenfolge durch

Entwicklung, Test und Produktion zu bewegen, sollten es Benutzern ermöglichen, den Inhalt von

Umgebungen jederzeit nachzuverfolgen .

• Release Management-Tools – Diese Tools sind darauf ausgelegt, ein Release über den End-to-End-Prozess hinweg zu definieren, zu verwalten und zu verfolgen . Dies umfasst die Verwaltung der physischen

Release-Artefakte, Beziehungen zwischen Anwendungen, Services, Plattformen oder sogar Komponenten

sowie die in einem Release enthaltenen Änderungen, und zwar sowohl aus einer geschäftlichen als

auch aus einer Entwicklungsperspektive . Weitere wichtige Funktionen beinhalten Links zu Testfällen,

Aktivitätssequenzierung, Genehmigungen und Meilensteinverwaltung .

• Überwachungstools – In der Regel ist die Bereitstellungs-Toolkette mit Anwendungen zum Überwachen der Anwendungsleistung integriert, die die Auswirkungen von neu bereitgestelltem Code verfolgen, mit

denen IT-Operationsteams Abweichungen erkennen können, sobald sie auftreten . Diese Tools umfassen

häufig eine erweiterte Analysefunktionalität und Performance-Dashboards .

26

Der Kernprozess: Continuous Integration und Continuous Deployment

Der CI-Prozess unterliegt in der Regel der Entwicklungsorganisation . Jede Änderung an einer Software-

Code-Basis wird im Wesentlichen in Echtzeit getestet . Wenn ein Entwickler das Commit einer Codeänderung

ausführt, löst dies einen automatischen Prozess zum Testen der betreffenden Software aus, sodass dem

Unternehmen am Ende dieses Prozesses ein bereitstellbares Element vorliegt . Weniger Mängel in dem zur

Bereitstellung freigegebenen Code sind das angestrebte Ergebnis .

Der Build-Prozess wird durch das Developer-Commit ausgelöst . Ein Entwickler, der einen Build-Fehler

verursacht, wird sofort darüber benachrichtigt (durch das Build-Tool), dass er den Build beschädigt hat . In

diesem Szenario liegt es in der Verantwortung des Entwicklers, der den Build beschädigt hat, die Fehler zu

korrigieren und den Build wieder in Gang zu bringen . Wenn mehr als ein Build-Fehler auftritt, können ein

Eskalationsverfahren und zusätzliche Benachrichtigungen generiert werden, um den Rest des Teams davon

zu informieren, dass der Build instabil ist .

Als Teil des CI-Prozesses wird eine Form des automatischen Testens auf Ausführung im Hintergrund

eingerichtet und ausgelöst, während Entwickler ihren Code mit Commits erstellen . Diese automatisierte

Testsuite validiert den kompilierten Code kontinuierlich und meldet fehlgeschlagene Tests dem Entwickler . Die

tatsächliche Validierungsstufe kann von Organisation zu Organisation variieren, aber sie umfasst in der Regel

eine Form von API- oder funktionalen Schnittstellentests (häufig lassen sich diese Testsuites am einfachsten

automatisieren) . Der erweiterte Testprozess kann beinhalten, dass Entwickler die automatisierte Testsuite für

Ausführung nach einem erfolgreichen Build oder planmäßig am Ende des Tages als Teil eines nächtlichen

Build-Prozesses initiieren . Diese automatisierte Testsuite kann bei der Ermittlung hilfreich sein, ob alle

Komponenten, an denen mehrere Entwickler gearbeitet haben, in eine Anwendung integriert werden können .

Einfacher ausgedrückt ist dies lediglich eine automatisierte Form des Integrationstests .

Abbildung 3: Das Release-Repository stellt sicher, dass bereitgestellte Komponenten identisch mit denen sind, die in Vorproduktionsumgebungen getestet wurden .

27

Die automatisierte Testsuite besteht aus vielen Tausenden gegen die Code-Basis gestarteten Testfällen . In

einer idealen Welt würde die Code-Basis eine Einheitentestabdeckung von 100 Prozent erzielen .

Den Grundbausteinen der Code-Basis Ihrer Anwendung (wie RESTful-Services und API-Aufrufe) sollten

für die Automatisierung priorisiert und danach erweiterte Logik- und Geschäftsfunktionen folgen . Wenn

ein Test fehlschlägt, wird der Entwickler automatisch benachrichtigt und ist für die Korrektur oder das

Rückgängigmachen der problematischen Änderung verantwortlich .

Sobald der automatisierte Einheitentest erfolgreich abgeschlossen wurde, sollte der Code automatisch

der nächsten Testumgebung bereitgestellt werden, wo zusätzliche Tests ausgeführt werden können .

Möglicherweise wird eine prozentual akzeptable Fehlerrate als angemessen betrachtet; diese Entscheidung

liegt beim Development Lead, da diese Person die letztendliche Verantwortung für die Code-Basis und den

kompilierten Code trägt, der in der nächsten Umgebung bereitgestellt wird . Nach erfolgreichem Abschluss

der automatisierten Tests in der nächsten Umgebung kann es zu einer automatisierten Hochstufung

zu weiteren Testumgebungen kommen . Der Prozess wird einfach wiederholt, wobei automatisierte

Anwendungsbereitstellungen und unterschiedliche Arten von Tests in jeder Umgebung durchgeführt

werden . Das Ziel besteht darin, einen wiederholbaren, automatisierten Prozess zu haben, bei dem

menschliche Fehler verringert werden und das Risiko einer manuellen Interaktion ausgeschaltet

wird.

Continuous Deployment kann dazu eingesetzt werden, Anwendungen bis hin zur Produktion bereitzustellen .

IT-Operationsteams sind generell einer Automatisierung der Produktionsbereitstellungen abgeneigt, außer

wenn sie an der Erstellung und früheren Ausführung solcher Bereitstellungen beteiligt waren . Meistens

bedeutet dies, dass das Continuous Deployment endet, sobald der Code einen Vorproduktions-Staging-

Bereich erreicht . Danach werden herkömmliche manuelle Bereitstellungen oder vorhandene Skripts für

den letzten Schritt zur Produktion verwendet . Obwohl dieser Ansatz verständlich und eine vorsichtige

Herangehensweise bei Produktionsumgebungen lobenswert ist, bleibt das grundlegende Problem bestehen:

unterschiedliche Tools und Skripte, die Änderungen an Ihren wichtigsten Produktionsumgebungen

vornehmen, aber weder in Tests verwendet noch selbst getestet wurden, verursachen signifikante Ausfälle

gefolgt von organisatorischer Verlegenheit .

Viele IT-Führungskräfte finden es schwierig, zwischen Continuous Deployment und Continuous Delivery

zu unterscheiden . Um den Unterschied zu verstehen, müssen wir uns Gedanken über die herkömmliche

Bereitstellungs-Pipeline machen . Bei traditionellen Entwicklungs- und Bereitstellungsansätzen gibt es an

jedem Punkt auf dem Weg zur Produktion Kontrollen oder Gates, die eine zustimmende Aktion erforderlich

machen, bevor fortgefahren werden kann . Denken Sie an die Übergabe- und Validierungsschritte eines

herkömmlichen Softwareentwicklungs-Lebenszyklus, die Genehmigungen für Eintreten und Verlassen jeder

Umgebung beinhalten können .

28

Wenn ein CD-Ansatz implementiert wird, sollte die Anwendung immer „bereitstellungsbereit“ sein und könnte

theoretisch jederzeit an die Produktion geliefert werden . Häufig sind organisatorische Regeln oder Praktiken

vorhanden, die dies verhindern, z . B . Bedenken hinsichtlich Aufgabentrennung oder nicht autorisierte

Produktionsänderungen . Bei der kontinuierlichen Bereitstellung sind selten automatisierte Bereitstellungs-

und Testprozesse für Pipeline-Umgebungen auf einer unteren Ebene vorhanden, z . B . Entwicklungs- und

Integrationstest, dürfen jedoch nicht in höheren Test-, Staging- und Produktionsumgebungen laufen . Das

finale Ziel ist, immer Code zu liefern, der in Produktion gehen könnte, selbst wenn das nicht der Fall sein wird .

Wenn ein Continuous Deployment-Ansatz implementiert wird, ist Code immer produktionsbereit . Solange die

Bereitstellungs- und Testautomatisierungsprozesse erfolgreich sind, wird die Codebereitstellung automatisch

durch alle Umgebungen und schließlich in der Produktion fortgesetzt, ohne dass menschliches Eingreifen

oder eine Aufsicht erforderlich sind . Potenziell ermöglicht dies eine vollständig automatisierte Bereitstellung

von Entwickler-Commit über Build, Bereitstellung und Test bis zur Produktion .

Mithilfe funktionsbasierter Entwicklung (Funktions-Flags) kann CI sicherstellen, dass die Code-Basis jederzeit

freigebbar ist, und dass die Lieferung von Code auf einer geschäftlichen Entscheidung statt auf einem

betrieblichen Sachzwang beruhen kann .

Schauen wir uns jetzt die verschiedenen Tool-Klassen für die Bereitstellungs-Pipeline genauer an .

Tools für die Automatisierung der Bereitstellungs-Pipeline

Diese Tools automatisieren die Bereitstellung und Validierung von Code über seinen gesamten Lebenszyklus .

Da sie die Bereitstellung von Änderungen automatisieren, kann potenziell eine größere Menge von Releases

an die Produktion bereitgestellt werden . Die schnelle Bereitstellung und Validierung von bereitgestelltem

Code durch den Einsatz von Automatisierung kann zur Verringerung von Fehlerraten beitragen und

vorhersagbare und zuverlässige Releases erleichtern .

Tools für die Automatisierung der Bereitstellungs-Pipeline wirken sich auf verschiedene Weise auf die

Bereitstellung von Anwendungen aus . Für die bereitgestellte Anwendung bieten diese Tools:

• Zugriff auf das Quellcode-Repository und das Repository für ausführbaren Code, auf die Konfigurationsdateien und die bereitzustellenden Datenelemente

• Einen definierten Prozess für die Bereitstellung einer Anwendung, der leicht geändert werden kann und gemeinsame Elemente für Standard-Aufgaben verwendet (z . B . Starten und Stoppen eines Webservers

oder Sichern einer Datenbank)

• Die Möglichkeit zur Definition einer gesteuerten Abfolge von Bereitstellungs-Zielumgebungen

• Unterstützung von „kompensierenden Transaktionen“ für vollständig automatisiertes Rollback

• Die Möglichkeit zum Aufrufen einer Kette von Ereignissen, die potenziell den gesamten Anwendungs-„Stapel“ bereitstellen, einschließlich Infrastruktur, Anwendung und Konfiguration

29

Ein Mangel an geeigneten Testumgebungen, die auf Konflikte in der Verwendung von Umgebungen

abgestimmt sind, kann Bereitstellungen verzögern und Release-Kosten erhöhen . Echte kontinuierliche

Bereitstellung erfordert die Verfügbarkeit von Test- und Vorproduktionsumgebungen . Es hat keinen Sinn, eine

kompilierte und bereitstellungsbereite Anwendung zu haben, wenn die Umgebung, in der sie bereitgestellt

werden soll, noch von der vorherigen Bereitstellung verwendet wird . Die Nutzung von Infrastruktur-

Bereitstellungstools, die eine spontane Erstellung neuer Umgebungen gestatten, stellt eine großartige Weise

zur Umgehung solcher Einschränkungen dar . Durch die Erstellung neuer physischer, virtueller, Cloud- oder

Container-Umgebungen als Teil des Bereitstellungs- und Pipeline-Prozesses können Organisationen die

Bereitstellungs-Zykluszeiten erheblich reduzieren .

Zusätzliche Transparenz sowohl für die aktuelle als auch für die vorgeschlagene Nutzung von Umgebungen

kann mithilfe einer Kalenderansicht gewonnen werden, die außerdem ein zentraler Ort für einen einheitlichen

Testmanagement-Zeitplan sein kann . Transparenz dabei zu erhalten, wer und was momentan einen Satz von

Umgebungen verwendet oder planmäßig verwenden soll, ermöglicht einen Einblick, den viele Unternehmen

nur mit großen Schwierigkeiten erreichen . Die Zeitplanansicht zeigt auch alle geplanten Bereitstellungen, alle

geplanten Wartungszeiträume und die verfügbaren Release-Fenster für jede Umgebung .

Für Zielumgebungen bieten Bereitstellungs-Automatisierungstools:

• Zugang zu und Transparenz von Test- und Produktionsbereitstellungs-Umgebungen

• Die Möglichkeit zum Erstellen von neuen physischen, virtuellen, cloud- oder containerbasierten Umgebungen nach Bedarf

• Eine Methode für die physische Verteilung der Anwendung an die Zielumgebung und zum Aufrufen der zugehörigen Testsuites

Für den Bereitstellungsingenieur bieten Automatisierungstools:

• Einen einfachen, vom CI-Tool gesteuerten CD-Service

• Die Möglichkeit zur Durchführung von Bereitstellungen mit einem Klick, entweder auf Anforderungs- oder auf Zeitplanbasis

• Echtzeitüberwachung des Fortschritts von Bereitstellung und automatisiertem Test mit der Möglichkeit zur Reaktion auf Eingriffsanforderungen

• Ein Dashboard mit allen historischen Daten, früheren Bereitstellungszeiten, Trends, Mustern und Versionsinformationen über aktuell bereitgestellte Anwendungen und Komponenten

30

Die Bereitstellungsautomatisierung hat nachweislich zu einer Reduzierung der Bereitstellungs-

Ausführungszeiten um mehr als 90 Prozent geführt . Fehlerraten, Nachbearbeitungsaufwand und

fehlgeschlagene Bereitstellungen wurden um bis zu 90 Prozent reduziert . Mithilfe der Erfahrung, die Release-

Engineers in der Nutzung dieser Produkte gewinnen, können sie zusätzliche Anwendungsbereitstellungen

(durch die Wiederverwendung vorhandener Prozesse) in viel kürzerer Zeit automatisieren, als für die

Erstellung anwendungsspezifischer Bereitstellungsskripts erforderlich ist .

Ein effektives Bereitstellungs-Automatisierungstool kann in CI, Provisioning, Bereitstellung und

automatisierten Tests integriert werden, wodurch Sie die Möglichkeit zur Planung von Bereitstellungen und

Automatisierung von Ad-Hoc-Bereitstellungen in jeder Umgebung haben .

Während ein organisationsübergreifender gemeinsamer Satz von Tools wünschenswert sein kann, sind die

Entwicklungs-, Qualitätssicherungs- und IT-Operationsteams oft an bereits vorhandene Tools gebunden, die

nicht einfach oder schnell ersetzt werden können . In diesem Fall ist es wichtig, die Flexibilität zu besitzen,

diese Tools zu einer kohärenten Toolkette zusammenzufügen . Mit öffentlichen APIs oder, schlimmstenfalls,

Befehlszeilenschnittstellen können die Produkten kommunizieren . In einem solchen Fall wird ein zentraler

Punkt für den Einblick in den gesamten Pipeline-Prozess benötigt .

Abbildung 4: Micro Focus DevOps-Toolkettenintegration

Entwicklung Build Bereitstellung Test Release

31

Als Teil des Freigabeprozesses besteht einer der wichtigsten Integrationsbereiche in der Sicherstellung, dass

das Release Management-Tool in das Änderungsmanagement-System integriert werden kann . Dadurch

erhalten verschiedene Mitglieder der Organisation einen Einblick sowohl in den Änderungs- als auch in den

Freigabeprozess . In vielen Organisationen sind spezifische Unternehmens-Änderungsmanagement-Tools

vorhanden, z . B . ServiceNow oder BMC Remedy . Diese Tools bieten zwar eine hervorragende Prozess- und

Genehmigungsverwaltung auf hoher Ebene, aber ihr Mangel an Integration in Artefakte oder entwicklungs-

oder testorientierten Tools (agile Planungstools, Artefakt-Repositorys oder Build-Tools) bedeutet, dass

eine breite Kluft zwischen formellen Änderungs- und Freigabeprozessen existiert . Das ideale Szenario ist

verständlicherweise die Möglichkeit zu einer lückenlosen Nachverfolgbarkeit von der Änderungsanforderung

bis zum bereitstellbaren Artefakt . Aktualisierungen, die in einem der beiden (oder beiden) Systeme(n)

auftreten, müssen im anderen System gespiegelt werden . Die Lösung muss außerdem Statusübergänge

zwischen den Änderungs- und Freigabeprozessen (oder umgekehrt) unterstützen . Zur Unterstützung dieser

echten Integration von Änderungsmanagement und Release-Management bietet ein Tool, das entweder

sich selbst oder andere Tools und Prozesse orchestrieren kann, die auf dem Zustand des Änderungs- oder

Freigabeprozesses basieren, einen deutlichen Vorteil .

Eine integrierte Plattform für Continuous Delivery

Deployment Automation6 (DA) ist eine Plattform, die die gesamte Bereitstellungs-Pipeline unterstützt .

Der Bereitstellungsprozess erstreckt sich über mehrere Umgebungen und lässt sich als Teil einer echten

DevOps-Toolkette nahtlos in andere Produkte integrieren . Kritische Tool-Integrationen, z . B . jene zwischen

Entwicklungstools (Softwarekonfigurations-Managementtools, Build-Server/CI-Server), Bereitstellungstools,

Bereitstellungsautomatisierungs- und manuellen oder automatisierten Testtools, sind sofort einsatzbereit . Die

erweiterbare Plug-In-Architektur ermöglicht es Unternehmen, diese Prozesse aufeinander abzustimmen und

in den verschiedenen Tools zu integrieren .

6- https://www .microfocus .com/products/deployment-automation/

https://www.microfocus.com/products/deployment-automation/

32

In einem Beispielfall legt ein Entwickler als Reaktion auf eine gültige Änderungsanforderung ein Code-

Commit im Quellcode-Repository ab . Das CI-Tool wird automatisch aufgerufen und das System erzeugt einen

neuen Build . Die Automatisierung in Dimensions CM, dem marktführenden Application Lifecycle Management

(ALM) von Micro Focus, gewährleistet, dass alle im Build enthaltenen Änderungen sowohl Peer-Review als

auch statische Analyse bestanden haben und erfolgreich einheitengetestet wurden . Wenn der Build-Prozess

erfolgreich ist, wird das Artefakt in das gesicherte Artefakt-Repository von Micro Focus hochgeladen . SDA

stellt dann automatisch die neue Version der Komponente oder Anwendung an die erste Umgebung bereit,

die als Teil der Bereitstellungs-Pipeline definiert ist .

Die Bereitstellungsautomatisierungs-Technologie kann vor der Bereitstellung jede benötigte Infrastruktur

erstellen und konfigurieren und bei Bedarf auch die Anwendung konfigurieren . SDA ruft das

Testautomatisierungs-Tool auf, das automatisierte Tests ausführt und protokolliert, ob die Testsuite bestanden

hat oder fehlgeschlagen ist . Wenn die Testsuite fehlschlägt, setzt das System die Anwendung automatisch

auf die letzte erfolgreich bereitgestellte Version zurück, und meldet dem Entwickler und dem Test Lead, dass

die Anwendung die automatisierten Tests nicht bestanden hat . Wenn die Anwendungs-Testsuite erfolgreich

ausgeführt wird, stellt SDA die Anwendung automatisch für die nächste Umgebung in der Pipeline bereit .

Als Teil des Bereitstellungsprozesses muss die Anwendung möglicherweise konfiguriert und auf einem

anderen Anwendungsserver (z . B . WebSphere) bereitgestellt werden . Ein einfacher Prozess dafür wäre, den

Anwendungsserver zu stoppen, die aktualisierte Anwendungsversion bereitzustellen, den Anwendungsserver

dann erneut zu starten, vorhandene Dateien zu sichern, .war-Dateien umzubenennen usw . In bestimmten

Situationen müssen Sie möglicherweise vor der Bereitstellung der Anwendung zuerst die Umgebung

bereitstellen . SDA kann die gesamte Abfolge automatisch durchführen .

Außerhalb des Anwendungs-Pipeline- und Bereitstellungsprozesses wird SDA nahtlos in Release Control7

integriert . RC bietet ein Integrations-Framework mit vollem Funktionsumfang, das in Änderungsmanagement-

Ticketsystemen (z . B . ServiceNow oder Remedy) integriert ist . Die erfolgreiche Bereitstellung kann eine

Aktualisierung des Änderungsmanagement-Tickets auslösen, sodass alle Personen, die nicht direkt am

Freigabeprozess beteiligt, aber eng am Änderungsprozess orientiert sind (z . B . Geschäftsbenutzer) in Echtzeit

Einblick in den Fortschritt der Änderung und des

der praktische leitfaden für enterprise devops und ...€¦ · devops wird von organisationen...

Documents