Continious Delivery (CD)
Nach der Folge über Continious Integration müssen wir die Kette mit Continious Deployment und Continious Delivery (CD) natürlich weiter betrachten. Quasi eine CI CD CD Chain. 😀
Diese Folge auf YouTube: https://youtu.be/c_wrVAJcHhE
Worum geht es heute?
Wir setzen fort, was wir letzte Woche begonnen haben. Continious Delivery ist unter anderem auch Bestandteil von Psychologischer Sicherheit. Wir reden dort im organisatorischen Modul über Psychologische Sicherheit. Also darüber, wie wir durch kontinuierliches Liefern eine vertraute und sichere Umgebung schaffen können, die sich positiv auf die Transformationsprozesse im Unternehmen auswirkt.
Gleichzeitig steht dies auch im Agilen Manifest für Softwareentwicklung. Häää? Wo?
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Principles behind the Agile Manifesto
Sind Continious Delivery & Continious Deployment das gleiche?
Continious Delivery geht, wie der Name schon sagt, davon aus, dass kontinuierlich geliefert wird. Was auch immer kontinuierlich ist. Also jeden Monat, jede Woche oder täglich.
Da das Deployment auch das Verteilen der Software ist, könnte sich Henry Schneider gut vorstellen diese Begriffe daher synonym zu verwenden. Janina Kappelhoff ist da zu Recht anderer Meinung.
Henrys Meinung beruhte darauf, dass in der Softwareentwicklung auch automatisch das Deployment einer Verteilung/Auslieferung entspricht. Beispielsweise wenn sich Deine Betriebssysteme automatisch das neueste Update ziehen. In der Hardware ist dem dafür nicht immer so. Also wenn es eine neuere Reifenversion gibt, so werden nicht automatisch alle Autos damit ausgestattet. Auch konntest Du in der Release BurnDown Folge lernen, dass sehr wohl die Product Ownerin dafür zuständig ist zu planen, was von den vielen Features wann in welches Release kommt und damit ausgeliefert wird. Das Deployment ist somit eine Vorstufe vom Delivery.
Der Gegenpol dazu ist, dass ein Produkt einmal so gekauft wird und dann bis zum Lebensende genau in diesem Zustand bleibt. Bei Mobiltelefonen war dies beispielsweise in der Vergangenheit so. Oder Betriebssysteme. Einmal gekauft und keine Updates mehr dafür.
Vor & Nachteile von Continious Delivery
Vorteile:
- Ständig die neuesten Features
- Kleine Häppchen
- Leicht an neue Features gewöhnen
- Fehler lassen sich schnell abstellen
Nachteile:
- Ständige Veränderung – wenig Verlässlichkeit, dass ein Produkt morgen noch so funktioniert, wie heute
- Viel Aufwand um das Produkt darauf vorzubereiten
- Viel Automatisierung nötig
Unterschiede zwischen Continious Delivery & Continious Deployment
Wie bereits erwähnt ist das Deployment ein Zwischenschritt vor dem Delivery. In guter Softwareentwicklung haben wir beispielsweise mehrere Instanzen unserer Umgebung. Beispielsweise, Entwicklung, Test, Produktiv. Auf jede Instanz wird nacheinander deployed, wenn die jeweiligen Tests positiv abgeschlossen wurden. Hier gibt es auch mehrere Integrationsschritte.
Beim Continious Deployment landet vielleicht das erste Mal die Software auf der neuen Hardware und wird dort getestet. Erst wenn dieser Test erfolgreich war, dann geht es ins Delivery und landet auf der Kundenhardware.
Wir haben also mehrere Sicherheitsnetze in unserer Entwicklung und das ist das, was Janina mit einem Aspekt der Psychologischen Sicherheit meint. 😉
Auf diese Instanzen kann ich auch verschiedene Nutzergruppen freischalten. Beispielsweise speilt Tesla Updates zuerst auf Autos rund um deren Werke ein um eventuelle Liegenbleiber schnell erreichen und reparieren zu können.
Pakete schnüren
Kommt es nun zum Delivery, so ist es die klassische Product Ownerinnen Aufgabe, genau diese Pakete zu schnüren. Also welche Features kommen wann zum Kunden?
Hier ist vor allem die Abwägung gefragt, wann man eine Kundin vielleicht sogar mit den vielen Änderungen überfordert. Darauf zu achten scheint uns bei der Znip Academy auch von vielen anderen Agilisten abzugrenzen, wo eher die Haltung zu sein scheint „alles schnell, schnell“. Das schnelle Liefern kann auch andere Unternehmensbereiche, vor allem wenn sie noch nicht Agil sind, überfordern.
Feedback
Continious Delivery bedeutet auch, dass wir entsprechende Feebdack-Schleifen installieren dürfen. Das funktioniert natürlich am besten mit DevOps Team oder in Frameworks wie eXtreme Programming.
Dadurch entsteht Flow. Gleichzeitig dürfen wir einen Takt finden, den alle kontinuierlich einhalten können.
Was braucht es dafür?
Es braucht auf jeden Fall eine vernünftige Toolchain für CI/CD. Wir haben bisher gute Erfahrungen mit Jenkins und Atlassian gemacht.
An der Stelle geht es zudem richtig viel um Automatisieren. Es muss alles, was nach dem Coden kommt, wegautomatisiert werden. Inklusive Entwicklerdokumentation, diese muss sich aus den Kommentaren im Code ergeben.
Das beinhaltet auch Testautomatisierung. Hinter dieser liegen vernünftige Definition of Dones und Codingrules.
Zusätzlich braucht es ein sehr stabiles Team dafür um auf dieses Level zu kommen. Dabei helfen Dir auch die engen Feedback-Loops, die es sowieso braucht.
SlackTime ist ein klasse Antreiber für dieses Thema.
Praxisbeispiele
Bordhandbücher für Autos können aus den CAD und Kinematikdaten automatisiert erstellt werden. Also nicht nur in der Software. 🙂 Ändern wir nun ein Teil, so werden automatisch in die Bordbücher für die neuen Autos neue Bilder eingefügt. So können wir auch Varianz in Bordbüchern abbilden. Hat Dein Auto keine Sitzheizung, wozu die Bedienung dann im Handbuch beschreiben?
Auch Lamborghini arbeitet mit Rapid Prototyping, so dass Konstruktionsänderungen direkt ausgedruckt und ausprobiert werden. Ersatzteile, auch in neueren Versionen, ließen sich so auch in der Werkstatt leicht herstellen.
All das lässt sich auch auf Firmenprozesse anwenden. Wie funktioniert bei Dir die Dienstreisebuchung? Was wäre, wenn während an dem Prozess gearbeitet wird Du die Teilstücke bereits benutzen könntest? Letzte Woche war es noch deutlich umständlicher, ein Papierformular dafür auszufüllen. Diese Woche geht es halbautomatisch. Nächste Woche werden Hotels automatisch angefragt, wenn die Dienstreise über meherere Tage geht.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Continious Integration
- Release BurnDown
- Product Ownerin
- Agilität
- Flow
- Definition of Dones
- SlackTime
- Teams
Connecte dich gerne hier mit uns:
