136 Continious Delivery (CD)

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,


Janina & Henry


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


Janinas Ultimativer OKR Guide


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:


LinkedIn


Instagram


YouTube


Facebook


Znip Academy, Deine Akademie für Agilität und Scrum


Facebook-Gruppe


The post 136 Continious Delivery (CD) appeared first on Znipcast
- für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.