Aufrufe
vor 5 Monaten

01 | 2018 public

  • Text
  • Verwaltung
  • Microservices
  • Continuous
  • Digitale
  • Deutschland
  • Digitalisierung
  • Moderne
  • Betrieb
  • Integration
  • Deployment
IT-Megatrends in der öffentlichen Verwaltung

Continuous Delivery geht

Continuous Delivery geht schon auf das agile Manifest zurück. Dort heißt es im ersten Prinzip: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ 3 Continuous Delivery verfolgt dieses Ziel durch Fortführen agiler Entwicklungspraktiken bis in die Produktion. Continuous Delivery ist eine Sammlung von Techniken, Prozessen und Werkzeugen, die den Auslieferungsprozess der Software automatisieren und verbessern. Dieser Auslieferungsprozess lässt sich sowohl unter zeitlichen (timeto-market) als auch unter qualitativen Aspekten (Automatisierung, wiederholbare und zuverlässige Prozesse) verbessern. CONTINUOUS DELIVERY Ist auch ohne DevOps anwendbar. Erweitert den Feedbackzyklus von CI bis in die Produktion. Ist im agilen Manifest begründet. Sammlung von Techniken, Prozessen und Werkzeugen, die den Prozess der Softwareauslieferung verbessern. Applikation ist in der Pre-Prod-Umgebung verfügbar. CDel = fordert ein kontinuierliches Bereitstellen von SW-Paketen in der Pre-Prod, das Deployment ist manuell; CDepl = fordert ein kontinuierliches Deployment in die Prod. Continuous Delivery beruht auf acht, durch J. Humble und D. Farley 2010 ausgearbeitete Prinzipien 4 , die als konkrete Leitsätze oder Empfehlungen formuliert sind: 5 1. Der Prozess der Software Bereitstellung/-Release muss wiederholbar und zuverlässig sein. 2. Automatisieren Sie alles! Ein manuelles Deployment kann niemals als wiederholbar und zuverlässig beschrieben werden. Ein ernsthaftes Investment in die Automatisierung aller Aufgaben, die Sie wiederholt durchführen, führt zwingend zu einer erhöhten Zuverlässigkeit. 3. Wenn es schwierig oder schmerzhaft ist, tun Sie es öfter. Dies scheint zunächst widersprüchlich, führt allerdings zu einem automatischen, kontinuierlichen Verbesserungsprozess. Je öfter Sie Hürden nehmen müssen, umso wahrscheinlicher ist es, dass Sie beginnen werden, den Prozess zu vereinfachen und zu automatisieren, damit er zukünftig einfacher und wiederholbarer wird. 4. Pflegen und managen Sie alles in der Quellcodeverwaltung. 5. Fertig bedeutet „released“. Dieses Prinzip trägt die Verantwortung weit über den eigenen Bereich und die Aufgabe hinaus. Die Verantwortung eines Entwicklers endet nicht mit dem Einchecken des Codes in das Repository, sondern erst, wenn sichergestellt ist, dass der Code in der Produktion fehlerfrei läuft und das Release-Monitoring dies bestätigt. 6. Bauen Sie Qualität ein! Berücksichtigen Sie den Qualitätsaspekt umfassend in den Metriken und investieren Sie ausreichend Zeit hierfür. Erst das Messen der Qualität in allen Phasen ermöglicht es, einen kontrollierten Prozess zu etablieren, bei dem die Qualität an verschiedenen Stellen im Entwicklungsprozess gesteuert verbessert werden kann. Eine verbesserte Qualität wiederum führt zu einfacherer Wartung und zu einer langfristigen Kostenreduktion. 7. Jeder hat die Verantwortung für den Release-Prozess. Nur die für den Bürger (den Endkunden) verfügbaren Dienstleistungen (und Produkte) bestimmen die Wahrnehmung und Bewertung der dienstleistenden Behörde. Im Falle von Software ist das also die Software, die produktiv (released) ist. Aus diesem Grund sollten auch alle gemeinsam für den Release-Prozess die Verantwortung tragen. Jede Aufgabe sollte deshalb immer die Effizienz und die Qualität des Release-Prozesses als Ziel berücksichtigen, damit neben der originären Aufgabe frühzeitig auch die Bereitstellung für den Kunden berücksichtigt wird. 8. Verbessern Sie kontinuierlich. Eine kontinuierliche Verbesserung ist eine ständige Anpassung der Prozesses und Verfahren an sich verändernde Rahmenbedingungen. Jede Verbesserung führt wiederum zu mehr Effektivität und Effizienz und ermöglicht es wiederum, im Falle von neuen Rahmenbedingungen schneller darauf zu reagieren. Neben diesen Grundprinzipien existiert eine Fülle von weiteren Handlungsempfehlungen, die sich bewährt haben. Im Rahmen dieses Fachartikels ist es allerdings nicht möglich, diese vollständig aufzuzählen, weshalb nur ein kleiner Ausschnitt präsentiert wird. CONTINUOUS DEPLOYMENT Beschreibt das automatisierte Deployment in Produktion. Ist die logische Konsequenz aus Continuous Delivery. Ist auch ohne DevOps anwendbar. Nutzt Methoden wie • Feature Toggles, • Canary Releases, • Blue-Green Deployments. 3 http://agilemanifesto.org/iso/de/principles.html 4 J. Humble, D. Farley, 2010: Continuous Delivery: Reliable Software Releases Through Build, Addison-Wesley 5 https://dzone.com/articles/8-principles-continuous 36 | .public 01-18 | Informationstechnologie

CONTINUOUS DEPLOYMENT Continuous Deployment ist der letzte logische Schritt einer kontinuierlichen Delivery-Pipeline und eine Fortführung des Continuous-Delivery-Gedankens. Was ist nun der Unterschied zwischen den beiden? Während man bei Continuous Delivery festlegt, wann man mit einer Softwareversion in Produktion geht, also eine bewusste Entscheidung fällt und somit die Wahl hat, resultiert bei Continuous Deployment jeder erfolgreiche Build aus einem automatisierten Deployment in Produktion. Spätestens jetzt ist eindeutig, wie tiefgreifend der Ansatz einer kontinuierlichen Delivery-Pipeline ist, wie wichtig die Bestandteile und deren Umsetzung sind und wie groß die Auswirkungen sowohl im Unternehmen als auch für den Endnutzer sein können. Deutlich ist dann auch die Motivation, eine kontinuierliche Delivery-Pipeline zu implementieren: Dies geschieht in der Regel, um eine schnellere Time-tomarket zu realisieren. Diese sollte dementsprechend auch fachlich oder technisch sinnvoll sein, und der Endkunde sollte sie auch sichtbar wahrnehmen können. Gerade in dieser letzten Phase steckt also das größte Risiko, da ein automatisches Deployment eine unmittelbare Kundenauswirkung hat. Gleichzeitig wird erst hier einer der großen Mehrwerte einer kontinuierlichen Delivery-Pipeline realisiert. „Learn fast, learn often“ ist also, konkreter formuliert, die Forderung von Continuous Delivery, die es überhaupt ermöglicht, schnell, wiederholbar, automatisiert und auch qualitativ hochwertig Softwarereleases zu deployen. Als Erfinder der Glühlampe ging der amerikanische Wissenschaftler und Autodidakt Thomas Alva Edison in die Geschichte ein. Allerdings: Rund 2.000 Anläufe brauchte Edison, bis er den ersten Kohlefaden in einer Lampe zum Leuchten bringen konnte. Ein Ergebnis, das den Amerikaner jedoch wenig schockte, denn trocken kommentierte Thomas Edison seine Fehlversuche mit dem Satz: „Ein Misserfolg war es nicht. Denn wenigstens kennt man jetzt 2.000 Arten, wie ein Kohlefaden nicht zum Leuchten gebracht werden kann.“ Softwareversionen, die also fehlerbehaftet sind, dürfen demnach gar nicht erst durch den Automatismus in Produktion kommen, sondern müssen zwingend vorher in der Pipeline scheitern. Die Automatisierung der Prozesse ermöglicht es, schnell Softwarepakete in Produktion zu bringen, während die kontinuierliche Kollaboration sicherstellt, dass nur solche in Produktion gelangen, die qualitativ hochwertig und fehlerfrei sind. Bei Continuous Deployment spielt daher das Risikomanagement eine sehr wichtige Rolle. Wie lässt sich ein Continuous Deployment also umsetzen, ohne dass die Stabilität durch (zu) häufige automatische Releases negativ beeinflusst wird? Hier greift die Continuous-Delivery-Forderung: „Fail fast, fail often.“ Provokant gesagt, ist es ein explizites Ziel von DevOps, viele Fehler zu machen, denn Fehler sind erwünscht. Jeder Fehler, der frühzeitig entdeckt und korrigiert wird, kann zur kontinuierlichen Verbesserung der automatisierten Delivery-Pipeline genutzt werden. Dies setzt wiederum einen ständigen Feedbackprozess in der DevOps-Organisation voraus, der durch Kollaboration der Organisationseinheiten getragen wird. DEV OPS 1 Produktionsausfälle durch ein neues Release lassen sich trotzdem nicht 100-prozentig ausschließen, da meist Test- und Produktionsumgebung unterschiedlich sind. Kommt es also zu einem Produktionsausfall, ist es notwendig, schnell auf die alte Version zurückzufallen oder aber einen nennenswerten Ausfall der Produktion zu verhindern. Traditionell wird der Roll-Back-Prozess (das Zurückspielen der Vorgängerversion) als Maßnahme bei Eintritt des Risikos einer nicht funktionierenden Produktivversion genutzt. Ein Roll-back bedeutet, dass die Anwendung in Produktion nicht zur Verfügung steht, weshalb es umso wichtiger ist, dass der Roll-back-Prozess funktionieren muss. Hierzu muss er also in Vorfeld ausführlich und immer wieder getestet werden und eine alte Version auch immer zur Verfügung stehen, um für den Notfall gewappnet zu sein. Continuous Deployment kennt allerdings auch weitere Mecha- 2 DEV OPS nismen zur Risikoreduktion beim Deployment in Produktion: BIZ 3 DEV OPS Abbildung 5: DevOps setzt auf kontinuierliche Kollaboration und Feedbacks Roll-forward Eine Alternative zum Roll-back ist der Roll-forward-/Patch-forward-Prozess. Dabei wird bei einem Fehler eine neue Version der Software deployed, die den Fehler korrigiert. Auch diese Version Informationstechnologie | .public 01-18 | 37

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum