Aufrufe
vor 1 Monat

02 | 2017 NEWS

  • Text
  • Continuous
  • Thinc
  • Msggillardon
  • Unternehmenssteuerung
  • Anforderungen
  • Integration
  • Sowohl
  • Meldewesen
  • Fachlichen
  • Deployment
Insight

u Unternehmenssteuerung

u Unternehmenssteuerung Neben diesen Grundprinzipien existieren eine Fülle weiterer Handlungsempfehlungen, die sich ebenfalls bewährt haben. Sie vollständig aufzuführen würde allerdings den Rahmen dieses Artikels weit übersteigen. Continuous Deployment Continuous Deployment ist der letzte logische Schritt einer kontinuierlichen Delivery Pipeline und eine Fortführung des Continuous-Delivery-Gedankens. Doch während bei Continuous Delivery bewusst entschieden und festlegt wird, wann man mit einer Softwareversion in Produktion geht, resultiert bei Continuous Deployment jeder erfolgreiche Build in einem automatisierten Deployment in Produktion. Eine bewusste Entscheidung wird nicht (mehr) getroffen. Spätestens jetzt ist eindeutig, wie tief greifend 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. Klar ist auch, dass man eine kontinuierliche Delivery Pipeline unter anderem deshalb implementiert, um eine schnellere Time-to- Market zu realisieren, die der Endkunde auch sichtbar wahrnehmen kann. Gerade in dieser letzten Phase steckt also das größte Risiko, da sie eine Kundenauswirkung hat. Gleichzeitig wird erst hier der Mehrwert einer kontinuierlichen Delivery Pipeline realisiert. Die Frage ist, wie sich Continuous Deployment umsetzen lässt, ohne die Stabilität durch häufige Releases zu beeinflussen? Eine DevOps-Forderung lautet „fail fast, fail often“. Das heißt, viele Fehler zu machen, ist ein explizites Ziel von DevOps, denn 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. Eine weitere DevOps-Forderung lautet „learn fast, learn often“. Sie ermöglicht, schnell, wiederholbar, automatisiert und auch qualitativ hochwertig Softwarereleases zu deployen. Denn Soft- Der amerikanische Wissenschaftler und Autodidakt Thomas Alva Edison ging als Erfinder der Glühlampe in die Geschichte ein. Allerdings brauchte er rund 2.000 Anläufe, bis er den ersten Kohlefaden in einer Lampe zum Leuchten bringen konnte. Trocken kommentierte Thomas Edision seine Fehlversuche so: „Ein Misserfolg war es nicht. Denn wenigstens kennt man jetzt 2.000 Arten, wie ein Kohlefaden nicht zum Leuchten gebracht werden kann." wareversionen, die fehlerbehaftet sind, dürften gar nicht durch den Automatismus in Produktion kommen, sondern müssten vorher zwingend in der Pipeline scheitern. Die Automatisierung der Prozesse ermöglicht es also, Softwarepakete schnell 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 geht es also vor allem um Risikomanagement. Produktionsausfälle durch ein neues Release lassen sich allerdings nicht zu 100 Prozent ausschließen, da Test- und Produktionsumgebung meist unterschiedlich sind. Kommt es zu einem Produktionsausfall, ist es wichtig, schnell auf die alte Version zurückfallen (Roll-Back), also einen langen Ausfall der Produktion verhindern zu können. Das bedeutet aber, dass die Anwendung in Produktion nicht zur Verfügung steht. Ein funktionierender Roll-Back-Prozess ist daher absolut notwendig. Um für den Notfall gewappnet zu sein, muss er im Vorfeld getestet werden und eine frühere Version immer zur Verfügung stehen. Continuous Deployment kennt noch weitere Mechanismen zur Risikoreduktion beim Deployment in Produktion: Roll-Forward- oder Patch-Forward-Prozess bedeutet, dass bei einem Fehler eine neue Version der Software deployed wird, die den Fehler korrigiert. Diese Version muss ebenfalls getestet werden, setzt aber das Vertrauen in die Delivery Pipeline und 40 I NEWS 02/2017

Unternehmenssteuerung t ihre Schnelligkeit voraus. Der Aufwand eines Roll-Forwards entspricht dem eines Roll-Backs, ist aber meist weniger komplex, vor allem deshalb, weil Änderungen an Datenbanken bei einem Roll- Back schwierig rückgängig zu machen sind, während beim Roll- Forward die Datenbankänderungen oft erhalten bleiben können. Feature Toggle ist eine Funktionalität, bei der bestimmte Features mittels eines Schalters aktiviert oder deaktiviert werden können. Features lassen sich so implementieren und der Code mit dem Feature in Produktion bringen, ohne dass diese aktiviert sind. Voraussetzung ist, dass die Features jeweils separat entwickelt werden. Durch Feature Toggles wird die Implementierung vom Deployment entkoppelt. Features lassen sich bereits in Produktion testen, wenn sie zum Beispiel für bestimmte Nutzer oder Kundengruppen aktiviert werden, um deren Feedback zu erhalten. Auswirkungen und Metriken, die durch den Feature-Einsatz erzielt werden sollen, lassen sich so plausibilisieren (A/B-Testing). Es gibt verschiedene Arten von Feature Toggles, die hier exemplarisch aufgelistet sind: > > Release Toggles dienen dazu, die Aktivierung eines Features von dem Release-Termin der Codeänderungen für dieses Feature zu entkoppeln. Zunächst wird der Code deployed und das Feature deaktiviert. Wenn das Feature tatsächlich fertig und getestet ist, wird der Toggle aktiviert. > > Geschäftliche Toggles dienen dazu, Features für Kunden auszuprobieren oder gezielt nur bestimmten Kundengruppen anzubieten. > > Betriebliche Toggles dienen dazu, Features zu deaktivieren, um den Ausfall der gesamten Anwendung zu vermeiden. Blue/Green-Deployment ist dadurch charakterisiert, dass es zwei parallele Produktionsumgebungen gibt. Ein Router steuert die entsprechende Umgebung für den Endnutzer an. Wird eine neue Softwareversion deployed, so wird diese zum Beispiel in die Umgebung „Blue“ deployed, während für die Endnutzer nach wie vor die „Green“-Umgebung genutzt wird. Durch eine Umkonfiguration des Routers kann die neue Softwareversion für die Endnutzer letztendlich verfügbar gemacht werden. Ein Vorteil davon ist, dass das neue Release neben dem alten Release betrieben und später gegebenenfalls umgeschaltet werden kann. Zusätzlich erfolgt durch den Produktionseinsatz keine Downtime, da die Anwendung durchgehend verfügbar ist. Ein weiterer Vorteil: Die neue Softwareversion kann, auch in Bezug auf die Performance, in einer Produktionsumgebung ausgiebig getestet werden, bevor sie livegeschaltet wird. Canary Release baut auf dem Blue/Green-Deployments-Ansatz auf und ergänzt ihn um eine stufenweise Lasterhöhung. Ein neues Softwarerelease wird zunächst nur auf einigen Server im Cluster ausgerollt, bevor die Software auf allen Rechnern deployed wird. Auch hier ist es möglich, zuerst die Endnutzer von der Nutzung des neuen Releases auszuschließen und das Release initial einer geschlossenen Benutzergruppe verfügbar zu machen. Der Rollout an die Endnutzer erfolgt dann jedoch, im Gegensatz zu den Blue/Green-Deployments, nach erfolgreichem Test nicht auf Knopfdruck (von 0 auf 100 Prozent), sondern sukzessiv. Hierzu wird das neue Release auf einer steigenden Anzahl von Servern im Cluster ausgerollt und mit der Lasterhöhung einer stetig steigenden Endnutzerzahl (von 10 auf 20 Prozent etc.) zur Verfügung gestellt. Sollte es zu Problemen kommen, ist nach wie vor ein schneller Wechsel auf die alte Release-Version möglich. Daraus ergeben sich folgende Vorteile von Continuous Deployment: > > Jede Änderung geht direkt in Produktion. > > Das Feedback erfolgt noch schneller als durch Continuous Delivery. > > Durch den Einsatz von Feature Toggles ist es möglich, nach Produktion zu deployen, ohne die neuen Funktionalitäten zu nutzen. Es sind also Teile, die noch unfertig sind, bereits in Produktion deployed. So kann bereits Feedback über das Deployment der neuen Teile gesammelt werden. > > Ebenfalls ist es möglich, eine neue Funktionalität bereits von einer kleinen Nutzergruppe testen zu lassen, um so ein frühes Feedback zu bekommen. NEWS 02/2017 I 41

msgGillardon

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
2016 | Seminarkatalog | Finanzen

Über msgGillardon



Wir bieten unseren Kunden Management-, Business-, Prozess- und IT-Beratung. Darüberhinaus entwickeln wir kundenspezifische Lösungen, sowohl auf Basis unserer eigenen Software als auch auf Basis marktüblicher Standardsoftware. Sofern gewünscht entwickeln wir auch Individuallösungen - ganz auf Ihre Bedürfnisse zugeschnitten. Mit unserer Beratungskompetenz, bankfachlicher Expertise und IT-Know-how unterstützen und begleiten wir Sie umfassend und helfen Ihnen, in dynamischen Märkten schnell, flexibel und erfolgreich zu handeln.

Ihr Erfolg ist unser Antrieb: Unsere mehr als 400 Mitarbeiterinnen und Mitarbeiter arbeiten mit Kompetenz und Leidenschaft an der Realisierung gemeinsamer Ideen - zuverlässig, engagiert und verantwortungsbewusst.

msgGillardon - Ihr Partner für zukunftsweisende Lösungen für die Finanzbranche.


© 2015 by msgGillardon AG - powered by yumpu Datenschutz | Impressum