IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Software-Entwicklung 4.0 – Merry DevOps Christmas

Kategorie: Trends des Monats

Alle Jahre wieder ....

Eigentlich sollte das Thema DevOps schon längst in den Unternehmen etabliert sein – schließlich kennt jedes Kind die Nachteile jährlicher Geschenk-Releases zu Weihnachten. Über Wochen und Monate, schon bevor die ersten Lebkuchen in den Supermärkten liegen, wird intensives Requirements-Engineering betrieben. Das Backlog in Form einer detaillierten Wunschliste wird angelegt und während der Vorweihnachtszeit die Priorisierung mehrmals überarbeitet. Bereits im November hat der Umfang des Wunschbacklogs das vorhandene Budget längst gesprengt und die Suche nach weiteren Budgettöpfen beginnt.

Die Spannung bei den Kindern steigt, denn das große Release kommt immer näher. Aber die entscheidende Frage vor Weihnachten bleibt: Werden die Wunschfeatures dabei sein und die Erwartungen erfüllen. Beim großen Weihnachtsrelease darf nichts schiefgehen, sonst ist die Enttäuschung groß. In vielen Fällen droht dann der Rollback: der Umtausch ungewünschter Geschenke.

Liegt der Reiz am Weihnachtsfest gerade für Kinder genau in dieser Spannung, ist diese im Rahmen der Softwareentwicklung unnötig. Das Risiko jährlicher oder auch halbjährlicher Releases liegt auf der Hand: Der Rollout ist durch die vielen Abhängigkeiten eine komplexe, schwer planbare Aufgabe, zudem dauert es dadurch sehr lange, bis die Anwender von neuen Features profitieren können.

Da die Produktions-Deployments so selten durchgeführt werden, ist der entsprechende Prozess zwar formal definiert, aber nur selten etabliert und von allen Mitarbeitern verinnerlicht. Dies zeigt sich insbesondere, wenn Entwicklung und Betrieb zur Inbetriebnahme zusammenarbeiten müssen und nach langer Zeit wieder ein Team auf Zeit bilden. Ein Fußballreporter würde es vermutlich wie folgt kommentieren: „Das Team hat in dieser Besetzung noch keine Erfahrung. Die Laufwege und Automatismen sind noch nicht eingeschliffen“.

If it hurts, do it more frequently

Wenn ein Produktionsrelease schwerfällt und Probleme verursacht, liegt die Lösung nicht in der Steigerung des Aufwands für die Release-Vorbereitung, sondern vielmehr in der drastischen Reduktion der Release-Zyklen. Der Trainer einer nicht eingespielten Fußballmannschaft wird seinen Spielern auch nicht individuelles Konditionstraining verordnen, sondern versuchen, dem Team die gemeinsame Spielpraxis zu ermöglichen.

Eine Reduktion der Release-Zyklen bietet daher zwei wesentliche Vorteile. Zum einen reduzieren regelmäßige Releases die Komplexität, da Inhalt und Abhängigkeiten der einzelnen Artefakte besser verstanden werden. Zudem bietet sich die Möglichkeit, den Prozess in kleineren Schritten kontinuierlich zu optimieren, bis das Release ein völlig unproblematisches gewöhnliches Ereignis wird. Zum anderen wird das Time-to-Market für neue Features deutlich reduziert. Entwicklungsaufwände machen sich so schneller bezahlt und auf Kundenwünsche kann deutlich schneller reagiert werden.

DevOps erfordert einen strukturellen und kulturellen Wandel

Umso häufiger Entwicklung und Betrieb nun zusammenarbeiten, desto auffälliger und schmerzhafter werden mangelhafte Abläufe und Defizite in der Zusammenarbeit. Um den Entwicklungsprozess entlang der gesamten Wertschöpfungskette von der Anforderung bis hin zur Auslieferung zu optimieren, müssen etablierte Strukturen hinterfragt und angepasst werden.

Die strukturelle Aufstellung einer DevOps -Organisation ist allein schon durch den Namen, der eine Integration von Dev & Ops beschreibt, meist im Mittelpunkt der ersten Überlegungen einer DevOps-Initiative. Bevor aber die Teams neu organisiert werden, sollte zunächst der End-to-End Prozess analysiert und bewertet werden , damit auf Basis dieser Ergebnisse kleine Veränderungen implementiert werden können. Operations-Mitarbeiter fest in das Entwicklungsteam zu integrieren, ist dabei oft nicht erforderlich.

Konsequente Automation bringt Geschwindigkeit und Konsistenz

Da wiederkehrende Aktivitäten fehlerfrei und schnell durchgeführt werden müssen, ist die Automation des gesamten Deployments ein wesentliches Element jeglicher DevOps-Initiative. Die Deployment-Pipeline beschreibt alle manuellen und automatisierten Aktivitäten, die ein neues Feature bis zur Produktion durchlaufen muss.

Manuelles Testen skaliert mit einer steigenden Zahl an Releases nicht. Die Teststrategie muss konsequent neu definiert werden. Der naheliegende Weg ist hier die Automation der Testfälle. Nun einfach die vorhandene Testsuite komplett zu automatisieren, ist sehr teuer und auch nicht empfehlenswert. Vielmehr ist es wichtig, die vorhandenen Testfälle zu bewerten und den Fokus der Testautomation auf Features zu legen, die einen hohen Geschäftsnutzen liefern und ein hohes Risiko haben, Fehler zu beinhalten.

Die initial zu automatisierende Testsuite muss die kritischen Anwendungsfälle absichern und iterativ entlang der Entwicklungssprints erweitert werden. Sollten manuelle Testfälle nach wie vor notwendig sein, können diese oft auch nach der Inbetriebnahme direkt im Produktivsystem getestet werden. Schließlich ist es durch die schnelle Deployment-Pipeline auch im Fehlerfall möglich, einen Bugfix durch den Regelprozess schnell produktiv zu setzen. Der weitere Ausbau der Testautomatisierung erfolgt sinnvollerweise dann gleich als Teil der Entwicklungssprints.

Nichtfunktionale Tests müssen auch bei DevOps die üblichen Quality Gates durchlaufen. Im klassischen Vorgehen werden hierfür oft mehrere Wochen benötigt. Um schnelle Release-Zyklen zu erreichen, müssen also auch Performance-Tests, Security-Checks und statische Codeanalysen konsequent automatisiert werden. Die wesentliche Herausforderung ist hierbei die Integration und Anpassung der IT Service Management Prozesse, da diese in der Regel nicht auf diesen Durchsatz an Releases ausgerichtet sind.

Fail fast, Fail cheap

Startups und erfolgreiche Innovatoren zeigen, dass Innovation häufig kein langfristig geplanter Siegeszug einer einzigen genialen Idee ist. Vielmehr entsteht Innovation durch ein ständiges Testen und Optimieren verschiedener guter Ideen am Markt. Dabei ist es entscheidend, neue Ideen durch minimale Prototypen sehr schnell und kostengünstig zu validieren. Durch das Feedback des Marktes wird dann entweder fokussiert weiterentwickelt oder die Idee verworfen. Je schneller dieser qualifizierte Regelkreis funktioniert, desto geringer ist das Invest in nicht marktfähige Features. So können mehr Ideen mit demselben Budget getestet werden. Während das Ziel der Risikoreduktion des Deployment-Prozesses meist auch mit monatlichen Releases erreichbar ist, lässt sich ein Wettbewerbsvorteil durch differenzierende Funktionalitäten mit diesem Rhythmus oft nicht nachhaltig realisieren. Um auch mehrmals am Tag neue Features dem Kunden zugänglich zu machen bedarf es einer leistungsfähigen, hochoptimierten Deployment-Pipeline. DevOps ist somit der Innovationsmotor für Softwareprodukte im digitalen Zeitalter.

DevOps für entspannte Weihnachtstage

DevOps ist nicht nur ein Mittel, die Weihnachtstage entspannt zu verbringen, auch wenn das nächste Release bereits vor der Tür steht, sondern auch einer der vier Schlüssel zur Steigerung ihrer Innovationsgeschwindigkeit mittels Software-Entwicklung 4.0. Es freut mich aktuell zu sehen, wie auf dieser Basis nicht nur Startups, sondern Unternehmen aller Art daran arbeiten, die Agilität ihrer Gesamtorganisation drastisch zu steigern.

 Aus diesem Grunde empfehle ich auch die anderen Blogs zu dieser Serie:

·         Software-Entwicklung 4.0 am 20. Nov.

·         Microservices am 3. Dez.

·         Agile am 11. Dez.

·         Cloud am 18. Dez.

Über den Autor

Marc Bauer
Marc Bauer
Marc Bauer ist Solution Architect und Professional Scrum Trainer der scrum.org. Als überzeugter Agilist unterstützt er Unternehmen in der agilen Transformation ihrer Software-Entwicklungsprozesse.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.