Die Konkurrenz ist groß, jeder will beim Ausliefern der Software der schnellste sein. Warum wir dabei auf DevOps setzen? Das sind die Argumente.

Früher war ganz klar, wer was macht. Die Entwicklungsabteilung (Dev) entwickelt, die Qualitätssicherung (QA) testet und der Betrieb (Ops) installiert und monitort die Applikationen. Es wurde drei Monate entwickelt, einen Monat lang getestet, Bugs gefixt und dann nachts mit Downtime das Deployment in die Produktion ausgerollt. Der Prozess für Bugfixes war über Change Requests und Tickets sehr mühsam und langwierig. Mit der Zeit stiegen die Anforderungen des Produktmanagements an die schnelle Bereitstellung von Features. Viermal im Jahr war in den 2000ern nicht mehr zeitgemäß. Die Konkurrenz wurde im digitalen Zeitalter zu groß und jeder war bemüht, schneller zu liefern. Wie kann man nun die Abteilungen besser zusammenbringen und die Prozesse optimieren? Die Antwort darauf ist DevOps – und ein Umbau der Gewaltenteilung sowie eine Änderung des Mindsets.

Die Transformation kann in mehreren Schritten erfolgen. Wurde früher alles über den Zaun geworfen, ist jetzt eine klare Definition davon unerlässlich, was von der Entwicklung gefordert wird. Das können Artefakte wie RPM-Installer-Pakete, VM-Images oder Docker-Container mit der passenden Konfiguration sein. Die Entwicklung muss sich mehr (Operations-)Wissen aneignen und es anwenden. Das hat den Vorteil, dass mehr Wissen und Verantwortung zusätzlich motiviert. Um das zu erreichen, ist eine vollautomatisierte Continuous Integration des Sourcecodes eine notwendige Voraussetzung. Mit dem weiterführenden Continuous Deployment geht auch oft eine Aufsplittung eines vorher bestehenden Monolithen zu einer Microservices-Umgebung einher, um schneller und risikofreier Features zu deployen. Hier gilt: Je kleiner die Änderung und je schneller das Deployment, umso weniger Risiko und umso schneller das Feedback. Genau dieses führt spätestens das erste Mal zu Schmerzen. Der Betrieb ist nicht mehr in der Lage, alle neuen Mikroartefakte zeitnah zu deployen. Automatisierung dieser Prozesse und mehr Verantwortungsübernahme der Entwickler ist die logische Schlussfolgerung. Beide Seiten mit ihrem Expertenwissen können so die Continuous-Delivery-Pipelines und Deployments optimieren. In einem weiteren Schritt wird sich auch die Rolle der Quality-Assurance-Abteilung wandeln: von der „Wir testen alles vor dem Livegang“-Abteilung hin zu einer beratenden Rolle und übergreifenden Qualitätssicherung...