One-Click Deployment

Transkript

1 One-Click Deployment Eine Continuous Delivery-Strategie Ein Whitepaper der avato consulting ag

2 Seite 2/23 Gegenstand Dieses Dokument beschreibt eine Continuous Delivery-Strategie mittels eines One-click Deployments. Betrachtet werden Anforderungen, technologische Konzepte, Architekturen, Migrationsstrategien sowie Erfolgsfaktoren bei der Einführung.. Control Table Contact Person: Classification Uwe Bloch Gregor Bister White Paper One-Click Deployment Functional Applicability: Last Revision Date: Version: 1.0 Change History Version Date Revision Description Revision Details, Authors 0.1 Initial Draft Uwe Bloch 1.0 Final Version Uwe Bloch Gregor Bister

3 Seite 3/23 Inhalt 1 Continuous Delivery-Strategie Von Continuous Development bis Continuous Delivery Modell des Continuous Delivery Continuous Software Integration & Delivery Lifecycle Typische Herausforderungen Mögliches Lösungsszenario Workflows & Komponenten Workflows Release Management Software Delivery Packaging Deployment Komponenten Workflow Management Repository Konfigurationsdatenbank (CMDB) Lösungsansatz Prinzip der Dimensionierung Anwendungsszenarien Packaging Anforderungen Technische Anforderungen Betriebliche Anforderungen Known Standards & Tools Tools zu Standards Ein Installation Package für alle Umgebungen? Mögliche Features & Herausforderungen Erfolgsfaktoren bei der Einführung Integrationsstrategie und -support Shared Service Platform Onboarding Flexibilität der Services Kostenverrechnung Fazit/Ausblick Links & Literatur

4 Seite 4/23 1 Continuous Delivery-Strategie In einer Zeit, in der im IT-Bereich zunehmend Kosten reduziert werden müssen, ist eine effektive Continuous Delivery Strategie unerlässlich. Oft werden die Kostentreiber in der Betrachtung vernachlässigt, der Business-Case für die Einführung einer übergreifenden Lösung nicht vollständig überdacht. Was ist aber bei der Einführung einer Continuous Delivery Lösung zu beachten, was sollte zum Einsatzspektrum gehören? Wie werden die schnelle Bereitstellung von Umgebungen, kurze Deploymentzyklen und reduzierte Build- und Deployment-Aufwände erreicht? Wie kann eine solche Lösung vollständige Kostentransparenz (Managed Service) schaffen, die sogar bis zu einer preislichen Ausdifferenzierung bis auf Einzelschrittebene, z.b. für ein einzelnes Deployment, Transparenz schafft? Zudem wollen wir beleuchten, wie eine solche Lösung zentral gesteuert wird, welche Workflows und Komponenten benötigt werden, welche technischen und betrieblichen Anforderungen bedient werden müssen, welche Standards und Tools dazu hilfreich sind sowie Erfolgsfaktoren bei der Umsetzung hervorheben.

5 Seite 5/ Von Continuous Development bis Continuous Delivery Continuous Delivery ist ein Oberbegriff für die Verbesserung eines Software Lieferprozesses über diverse Umgebungsstufen bis in die Produktion. Es wird mittels einer Sammlung von Prozessen, Techniken und Werkzeugen der agilen Softwareentwicklung umgesetzt. Das Ziel ist die möglichst schnelle, zuverlässige, fehlerfreie, wiederholbare und automatisierte Softwareintegration und -lieferung in Entwicklungs-, Test- und Produktionsumgebungen, um mit geringem Risiko und ohne manuellen Aufwand Software in die Produktivumgebung oder zum Kunden auszurollen. Continuous Delivery ist demnach eine Kombination von Continuous Development, Continuous Integration und Continuous Deployment. Continuous Delivery Anpassbarkeit & Agilität Continuous Development Continuous Integration Continuous Deployment Strategischer Einfluss 1.2 Continuous Delivery-Modell Eine Software muss auf dem Weg der Veröffentlichung, auch deployment pipeline genannt, einige Validierungen durchlaufen und erfolgreich bestehen. Dabei wird jede Änderung am Programmcode in einer Versionsverwaltung eingecheckt sowie von einer beliebigen Build Engine kompiliert und paketiert. Oberstes Gebot ist hier, dass auch frühe Codestände versioniert werden und zu jeder Zeit aus der Versionsverwaltung lieferbar sein müssen. Nun werden möglichst automatisiert Tests (Code- und Strukturchecks) gefahren. Bei positivem Ergebnis wird eine Software als produktionstauglich gekennzeichnet und kann auch in die Produktion promotet werden. Somit ist es theoretisch möglich, eine Software über die deployment pipeline mittels der genannten Validierungsstufen automatisch in die Produktion zu überführen. Die gängige Praxis ist allerdings, dass die Vor-Produktionsstufen automatisch und die Produktion selbst manuell deployed oder das Deployment manuell gestartet wird.

6 Seite 6/23 Continuous Integration beschreibt hingegen eine Praxis aus der Software-Entwicklung, bei der eine Software auch bei minimalen Änderungen permanent automatisiert gebaut wird. Zusätzlich werden häufig automatisierte Tests und Softwaremetriken mit dem Ziel erstellt, dem Entwickler so schnell wie möglich auf Integrations- und Softwarefehler hinzuweisen. Continuous Integration ist ein bewährtes Mittel, schon in der laufenden Entwicklung die Qualität erheblich zu steigern. Es ist somit eine Voraussetzung, um das Konzept der Continuous Delivery erfolgreich in der Praxis zu etablieren. Continuous Deployment bezeichnet die Möglichkeit, neue Releases frequentiert und automatisiert nach vorheriger Freigabe in die Entwicklungs-, Test-, Integrations- und Produktionsumgebung zu überführen. 1.3 Continuous Software Integration & Delivery Lifecycle Continuous Software Integration & Delivery beschreibt also den fortlaufenden toolgestützten Integrations- und Lieferprozess in alle Zielumgebungen (Entwicklung, Test sowie Produktion) von der Codeübergabe durch den Softwarelieferanten bzw. der Entwicklung (Softwarelieferung) bis zur Produktivsetzung. Dies umfasst die Schritte Software-Delivery, Packaging, Pre-Deployment-Check, Deployment und Post-Deployment-Check. 1.4 Typische Herausforderungen Wer kennt die täglichen Herausforderungen nicht? Releases kommen selten in der gewünschten Qualität und in der gewünschten Zeit auf eine Umgebung. Es existiert eine Vielzahl unterschiedlicher Projekte mit diversen Prozess- und Tool-Varianten. Es beginnt meist mit differierenden Anlieferungsprozessen und erstreckt sich über fehlende Revisionssicherheit, Konfigurationsprobleme und eingeschränkte Testmöglichkeiten. Hinzu kommen hohe Aufwände und eine große Fehleranfälligkeit durch individuelle und in Teilen manuelle Verfahren. Die Deployment-Laufzeiten sind lang und die Komplexität des Systems führt zu einer geringen Anzahl von Deployments. Nur durch umfangreiches technologisches Know-how, genaue Kenntnis der Umgebungen (meist an Kopfmonopole gebunden) und eingesetzten Technologien ist eine erfolgreiche Integration zu gewährleisten. Typisch sind im Operations die Fehleranfälligkeit durch nicht standardisierte Übergabeverfahren, manuelles Nacharbeiten und individuelle Softwarelieferungen je Umgebung.

7 Seite 7/ Mögliches Lösungsszenario Aber wie sieht ein mögliches Lösungsszenario für Java-basierte Applikationen aus? Zentrale Elemente sind die Standardisierung der Softwarelieferungen, Konfigurationen, Paketierungen und Deployment-Verfahren. Erst einheitliche Softwarelieferungen inklusive Konfigurationen in einen zentralen Eingangskanal bieten fehlerresistente, revisionssichere und schnelle Integrationen. Darauf aufbauend lässt sich die Integration (inklusive Build und Deployment) weitestgehend automatisieren. Auch die Installation in beliebige Umgebungen kann durch geeignete Verfahren automatisiert und ohne aufwändige manuelle Nacharbeiten auf sämtlichen Plattformen dargestellt werden. Idealerweise werden die zuvor erwähnten Prozesse mittels eines zentralen Workflowmanagement-Tools gesteuert. 2 Workflows & Komponenten Das Handwerkszeug für eine erfolgreiche One-click deployment -Lösung sind aufeinander abgestimmte Workflows, die mit den effektivsten Komponenten ausgeführt werden. Bei der nachfolgenden Betrachtung wird der Software-Entwicklungsprozess nicht veranschaulicht, sondern dessen Input im Workflow Software Delivery integriert. 2.1 Workflows Ein zentrales Workflow Management Tool bietet die notwendigen Übersichten/Dashboards zu den Prozessen und ihren Ergebnissen. Der übergreifende Workflow ist das Release Management, das die Sub-Workflows Software Delivery, Packaging und Deployment enthält. Ein Beispiel für einen möglichen automatisierten Workflow bietet die nachfolgende Grafik.

8 Seite 8/ Release Management Der Release Manager zeichnet sich für eine Reihe von Aufgaben im Software Lifecycle verantwortlich. Von der Release-Planung über die Entscheidung, wann welche Releases zum Einsatz kommen sowie über die Risikoanalyse, das Qualitätsmanagement, die Release Erstellung und abschließende Dokumentation hat der Release Manager immer den Überblick zu behalten. Der Vorgang der Release-Erstellung wird in drei Teil-Workflows, der Software Delivery, dem Erstellen eines Installation Packages und dem Deployment auf die Zielumgebung, unterteilt. Diese werden nachfolgend beschrieben.

9 Seite 9/ Software Delivery Die Software wird nach Anforderung von einem externen Lieferanten oder der internen Entwicklung in Form eines Archives in das Repository angeliefert. Das Installation Package wird meist in einem Arbeitsgang, nach einem vorher definierten Standard, gebaut und abgelegt. Ein wichtiger Bestandteil der Lieferung ist das Konfigurationsset der Applikation zur individuellen Parametrisierung beim späteren Deployment. Dies kann in Form von Files oder idealerweise direkt in einer Datenbank erfolgen. Nach Eingang der Lieferung wird automatisch eine Prüfung auf Inhalte und Struktur durchgeführt. Dieser Schritt stellt die automatische Weiterverarbeitung sicher. Enthält die Lieferung nicht die gewünschten Inhalte bzw. entspricht sie nicht der benötigten Struktur, wird die Lieferung nicht für den nächsten Arbeitsschritt freigegeben und zurück an den Lieferanten geleitet Packaging Nach erfolgreicher Software Delivery sind alle notwendigen Bestandteile für eine automatische Paketierung vorhanden. Das Ergebnis des Packagings sollte ein Paket sein, das auf allen Ziel-Umgebungen lauffähig ist. Das wird erreicht, indem das Paket neben der eigentlichen Anwendungssoftware und der Konfigurationen (Applikation und Umgebung) auch die Paketierungskonfiguration und die Installationslogik enthält. Konsequenterweise müssen für alle gewünschten Zielumgebungen Konfigurationen und Installationslogiken eingebracht werden. Alle erstellten Pakete werden aus Revisionsgründen im zentralen Repository abgelegt.

10 Seite 10/ Deployment Hat eine erfolgreiche Software Delivery zu einem funktionsfähigen Paket geführt, kann es auf die Zielumgebung deployed werden. Voraussetzung ist eine nach definierten Standards aufgesetzte Umgebung, damit das Installation Package auf erwartete Strukturen trifft. Das Deployment sollte neben der eigentlichen Installation der Software auch vorher überprüfen, ob die Umgebung bereit ist. Eine Überprüfung der Filesysteme, Datenbanken, Middleware-Komponenten etc. bietet sich hier an. Auch nach einem Deployment ist es sinnvoll, die eingangs getesteten Komponenten erneut zu überprüfen. Ein technischer oder sogar funktionaler Antest der installierten Applikation ist ein arbeitserleichternder Schritt. Selbst ein automatisierter Regressionstest im Anschluss an das Deployment ist denkbar. So lässt sich beispielsweise bei Hotfixes die vorhandene Software-Qualität schnell und vollständig überprüfen.

11 Seite 11/ Komponenten Eine vollständige Continuous Delivery-Lösung setzt, neben den zuvor angesprochenen Workflows, auch eine Reihe von aufeinander abgestimmten und verknüpften Komponenten voraus Workflow Management Welchem Zweck dient ein zentrales Workflow Management Tool? Wie weit kann eine solche Lösung reichen? Das Workflow Management Tool stellt die zentrale Verbindung und Steuerung aller Komponenten dar. Es bildet die notwendigen Workflows ab, bietet Dashboards und Verwaltungsmöglichkeiten von der Software Delivery bis hin zu Umgebungszuständen. Intelligente Lösungen steuern die gesamte Prozesskette über das Workflow Management Tool, indem zu jeder Komponente eine Schnittstelle existiert. Diese Schnittstellen ermöglichen es dem Anwender alle notwendigen Arbeitsschritte aus dem Tool heraus zu managen. Jeder Workflow erhält Details, z.b. über erfolgreiche Software Deliveries, vorhandene Installation Packages samt ihren Inhalten sowie durchgeführte Deployments und Umgebungszustände Repository Sie haben auch schon häufiger ein bestimmtes Installation Package oder eine Software Delivery gesucht? Ein zentrales Repository, welches Eingangs- und Ausgangskanal miteinander kombiniert, ist eine enorme Arbeitserleichterung im Alltag eines Release- und/oder Configuration Managers. Versionsstände inklusive Dokumentation sowie diverser Metainformationen werden zentral und revisionssicher abgelegt. Keine Suche mehr auf lokalen Filesystemen oder Servern. Die modernen Tools verfügen über Schnittstellen, die sich einfach automatisiert für Ablage und Abholung bedienen lassen. Auch webbasierte Zugriffs- und Verwaltungsoberflächen gehören mittlerweile zu den gewohnten Standards.

12 Seite 12/ Konfigurationsdatenbank (CMDB) Sie haben schon große Softwareentwicklungsprojekte durchgeführt? Die Parametrisierung war auch bei Ihnen ein Schlüsselthema? Im Rahmen der Entwicklung einer Software machen sich die wenigsten Gedanken darüber, wie die Software möglichst fehlerfrei und parametrisierbar in die entsprechenden Zielumgebungen gelangt. Die Herausforderung der Parametrisierung tritt meist erst beim Deployment in die erste Testumgebung zutage. Wer kennt als Release Manager nicht das Problem, dass die notwendigen Parameter für die Applikation, Umgebung und Schnittstellen zusammengesucht werden müssen und sich niemand dafür verantwortlich fühlen möchte. Nun folgt die Frage, wie man einfach und möglichst variabel Parameter für verschiedenste Umgebungen, Applikationskonfigurationen und Laufzeitzeitänderungen strukturiert aufbereitet. Anschließend gilt es, die Parameter während des Deployments an den gewünschten Stellen in der Software und der Umgebung zu platzieren. Jeder, der sich dieser Aufgabe schon stellen durfte, hat diverse Mechanismen getestet. Der Ansatz, je Umgebung und für die Applikation getrennt Parameterfiles anzulegen, ist der wohl am meisten verbreitete. Nicht selten wird für jede Umgebung ein eigenes deploybares Paket erzeugt. Eine andere Möglichkeit ist, alle Konfigurationsparameter in einer einzigen Datei zu versammeln. So existiert eine zentrale Stelle, die allerdings auch entsprechend sensibel behandelt werden muss. Wenn viele Mitarbeiter die gleiche, große Datei bearbeiten, gehen schnell Übersichtlichkeit und Versionierung verloren. Immer frequentierter legen Anwendungen ihre Parameter innerhalb der Applikationsdatenbank ab und werden somit beim Deployment über Updates der einzelnen Werte konfiguriert. Die Werte haben meist ihren Ursprung in SQL-Skripten. Welchen Weg Sie auch wählen, Sie haben immer die Herausforderung, alle notwendigen Key-/Value-Paare aktuell zu halten und zum gewünschten Zeitpunkt bereitzustellen. In den typischen Enterprise-Umgebungen sind oft mehrere Software Releases parallel im Einsatz, die ebenfalls eine professionelle Versionierung der Konfigurationen bedingen Lösungsansatz Um die zuvor beschriebenen Herausforderungen für viele Applikationen beherrschbar zu machen, sollte eine Konfigurationsdatenbank konzipiert werden. Die Lösung sollte neben den genannten auch noch folgenden nichtfunktionalen Anforderungen genügen: Zentrale Datenbank mit Web Frontend Paralleles Arbeiten und dezentrales Pflegen der Konfigurationsdaten Verursachergerechte Verteilung der Pflegeaufwände und Verantwortung für Wertbereiche Import-/Exportfunktionalität gesamter Konfigurationsbereiche Versionierung der Softwarekonfigurationsstände Revisionssicherheit Historisierung und Protokollierung aller Änderungen Rollenkonzept/Rechtesystem Last Minute Überschreibungsmöglichkeit beim Deployment mit lokaler xml-datei Auslesen der Konfigurationen beim Deployment in Realtime

13 Seite 13/ Prinzip der Dimensionierung Neben den nichtfunktionalen Anforderungen gibt es noch die zusätzliche Herausforderung, die Parameter möglichst intelligent in der Datenbank abzulegen. Ein zentrales Ziel muss sein, Redundanzen von Parametern zu vermeiden, ohne Funktionalitätseinbußen hinzunehmen. Dazu werden die Parameter (Key-/Value-Paare) in einer CMDB wissensbasiert modelliert und hierarchisch abgelegt. Eine solche Hierarchie wird im Folgenden als Dimension bezeichnet. Dimension 1: Was Applikation 1 Applikation Dimension 2: Wo Test 1 Test Test 2 P 1 Produktion P Anwendungsszenarien Die zentrale Speicherung und Pflege der Applikations- und Umgebungskonfigurationen eröffnet eine Menge weiterer Anwendungsszenarien, die das tägliche Arbeiten eines Release Managers, Entwicklers, Deployers oder Umgebungsverantwortlichen zum Teil erheblich erleichtern können: Einfaches und schnelles Kopieren von ganzen Konfigurationsständen, z.b. wenn ein neues Software Release erfasst werden soll. Änderungen von Konfigurationssätzen über die gewählten Dimensionen (Applikationen, Umgebungen) hinweg sind ebenfalls mit wenigen Handgriffen zuverlässig durchzuführen. Zielgerichtete Fehlersuche mittels Vergleich von zwei oder mehreren Konfigurationsständen. Vergleich von vollständigen Umgebungsständen. Exporte ganzer Konfigurationen zum Build-Zeitpunkt zur direkten Einbindung in ein Software-Paket oder zur Ablage in ein Repository. Bereitstellung der aktuellsten Konfigurationen oder gezielter Konfigurationsstände zum Deployment-Zeitpunkt. Änderung der Applikations- oder Umgebungskonfiguration zur Laufzeit.

14 Seite 14/23 Grundsätzlich können n-dimensionen abgebildet werden. Weitere Möglichkeit wären z.b. Konfigurationsdateien oder die Aufnahme von Metadaten zu Lieferant, Projekt etc.. Wie werden die Werte in der Datenbank abgelegt? Ein Parameterwert ist immer genau einer Hierarchiestufe pro Dimension zugeordnet (Koordinaten) -z.b. einer Applikationsversion oder einer Maschine. Durch den hierarchischen Aufbau ergibt sich eine Vererbungsreihenfolge, die einer redundanten Parametererfassung entgegenwirkt. Somit kann in der Regel eine Reduzierung von ca. 50% der Gesamtparameter erzielt werden. Bedingt durch die Möglichkeit, bei Bedarf auf jeder Hierarchiestufe einen Wert zu definieren, ist eine vollständige Flexibilität gegeben (siehe Abbildung).

15 Seite 15/ Packaging Sie haben eine Vielzahl von Paketen für eine Applikation, Teilkomponenten und diverse Umgebungen? Dependency Management der Teilpakete existiert nur in wenigen Köpfen oder in Excel Sheets? Ein intelligentes Packaging kann diese Herausforderungen lösen. Eine der größten Herausforderungen bei der Paketierung ist die Verknüpfung aller Komponenten, die für ein erfolgreiches Deployment notwendig sind. Das Paket muss meist neben einer Vollinstallation auch die Möglichkeit einer komponentenbasierten Installation bieten. Das Dependency Management spielt ebenfalls eine entscheidende Rolle, da Konfigurationen bestimmten Software-Ständen zugeordnet werden müssen und es immer wieder Komponenten gibt, die auf gezielte Versionsstände und weitere Komponenten aufsetzen. Wie aber werden sehr späte Konfigurationsänderungen noch berücksichtigt? Entweder wird ein neues Paket erstellt oder die Routine real time greift beim Deployment auf die CMDB zu. Voraussetzung hierfür ist eine Anbindung der CMDB an alle Umgebungen 3 Anforderungen One-click Deployment und Continuous Delivery erfordern die Umsetzung einer Vielzahl von Anforderungen. Nachfolgend sind in tabellarischer Form die elementarsten technischen sowie auch betrieblichen Anforderungen aufgelistet. 3.1 Technische Anforderungen Anforderung Zentrale Lieferverwaltung Parameterverwaltung Parameterersetzung Optionale Konfigurationsdateien Komponentenbasiertes Deployment Zentrale Buildplattform Erklärung Annahme und Verwaltung interner/externer Softwarestände, um Zulieferung von Abteilungen/Firmen zu managen. Verwaltung umgebungs- und applikationsabhängiger Parametersätze, um den Einsatz im Multiserverbetrieb zu gewährleisten. Ersetzungsmechanismen, um Konfigurationsdateien mit umgebungsabhängigen Parametern zu befüllen. In Enterprise-Umgebungen zwingend erforderlich, um sicherheitsrelevante Parameter bzw. zum Lieferzeitpunkt noch nicht feststehende Parameter erst zum Deploymentzeitpunkt zu ersetzen (Last-Minute-Eingriff, ohne ein neues Paket erzeugen zu müssen). Erstellung von Filtervorlagen, um nur bestimmte Teile eines Deployments automatisch ablaufen zu lassen. Zentraler Buildmechanismus, um reproduzierbare Softwarepakete zu gewährleisten.

16 Seite 16/23 Snapshot-Buildplattform Management interner Abhängigkeiten Skalierbarkeit Plattformunabhängigkeit In sich abgeschlossenes Paket (self-contained) Clusterfähigkeit Plug-In-Fähigkeit Integrationsfähigkeit Testfähigkeit Bereitstellung der Build- und Packagingumgebung, um Abteilungen/Firmen eine Validierungsplattform zu bieten. Definition interner Abhängigkeiten beim Deployment, um keine inkonsistenten SW-Stände zu erzeugen. Integrationsmöglichkeit beliebiger Anzahl an Applikationen und Tools in bestehende Lösung. Einsatz des erzeugten Packages in Multiserver-/Multibetriebssystemumgebungen. Einfache Handhabung und geringe Fehleranfälligkeit durch Bereit-stellung EINES Lieferpaketes. Es beinhaltet Software, Konfigurationen und Installationslogik. Rollout der Software im Clusterbetrieb, um mehrmaliges Deployment zu vermeiden. Möglichkeit der Spezifikation eigener Plug-In-Module, um einen Multiprojektbetrieb zu ermöglichen. Bereitstellung einfacher Schnittstellen, um das System in bereits bestehende Trackingund Ticketingsysteme integrieren zu können. Gewährleistung automatisierter Pre- und Postbuildtests, um die Einsatzfähigkeit des Systems/des Servers nicht zu beeinträchtigen. Möglichkeit der Integration von technischen und fachlichen Antests bis hin zu vollständigen Regressionstests 3.2 Betriebliche Anforderungen Anforderung Reduktion der Komplexität Standardisierung Automatisierung Flexibilität/Wartbarkeit Revisionssicherheit Kostenverrechnung Reduzierung des Spezialisten- Know-hows Erklärung Zusammenfassung von Einzelschritten; Vereinfachung von komplexen Prozessen; Abstrahierung von teifen technischen Details Übergreifende Einführung von Standards für Projekte und Betrieb. Auf Basis umgesetzter Standards werden -wo möglich- alle Arbeitsschritte toolgestützt automatisiert. Abbildung möglichst vieler Anwendungsszenarien für Projekte und Betrieb sowie einfache Wartbarkeit durch minimalste Wartungsfenster. Jederzeitige Sicherstellung der Versionssicherheit von Softwäreständen und Releases in jedem Umgebungstyp. Vollständige Kostentransparenz mit einer Ausdifferenzierung bis auf Einzelschrittebene. Standardisierung und Automatisierung versetzen jeden Projektmitarbeiter in die Lage, beliebige Prozessschritte kontrolliert ablaufen zu lassen.

17 Seite 17/23 4 Known Standards & Tools Da jedes Unternehmen ähnlichen Herausforderung bei der Umsetzung einer erfolgreichen Softwareintegration gegenübersteht, ist auf Basis dieser Anforderungen im Laufe der letzten Jahrzehnte eine erhebliche Anzahl an Open Source und kommerziellen Werkzeugen entstanden. 4.1 Tools zu Standards Nachfolgend sind in tabellarischer Form die prominentesten und erfolgreichsten Tools in Verbindung zum umgesetzten Standard aufgelistet (kein Anspruch auf Vollständigkeit). Standard Deployment / Umgebungsmanagement / Promoting Builds Parametrisierung Setup Testumgebungen Worklflow Management Buildmanagement Repository Paketierung Tools ControlTier, BMC Bladelogic, CfEngine, Puppet, Chef Go, Anthill Pro Flat-Files, XML, Datenbank, Puppet Vagrant, IBM STAF/STAX ARS, Servicenow, HP Service Manager, JIRA Jenkins, Bamboo, AntHill Pro, CruiseControl Nexus, Artifactory, Archiva ant, maven Installbuilder, InstallAnywhere, IZPack 4.2 Ein Installation Package für alle Umgebungen? Benötigen Sie für eine vollständige Installation einer Applikation mehrere Pakete? Es werden immer wieder mal Applikationsteile oder Pakete bei der Installation vergessen? Die Einzelpakete passen nicht zueinander bzw. Abhängigkeiten werden verletzt? Genau diese Herausforderungen managen Sie mit dem Einsatz von einem Installation Package pro Applikation für alle Umgebungen. Das Paket enthält immer eine vollständige, im Zusammenhang getestete und funktionierende Applikation. Beim Deployment entscheiden Sie, ob die gesamte Applikation oder nur Teilkomponenten deployed werden sollen. Dieser Mechanismus stellt die Voll-

18 Seite 18/23 ständigkeit der Applikation und Konfiguration zu jedem Zeitpunkt sicher. Konfigurationsprobleme gehören somit der Vergangenheit an. Sie suchen nie wieder die zur Applikationsversion gehörigen Konfigurationen. Zudem ist dieses Verfahren deutlich schneller und übersichtlicher im täglichen Einsatz im Projekt sowie im Betrieb. Ein Deployment eines einzigen Installation Package ist mit deutlich weniger Know-how und Arbeitsaufwand zu bewältigen. Nachfolgend eine Auflistung der Vor- und Nachteile eines einzelnen Paketes: Vorteile Vollständige funktionierende Software in einem Paket Konfiguration passt immer zur Software, da Teil des Paketes Reduzierung der Komplexität Ohne großes Spezialisten Know-how deploybar / Reduzierung von Kopf-Monopolen Abbildung des Dependeny Managements Integration von Tests Komponentenbasiertes Deployment Schneller und flexibler Nachteile Möglicherweise große Pakete Vollständige Software-Lieferung auch bei Hotfixes 4.3 Mögliche Features & Herausforderungen Was sind weitere Herausforderungen bei der Umsetzung eines Continuous Delivery? Welche weiteren Features sind sinnvolle Ergänzungen? Eine noch weitreichendere Flexibilisierung des vorgestellten Lösungsszenarios ist der konsequente Einsatz von virtualisierten Umgebungen. Stellen Sie sich vor, vor einem Deployment auf einer Testumgebung wird diese aus einer Standard-VM automatisiert neu aufgesetzt, deployed, mit Testdaten versehen und z.b. ein Regressionstest durchgeführt. Mittels Workflow Management Tool steuern und überwachen Sie den gesamten Ablauf. Auch eine Erweiterung in den Bereich der Cloud ist hier in vielen Fällen ein konsequenter Schritt. Eine vollständige Testintegration bedarf einiger Anstrengungen, die sich aber durch den hohen Automatisierungsgrad schnell auszahlen werden. Ein häufig gefordertes Feature ist ein Promotion Workflow. Eine Applikation wird auf einer Testumgebung installiert. Ist diese erfolgreich getestet worden, soll diese automatisch nach einem Approval in die nächsthöhere Umgebung promoted, d.h. automatisch dort deployt werden.

19 Seite 19/23 5 Erfolgsfaktoren bei der Einführung Kritische Erfolgsfaktoren für eine wirksame und übergreifende Continuous Delivery-Strategie bilden die Summe der folgenden Punkte: 1. Integrationsstrategie und -support Projekte müssen schnell und zuverlässig integriert werden. Auch der Support der Lösung ist eine ernstzunehmende Anforderung. 2. Flexibilität der Services Erweiterbarkeit, Skalierbarkeit, Wartungsarmut, Einbindung von externen Dienstleistern und Fall back-szenarien stellen hohe Anforderungen an die Flexibilität. 3. Kostenverrechnung Verursachergerechte und praktikable Verrechnungsmodelle sind für unterschiedliche Nutzergruppen zu entwickeln. 5.1 Integrationsstrategie und support Bei dem zuvor betrachteten Lösungsszenario mit seinen benötigten Workflows und Komponenten stellt sich für ein Projekt und das Unternehmen schnell die Frage nach der Wirtschaftlichkeit. Onboarding-Aufwände und die noch zu erwartenden Probleme von bestehenden Projekten lassen Projektmanager gerne zurückschrecken. Wie sind langfristig die Skalierbarkeit und die Performance der Lösung einzuschätzen? Und wie werden große Datenbankanteile integriert? Shared Service Platform Erst der Aufbau und der Betrieb der Continuous Delivery-Lösung als zentralisierte standardisierte Shared Service Platform schafft unternehmensweit enorme Skaleneffekte im Bereich der Kosten und Ressourcen. Das Aufsetzen einer solchen Lösung ist für ein einzelnes Projekt selten rentabel, weshalb häufig auf kleinere Strukturen und zum Teil auch auf mehr manuelle Tätigkeiten zurückgegriffen wird. Der Vorteil eines Shared Services liegt klar auf der Hand. Neben vorgefertigten erprobten Workflows und Techniken steht auch ein definierter Service Level bereit, der sich am Nutzungsverhalten der jeweiligen Projekte skalieren lässt. Eine solche Ausprägung ist anhand der Anzahl von Softwareintegrationen, Builds, Deployments etc. leicht zu berechnen.

20 Seite 20/23 Wie entsteht eine solche Plattform? Wer ist zu beteiligen? Neben einem Management Buy-In ist die Einbeziehung aller Stakeholder im Gesamtprozess der Lösung zu beachten. Angefangen bei den Enterprise-Architekten über Programm- und Projektmanager, Release Manager und Configuration Manager sowie Betrieb gilt es viele Personen zu überzeugen. Spürt ein Programm- oder Projektmanager, dass seine Releases deutlich an Lieferqualität und Geschwindigkeit zunehmen, ein Release- oder Configuration Manager, dass Softwarelieferungen schnell integriert und fehlerfrei auf Umgebungen gebracht werden, wächst die Akzeptanz sprunghaft. Kann ein Betrieb übergebene Projekte anhand von Standards zuverlässig warten und sind diese auch noch flexibel in der Handhabung und Anpassung wird es auch hier Zustimmung geben. Individuelle Dashboards liefern den beteiligten Parteien einen Status über verbrauchte Kontingente, Zustände des Release in Abhängigkeit vom Workflowschritt und der Softwarequalität anhand der Ticketauswertungen Onboarding Was sind die Herausforderungen eines schnellen und erfolgreichen Onboarding neuer Projekte? Wie können auch komplexe Projektstrukturen integriert werden? Eine Continuous Delivery-Lösung zeichnet sich durch die Abdeckung der wichtigsten Features und Prozessschritte im Software Lifecycle aus. Ein Projekt erwartet als erstes eine zielgerichtete und umfassende Beratung, welche Aufwände ein Onboarding bedingen, wie flexibel auf die Projektanforderungen eingegangen und wie kostenintensiv der spätere Betrieb wird. Auch beim Onboarding selbst ist eine qualifizierte Betreuung ein Erfolgsgarant. Sehr einfach lassen sich in der Onboardingphase Quick-wins erzeugen, indem vorhandene Automatisierungen und Standards integriert werden. Ein Prototyping oder die direkte Lösung des größten Projektproblems erzeugen auch schnell Akzeptanz. Ein Onboarding muss in jedem Fall schneller als der bisherige Prozess sein. Die Umstellung der Software Delivery darf nicht länger als wenige Tage dauern, um die gewonnene Akzeptanz nicht abzuschwächen. Um Unsicherheiten zu beseitigen, kann nach dem Canary Releasing -Prinzip vorgegangen werden, d.h. die Einführung von neuen Releases erfolgt erst für einen kleinen Nutzerkreis und wird bei Erfolg ausgeweitet. Je nach Ausgestaltung des Shared Service sind Standards und Spielregeln etabliert, die nicht immer für alle Projekte zutreffend sind. Die Rahmenkriterien sind individuell für jedes Unternehmen zu definieren. Es gibt auch durchaus komplexeste Strukturen, die in eine solche Lösung nur schwer zu integrieren sind.

21 Seite 21/ Flexibilität der Services Welche Anforderungen an die Flexibilität einer Continuous Delivery-Lösung haben Projekte? Wie häufig unterliegen diese Anforderungen Änderungswünschen? Projekte sind gemäß ihrem Einsatzrahmen immer wieder anderen und wechselnden Anforderungen und Ausprägungen unterworfen. Werden nur Teilaspekte des in der Continuous Delivery umgesetzten Workflows genutzt, so muss es möglich sein, auch nur Teilkomponenten einsetzen zu dürfen. Sind z.b. die Software Delivery und das Packaging durch den externen Lieferanten vorgegeben und nicht zu ändern, kann immer noch das Deployment über die Lösung gesteuert werden. Oder ist ein Deployment-Mechanismus vorhanden, kann die Lösung das Software Delivery und das Packaging übernehmen und so für einen standardisierten Input in das vorhandene Tool sorgen. Erweiterungen & Betrieb Die Erweiterung der Lösung um weitere Funktionalitäten und Automatisierungen muss auch zeitnah möglich sein. Ein zielgerichtetes Anforderungs- und Produktmanagement erleichtert den Ausbau der Gesamtlösung. Ein regelmäßiger Austausch mit den Nutzerkreisen liefert nicht selten wertvolle Anregungen für weitere Verbesserungen. In großen Unternehmen ist die Skalierbarkeit der Lösung auch ein wichtiger Aspekt, besonders wenn schnell eine größere Anzahl Projekte integriert und betrieben werden soll. Ist das Projekt einmal integriert, sollte es im laufenden Betrieb eine Anlaufstelle für Fragen und Probleme geben. Im Rahmen der Nutzung muss das Projekt jederzeit in der Lage sein, seine projekteigenen Spezifika innerhalb der Continuous Delivery-Lösung auf seine Bedürfnisse anzupassen. Innerhalb des gesamten Workflows müssen die Ausführungsfrequenzen und zeitpunkte beliebig konfigurierbar sein. In Summe muss das System sehr wartungsarm sein, um eine dauerhafte Akzeptanz im Betrieb zu erreichen. Integration externer Dienstleister Die Integration externer Dienstleister innerhalb einer solchen Lösung ist enorm wichtig. Sehr gerne wird Software extern entwickelt und muss später in das Unternehmen integriert werden. Möglich ist, die Anlieferung der Software mittels einer im Internet publizierten Webseite direkt durch den Lieferanten durchzuführen. Weitere Anbindung an das Ticketsystem erleichtert erheblich das gemeinsame Arbeiten. Für externe Softwareentwicklungshäuser darf der Aufwand der Integration in den geforderten Software Delivery-Standard nur minimal sein, um dem gewünschten Standard die notwendige Akzeptanz zu verschaffen. Integration Datenbankanteile Eine weitere Herausforderung sind große Datenbankanteile. Können Datenbankanteile und Migration als Teil der Lösung integriert werden? Welche Hürden sind zu überwinden? Java-basierte Anwendungen bestehen fast immer aus einem Applikations- und Datenbankanteil. Es ist empfehlenswert, in das Installation Package nur die Datenbankstrukturen für das anschließende Deployment aufzunehmen. Die meist großen Datenmengen bringen erfahrene Datenbankadministratoren dann in die deployte Datenbank ein. Ist die Datenmenge (z.b. Testdaten, sich nicht ändernde Produktdefinitionen etc.) eher statisch und kleiner 100MB, bietet sich eine Integration ins Paket trotzdem an. Größere Datenbank Migrationen sollten besser von dem eigentlichen Installation Package getrennt werden, um den meist individuellen Aufgaben bei einer Datenmigration gerecht zu werden.

22 Seite 22/23 Fallback-Szenarien Wie sieht ein Fallback-Szenario im Fehlerfall aus? Prinzipiell lässt sich feststellen, dass beim Einsatz einer standardisierten und automatisierten Continuous Delivery-Lösung die Fehlerquote nicht selten um 90% sinkt. Dadurch wird einem Fallback-Szenario nicht mehr so viel Priorität beigemessen. Das typische Fallback-Szenario ist die Installation des Vorgänger-Releases. Bei größeren Datenbankanteilen ist auf die Koordination mit den Datenbankexperten zu achten. Ist die Installation des Vorgänger-Releases keine umsetzbare Praxis, ist innerhalb des Installation Package eine vollständige Fallbacklösung zu integrieren. Die Umsetzung einer solchen Lösung ist erfahrungsgemäß mit erhöhtem Aufwand verbunden und höchst individuell je nach Projekt. 5.3 Kostenverrechnung Wie erfolgt eine verursachergerechte Verrechnung der finanziellen Aufwände einer etablierten Continuous Delivery-Lösung? Welche Anforderungen werden an ein praktikables Charging gestellt? Je nach Nutzergruppe ergeben sich unterschiedliche Anforderungen an die Verrechnung. Ein Projekt möchte die Kosten möglichst auf ein einzelnes Release und auf Taskebene aufgeschlüsselt haben, während Operations mit generellen nutzungsabhängigen Pauschalen auskommen würde. Grundsätzlich bietet sich eins der folgenden Verrechnungsmodelle an: 1. Anwendungsgröße und -komplexität Zu integrierende Applikationen werden nach ihrer Größe und bestimmten Kriterien in Kategorien (z.b. small, medium, large) eingeteilt und entsprechend belastet. 2. Anzahl genutzter Komponenten Die zum Einsatz kommenden Komponenten der Gesamtlösung bestimmen die Kosten. 3. Nutzungsfrequenz/Betriebskosten Die Berechnung der Kosten erfolgt nach tatsächlicher Nutzung der Prozesse und Komponenten. Gerne werden auch Kombinationen aus den oben genannten Modellen verwendet. Wird eine Continuous Delivery-Lösung als Shared Service betrieben, ist es praktikabel, die Kosten für die einzelnen Dienstleistungen zu benennen und in Rechnung zu stellen. Dies ermöglicht dem Projekt und dem Betrieb die notwendige Transparenz und die Administration ist mit vertretbarem Aufwand durchführbar. Idealerweise werden die einzelnen Dienstleistungen, z.b. auf Ebene Einzelintegration, -packaging und -deployment, automatisch innerhalb des Workflow Management Tools erfasst und in einem Dashboard gegen das vereinbarte Service Level oder Operational Level abgeglichen. Somit herrscht jederzeit Transparenz über bereits verbrauchte Kontingente. Aber auch potentielle Trends und frühere verbrauchte Kontingente werden offenbart.

23 Seite 23/23 6 Fazit/Ausblick Bereits ab der Integration des zweiten Projektes rechnet sich die Umsetzung der beschriebenen Continuous Delivery-Lösung für ein Unternehmen. In Summe wird eine flexiblere und schnellere Bereitstellung von Releases bei deutlich besserer Qualität und sinkenden Kosten erzielt. Kopfmonopole weichen einem strukturierten und dokumentierten Verfahren, welches leicht skalierbar und flexibel erweitert werden kann. Völlig neue Möglichkeiten werden hiermit eröffnet. Weitere Integration von Teilbereichen des Software Lifecycle wie z.b. Continuous Integration und Testing sind denkbar. Besonders große Unternehmen haben die Problemstellung erkannt und werden die Professionalisierung des Continuous Delivery vorantreiben. 7 Links & Literatur.tricon Video.tricon Homepage avato Newsletter: Continuous Software Integration & Delivery I