Das Hauptproblem bei Workflow-Basierten Deployment-Lösungen besteht hauptsächlich darin, dass damit jedes Deployment einzigartig ist und jede Änderung der Anwendung (z.B. wenn neue Komponenten hinzukommen) eine Änderung des Workflows bedingt. Dieser muss dann zusammen mit vorhandenen Umgebungskonfigurationen jedes Mal manuell angepasst werden. Außerdem müssen häufig zwei Workflows gepflegt werden, einer für das Roll-Out und einer für das Roll-Back. Die Maintenance über einen längeren Zeitraum ist mit Workflow-basierten Systemen eine Herausforderung, derer die meisten IT-Organisationen nicht gewachsen sind.
Eine Lösung, die sehr häufig in der IT (und nicht nur da) für dieses Problem angewendet wird, sind Abstraktionen des Problem- und Lösungsraums auf eine höhere Ebene. Beispiele dafür sind Assembler vs. Hochsprachen, Provisionierung mit Puppet/Chef/Ansible vs. handgebauter Provisionierungsskripte oder ein Container-Scheduler (Kubernetes, OpenShift) statt expliziter Orchestrierung.
Skills
Grundkenntnisse in Application Development, Deployment und Betrieb und Infrastrukturen
Lernziele
* Wie würde es aussehen, wenn man dieses Paradigma auf das Applikationsdeployment übertragen würde?
* Welche Vorteile hat das?
* Worauf muss man achten?
* Was heißt das konkret für die unterschiedlichen Zielsystem – vom SharePoint über Jave EE App-Server bis hin zu Docker, Cloud und Serverless-Applikationen?
Referent
Matthias Ziegerist seit mehr als 20 Jahren in der IT-Industrie unterwegs mit den Themen Software-Entwicklung, Architektur, Application Lifecycle Management und DevOps u.a. für IBM, Borland, Microsoft und codecentric.,Die letzten drei Jahre hilft er großen Unternehmen, ihre Software schneller in Produktion zu bringen mit den Releasemanagement- und Deploymentlösungen von XebiaLabs – von klassischen Java-EE-Umgebungen über Docker und Cloud bis hin zu Serverless-Architekturen.