Wenn wir über traditionelles Testen sprechen, meinen wir das V-Modell, das in Wasserfall-Projekten verwendet wird. Wir betreiben Requirements Engineering, schreiben Features für unsere Software nieder, brechen diese dann herunter und schreiben Stories, die anschliessend den Entwicklern zur Umsetzung übergeben werden. Der Entwickler setzt dies in Code um und schreibt dann Unit Tests und Integrationstests.
Ich habe 9 Arten von Verschwendung 🗑 in der Softwareentwicklung identifiziert:
🧩Unfertige Arbeit
💲Überflüssige Features
😤Unnötige Prozesse
🤯Task-Wechsel
🧟♀️Nicht-standardisierte Arbeit
Welche Arten von Verschwendung hast du identifiziert?
Der “Erfinder” des Wasserfall-Prozesses 💧 sagte 1970: “I believe in this concept, but the implementation described above is risky and invites failure.” 😱
Was wird DevOps 2021 wirklich bewegen? Nach einem Jahr, das fast jede Organisation gezwungen hat, Digital Delivery zu beschleunigen, sind die Trends für 2021 weniger glänzende neue Tools, sondern Disziplin: DevOps im grossen Stil zum Funktionieren bringen, Security nach links verschieben, Continuous Delivery ernst nehmen, weiter in die Cloud gehen — und die ersten Signale von AIOps beobachten.
Waterfall und Agile sind nicht einfach zwei Geschmacksrichtungen von Projektmanagement. Es sind zwei grundlegend verschiedene Arten, mit Unsicherheit umzugehen. Wer das versteht, versteht den Rest fast von selbst.
Waterfall: Linear und sequenziell # Waterfall ist ein linearer, sequenzieller Lebenszyklus. Das Team geht erst in die nächste Phase, wenn die vorherige erfolgreich abgeschlossen ist. Zuerst Anforderungen, dann Design, dann Implementierung, dann Test, dann Deployment, dann Betrieb. Jede Phase hat eine Übergabe und eine Freigabe. Jede Phase erzeugt ein Dokument, das die nächste Phase konsumiert.
Der dritte Weg, DevOps einzuführen, besteht darin, eine Vertrauenskultur zu schaffen, die Experimente und Risikobereitschaft trägt. Das ist der Third Way im Three-Ways-Framework von Gene Kim — und er bringt das Team auf eine Lernkurve, die steil genug ist, um die Konkurrenz hinter sich zu lassen.
Der zweite Weg, DevOps einzuführen, ist ein starker Feedback-Fluss in die Gegenrichtung des Value Flows — vom Kunden und aus der Produktion zurück ins Business und ins Development. Das ist der Second Way im Three-Ways-Framework von Gene Kim, und er verhindert, dass der First Way im Blindflug optimiert.
Der erste Weg, DevOps einzuführen, besteht darin, den Value Flow von Development über Operations bis zum Kunden zu optimieren. Das ist der First Way im Three-Ways-Framework von Gene Kim — und genau dort sollte jede Transformation starten.
Continuous Deployment ist der finale, aggressivste Schritt in der CI/CD-Progression. CI beweist, dass der Code baut und die Unit Tests grün sind. Continuous Delivery beweist, dass das Artefakt in einer produktionsähnlichen Umgebung funktioniert. Continuous Deployment entfernt den letzten manuellen Checkpoint: Wenn alle Tests auf dem Weg grün sind, geht die Änderung direkt in Produktion. Kein “Deploy”-Button, kein Freitagnachmittag-Release-Fenster, kein Mensch im Loop für den letzten Schritt.
Continuous Integration endet mit einem getesteten Artefakt. Das klingt gut, aber ein grüner Build heisst nicht, dass die Software in einer realistischen Umgebung tatsächlich funktioniert. Unit Tests laufen isoliert. Integrationstests laufen gegen Mocks. Solange man die Software nicht irgendwo hinstellt, das aussieht wie Produktion, und sie unter echten Bedingungen ausführt, hat man eigentlich noch nichts bewiesen. Continuous Delivery ist der Schritt, der diese Lücke schliesst.
In der traditionellen Softwareentwicklung wird Software von allen Entwicklern in einem grossen einzigen Integrationsschritt zusammengeführt und getestet, der in der Regel Wochen oder gar Monate dauert. Da dies nur alle paar Monate passiert, ist dieser Schritt sehr zeitaufwändig.
In der klassischen Softwareentwicklung war Integration ein einziges, schmerzhaftes Ereignis. Jeder Entwickler arbeitete wochen- oder monatelang isoliert, und am Ende wurde alles in einem grossen Big Bang zusammengeführt. Dieser Integrationsschritt dauerte Wochen, manchmal Monate. Konflikte häuften sich an, Bugs versteckten sich in den Nahtstellen zwischen Modulen, und niemand konnte mit Sicherheit sagen, ob das System tatsächlich funktionierte. Continuous Integration wurde erfunden, um genau diesen Schmerz aufzulösen.
