![\"Deployment-Pipeline\"](\"https:\/\/cabp.server-ip.info\/wp-content\/uploads\/Deployment-Pipeline-300x184.jpg\")
<\/a><\/p>\nIm Gesch\u00e4ftsbereich Software Engineering (SE) reifen \u2013 insbesondere in der Entwicklung (Dev) – seit mehr als einem Jahrzehnt agile Praktiken und Methoden. Diese haben sich unter dem Stichwort Continuous Integration (CI) auch in einer unverzichtbaren Werkzeugkette niedergeschlagen. Im Betrieb (OPS) von Middleware hingegen, hinkt die Realit\u00e4t den Erfordernissen noch deutlich hinterher.<\/p>\n
F\u00fcr Middleware-Ops muss eine die Deployment-Pipeline implementierend Werkzeugkette vor Allem individuelle Konfigurationsprozesse abbilden k\u00f6nnen und diesen durch kontinuierlich und dezentral (weiter)entwickelter Automatisierungsketten und \u2013bausteinen flexibel halten.
\nNeben einem anpassbaren Datenmodell in XML zur dezentral verantworteten Datenhaltung und inter-system-kommunikation \u00fcber Webservices ist die strikte Versionierung der Konfiguration und die Nachvollziehbarkeit von \u00c4nderungen durch Logging und Reporting ist schlicht notwendig.<\/p>\n
Nicht zuletzt ist auch eine Integrationen in weitere Prozessbereiche wie z.B. Product Lifecycle Management (PLM), IT-St\u00f6rungsmanagement, etc. w\u00fcnschenswert. So wird ein zentraler IT-Betrieb, bei gleichzeitiger dezentraler Konfiguration f\u00fcr Projekte, Mandanten oder Gruppen m\u00f6glich.<\/p>\n
<\/p>\n
Continous Delivery<\/h2>\n
Jeder kennt und viele f\u00fcrchten diese Wochenenden, an denen ein System Upgrade ausgerollt werden soll, bevor am Montag sich die Sonne \u00fcber den Horizont schiebt. Was nutzt ein integrierter (Oracle) Middleware Stack, wenn der Entwicklungs-, Deploy- und Releaseprozess nicht integriert sind? Wie stopft man das lang vergessene Loch zwischen Development und Operations? Wie bekommt man diese letzte Meile in den Griff? Eine funktionierende CI ist dabei nur ein erster Schritt! Neben Code sind Konfiguration, Middleware-Stack, Daten und Systemkontext fragil, komplex und kritisch.<\/p>\n
\u00a0 \u201eDeploy the same artifacts in every environment\u201c<\/i><\/p>\n
\u201eKeep everything in version control\u201c<\/i><\/p>\n
\u201eAutomate almost everything\u201c<\/i><\/p>\n
\u00a0Die Continous Delivery beschreibt den Prozess f\u00fcr DevOps. Ziel ist die Integration der verschiedenen Aufgaben und Funktionen in einer Deployment Pipeline, die Bereiche des Change-, Build-, Requirements-, Integrations-, Release- und Test-Management unter agiler Ma\u00dfgabe implementiert. Dazu geh\u00f6rt:<\/p>\n
- \n
- continuous integration and deployment<\/li>\n
- data management<\/li>\n
- configuration management<\/li>\n
- environment management<\/li>\n
- automated testing<\/li>\n
- release management<\/li>\n<\/ul>\n
<\/p>\n
\u00a0Agile Delivery<\/h2>\n
Der zunehmende Einsatz komplexer Middleware verschiebt ma\u00dfgebliche Aufw\u00e4nde aus der Softwareentwicklung\u00a0 (Dev) in den Betrieb (Ops). Auch die Middleware und damit Middleware-Ops, ist zunehmen im Sog dynamischer und sich entwickelnder Anforderungen. Und das meint wandelbare, sich im Zeitablauf entwickelnde Anforderungen an Middleware und deren effiziente und qualitativ hochwertige Umsetzung.<\/p>\n
System Engineering ist im Betrieb (OPS) hingegen noch immer weitgehend einem statischen Idealbild verhaftet. Und die notwendigen Schritte hin zu einer anforderungsgetriebenen zunehmend m\u00e4chtigen und komplexen Middleware stehen aus. Jede \u00c4nderung ist\u00a0 ein ma\u00dfgeblichen Risiko, das die Stabilit\u00e4t gef\u00e4hrdet; im Zeitalter eines \u201eagile\u201c Megatrends.<\/p>\n
<\/p>\n
Lean Delivery<\/h2>\n
Eines der Dinge, die Lean Management lehrt ist, das Ganze zu optimieren. Dazu geh\u00f6rt es, kurze und effektive feedback-Schleifen zu etablieren, die eine kontinuierliche und dezentrale Entstehung und Verbesserung erm\u00f6glichen. Der nat\u00fcrlich iterative Evolutionsprozess gilt gleicherma\u00dfen in beiden Bereichen; dem Software- und System-Engineering. Im Geiste des Lean Management gilt es, drei wesentliche Punkte in einer Continous Delivery zu implementieren: Feedback, Learning, Flow!<\/p>\n","protected":false},"excerpt":{"rendered":"
Es ist gesch\u00e4ftskritisch die Durchlaufzeit von \u00c4nderungen an Software zu reduzieren um eine neue Version so schnell wie m\u00f6glich in ein funktionierendes System zu wandeln. W\u00e4hrend manche Unternehmen sich heute noch Zykluszeiten von mehreren Monaten erlauben, bringen andere schon mehrfach t\u00e4glich eine neue Version in Produktion. Zur Verk\u00fcrzung der cycle-time und zur Reduktion des Release-Risikos […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/posts\/829"}],"collection":[{"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/comments?post=829"}],"version-history":[{"count":13,"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/posts\/829\/revisions"}],"predecessor-version":[{"id":3647,"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/posts\/829\/revisions\/3647"}],"wp:attachment":[{"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/media?parent=829"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/categories?post=829"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cabp.de\/index.php\/wp-json\/wp\/v2\/tags?post=829"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}