Aufrufe
vor 1 Monat

02 | 2017 NEWS

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

Gemeinsam: schneller,

Gemeinsam: schneller, besser, sicherer! Kernbestandteile einer kontinuierlichen Delivery Pipeline von Erik Benedetto Nachdem in der NEWS 01/2017 der Konflikt zwischen Softwareentwicklung und Betrieb sowie Lösungsmöglichkeiten dieses relevanten Themas untersucht wurden, legt dieser Artikel den Fokus auf die Begriffe DevOps, Continuous Integration, Continuous Delivery und Continuous Deployment und die Bausteine einer kontinuierlichen Delivery Pipeline. DevOps, Continuous Integration, Continuous Delivery und Continuous Deployment Entwicklung und Betrieb werden in der Regel als eigenständige Bereiche getrennt betrachtet; als Gründe werden Arbeitsteilung, Spezialisierung sowie höhere Effizienz durch Standardisierung und Industrialisierung genannt. Das gemeinsame Ziel, einen möglichst guten Service für interne oder externe Kunden anzubieten, gerät dadurch leicht in Vergessenheit. Dennoch ist diese Trennung in einzelne Organisationseinheiten faktisch eine große Gemeinsamkeit heutiger IT-Organisationen (siehe Abbildung 1), die in der Regel mit einer unterschiedlichen Perspektive auf die Anwendungen begründet wird. Die Kombination von Wissen aus Entwicklung und Betrieb ist aber für einen sinnvollen Anwendungsbetrieb notwendig und aus Kundensicht sogar unerlässlich. Denn für die Lösung eines Problems kann, je nach Ursache, das Wissen der einen oder anderen Einheit beitragen. Dass die Kollaboration von Entwicklung (Dev) und Betrieb (Ops) möglich ist, zeigt der DevOps-Ansatz. Hier arbeiten Entwicklung und Betrieb gemeinsam in einem Team und sind jeweils für einen bestimmten fachlichen Service zuständig (siehe Abbildung 2). Der für Entwicklung und Betrieb benötigte Technologiemix, also der „Technologie-Stack“, wird eigenverantwortlich durch das gesamte Team betrieben und gewartet. Jedes Team kann so den Service weiterentwickeln, optimieren und betreiben, wie es ihn benötigt. Da sowohl der Betrieb (Entwicklung/Produktion) als auch die Lösung von Problemen in der Verantwortung desselben Teams liegt, können Abstimmungen zu Erweiterungen des Technologie-Stacks, zum Beispiel im Monitoring, schnell realisiert und die Entscheidungen eigenverantwortlich getroffen werden. Der Kunde profitiert von einem dedizierten Ansprechpartner für einen fachlichen Service, der sowohl die Betriebs- als auch die Anwendungssicht kennt. Unternehmensweite Standards beziehen sich nur noch auf die Hardware und eine Cloud-Infrastruktur. Übergreifend über die verschiedenen 36 I NEWS 02/2017

Unternehmenssteuerung t IT-Management Kunde BIZ DEV OPS Abbildung 1: Klassische IT-Organisation Teams arbeitet somit nur ein Basisbetrieb, der die Hardware und Cloud-Infrastruktur wartet und bereitstellt. Die Installation/ Konfiguration von Anwendungen auf den virtuellen Maschinen erfolgt jeweils selbstständig durch die Teams. dass isolierte Änderungen an der Codebasis sofort geprüft und anschließend zur Gesamtcodebasis einer Software hinzugefügt werden. Das heißt, Entwickler integrieren ihren Code mehrmals am Tag in ein gemeinsames Repository und jeder Commit in der Versionsverwaltung führt zu einem automatisierten Build-Prozess. Über einen automatischen Fehlerreport oder Alarm erhalten sie ein unmittelbares Feedback, sodass ein versehentlich integrierter Fehler schnellstmöglich identifiziert und korrigiert werden kann. Mit Tools, die eine kontinuierliche Integration ermöglichen, können meist auch Tests automatisiert und eine fortlaufende Dokumentation erstellt werden. Die Tests können sowohl Unit- und/oder Integrationstests, funktionale und/oder nicht funktionale Tests als auch Performance- und/oder Security-Tests umfassen. Umbau der Organisation nicht zwingend erforderlich Auch wenn es auf den ersten Blick so erscheint, ist es kein Muss, die Organisation für die Einführung von DevOps umfassend zu verändern. Zum Einstieg ist es sinnvoll, zunächst einen fachlichen Service nach dem DevOps-Gedanken durch ein gemeinsames Team aus Fachbereich, Betrieb und Entwicklung zu etablieren und weiterzuentwickeln. Noch einfacher wird der Einstieg, wenn im ersten Schritt die Kollaboration der drei Organisationseinheiten Fachbereich, Betrieb und Entwicklung forciert wird, zum Beispiel durch Zusammenlegung der Räumlichkeiten, Durchführung von Workshops zum Wissenstransfer etc. Nicht sinnvoll ist es dagegen, ein DevOps-Team neben Entwicklung und Betrieb zu installieren. Dies wäre ein weiteres Silo, was dem DevOps-Gedanken widerspricht. Continuous Integration (und Test) Continuous Integration ist eine Methode in der Softwareentwicklung, die auf eine kontinuierliche Integration von Codeänderungen in die Codebasis einer Softwareanwendung, die Validierung des Codes durch Unit-Tests und eventuell Integrationstests fokussiert. Kontinuierliche Integration bedeutet, Eine einfache Variante der kontinuierlichen Integration ist zum Beispiel der Nightly Build, bei dem jeweils über Nacht alle Codeänderungen in einem Build integriert und automatisch einem Integrationstest unterzogen werden. Die Applikation ist danach in einer Testumgebung verfügbar. Ein Vorteil von automatisierten Tests ist, dass spezifische Prüfungen und Prüfbedingungen priorisiert werden können. So kann sichergestellt werden, dass entweder nur ausgewählte Testfälle oder aber das gesamte Testset mit jedem Build geprüft wird. Kontinuierliche Tests können somit als Erweiterung der testgetriebenen Entwicklungspraktik (TDD) genutzt werden. Wesentliche Bestandteile von Continuous Integration sind in der Regel folgende: Gemeinsame Codebasis: In eine gemeinsame Codebasis (Repository) mit einer Versionsverwaltung können alle Entwickler einer Arbeitsgruppe ihre Änderungen kontinuierlich integrieren. Automatisierte Tests: Jede Integration muss einheitlich definierte Tests und statische Codeüberprüfungen durchlaufen, bevor die Änderungen integriert werden. Hierfür ist ein automatisierter Build-Prozess notwendig. Idealerweise werden separate Testumgebungen genutzt, damit darauf auch gezielt Verfahren implementiert werden können, um die Testlaufzeit zu minimieren. NEWS 02/2017 I 37

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