In dieser Episode diskutieren Luca Ingianni und Falko Werner die Nuancen der Implementierung von Continuous Delivery unter schwierigen Bedingungen und heben die Bedeutung von Pragmatismus und Anpassung an spezifische Umstände hervor. Sie erkunden, wie Continuous Delivery in verschiedenen Kontexten, von einfachen Softwareanwendungen bis hin zu komplexen, hardware-einbeziehenden Systemen, angewendet werden kann. Das Gespräch berührt auch kulturelle und organisatorische Barrieren, die Bedeutung von Automatisierung im Lieferprozess und die Notwendigkeit, eine robuste Pipeline zu schaffen, die schnelle Iteration und Feedback unterstützt.
Inhalt
- Einführung in Continuous Delivery in herausfordernden Umgebungen
- Die Beziehung zwischen Continuous Delivery und DevOps
- Technische und organisatorische Aspekte von Continuous Delivery
- Pragmatische Ansätze für Continuous Delivery in verschiedenen Kontexten
- Umgang mit komplexen Softwareprodukten in Continuous Delivery
- Überwindung kultureller und organisatorischer Barrieren
- Die Rolle von Automatisierung und Pipelines in Continuous Delivery
- Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment
- Fallstudien und praktische Beispiele für Herausforderungen bei Continuous Delivery
- Continuous Delivery in hardware-einbeziehenden und cyber-physischen Systemen
- Strategien für den kleinen Anfang und Skalierung in Continuous Delivery
- Die Bedeutung von Feedback-Schleifen und schneller Iteration in Continuous Delivery
Shownotes
MinimumCD
Mehr lernen? Hier findet Ihr unser Trainingsprogramm
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Dirk ist nach wie vor im Urlaub.
Insofern haben Falko und ich uns gedacht,
wir nehmen heute eine Folge auf zum Thema
Continuous Delivery unter erschwerten Bedingungen.
Mit anderen Worten zum Gast haben wir uns selber.
Hallo Falko.
Hallo Luca, schön von dir zu hören.
Ich dachte mir, statt uns selbst vorzustellen,
vielleicht ist es ganz gut und an der Zeit,
dass wir einfach die Zeit,
die wir hier im Podcast nutzen, um ein bisschen über Vempio zu reden.
Wir sind ja gerade dabei, Vempio als Gesellschaft zu gründen,
zu zweit mit enger Zusammenarbeit,
weiter auch mit Dirk Ideen gemeinsam umzusetzen und daran zu arbeiten.
Fällt dir etwas ein, was wir vielleicht an der Stelle noch erwähnen sollten?
Vieles, vieles.
Aber ich glaube, das Wichtige ist erstens,
es ändert sich erstens mal gar nichts und wenn doch,
dann nur zum Guten oder zum Besseren.
Genau, also Falko und ich sind dabei,
Vempio zu gründen und wir arbeiten weiterhin sehr,
sehr eng und eifrig mit Dirk und auch mit Peter Lehmann zusammen.
Und wir haben auch schon einige neue Trainings auf der Pfanne,
die wir dieses Jahr neu entwickeln wollen.
Und abgesehen davon sind wir auch dabei, momentan sehr fleißig offene Trainings
in Zusammenarbeit mit der DASA,
der DevOps Agile Skills Association, ins Leben zu rufen.
Die könnt ihr entweder bei uns auf der Webseite finden
oder im
Trainingskalender der DASA.
Das verlinken wir euch alles in den Shownotes für den Fall,
dass das jemanden gerade interessieren würde.
Cool.
Normalerweise fragen wir unsere Gäste traditionell nach ihrer persönlichen
Definition von DevOps.
Das haben wir hier für uns in unseren Folgen auch schon öfter gemacht.
Also ich denke, wer das möchte, kann auch in den früheren Folgen einfach mal schauen,
was wir zu DevOps gesagt haben.
Aber da das Thema ja heute Continuous Delivery ist,
ist es natürlich nicht verkehrt, uns mit diesem Thema auseinanderzusetzen.
Deswegen an dich die Frage, Luca, was ist Continuous Delivery aus deiner Sicht?
Genau.
Also was ist meine Definition von Continuous Delivery?
Für mich ist das die sehr häufige oder gern auch sehr, sehr häufige,
hoch bis voll automatisierte Bereitstellung von Produktinkrementen an das Business,
wie man so schön und so nebulös sagt.
Sprich nicht an den Kunden, sondern erst mal nur an jene Teile der Organisation,
die sich an den Kunden richten.
Und neue Produktinkrementen werden also erzeugt und stehen dann zur Verfügung,
um die, wenn man möchte, auszuprobieren, um die, wenn man möchte,
vielleicht einem Kunden herzuzeigen oder auch, wenn man das möchte,
die ganz konkret in die Produktion auszuliefern und tatsächlich wertschöpfend zu nutzen.
Diese Entscheidung obliegt völlig diesem nebulösen Business.
Das ist also keine technische Entscheidung mehr,
wann man eine neue Produktversion tatsächlich produktiv setzt,
sondern das ist jetzt wirklich einfach eine vollkommen wertgetriebene Entscheidung.
Mit anderen Worten,
Continuous Delivery ist aus meiner Sicht zwar ganz grundsätzlich eine technische Praktik.
Wir reden von, ich weiß nicht, Automation und Pipelines und all so ein Zeug.
Aber die eigentliche Wirkung entfaltet sich auf anderer Ebene.
Die entfaltet sich auf einer Prozessebene.
Wann tritt eigentlich wer mit wem und warum in den Dialog?
Am besten natürlich mit dem Kunden.
Falco, wie siehst du das?
Ja, ich stimme dir im großen Teil zu.
Also für mich ist es auch als Praktik zu verstehen.
Mir geht es dabei darum, sicherzustellen,
dass die Änderungen an der Funktionalität oder Konfiguration von Systemen
möglichst wenig manuellen Aufwand beinhalten.
Das heißt, dass man da mit Tool-Unterstützung, mit Pipelines arbeitet,
die viele aufeinanderfolgende Aufgaben, die man sonst manuell ausführen würde,
automatisiert durchführen.
Das kann von den Schritten aus dem Continuous Integration sein.
Letztendlich alles, was nach dem Code Review, nach dem Vier-Augen-Prinzip aus
der Entwicklung passiert, bis hin zu mindestens einer Pre-Life- oder QS-Umgebung,
die dann letztendlich die Übergabe an die Fachbereiche des Businesses,
wie du vorhin sagtest, gehen.
Theoretisch können sie auch bis in die Produktivumgebung gehen.
Spricht aus meiner Sicht auch nicht viel dagegen.
Wenn man dann mit Techniken arbeitet wie Feature-Flagging und anderem,
dann sind wir aber schon stark an der Grenze von Continuous Delivery,
zu Continuous Deployment.
Das ist quasi unser nächster Themenpunkt.
Lass uns doch da am besten gleich weitergehen.
Was gibt es denn in dem Umfeld von Continuous Delivery zu beachten?
Was gibt es da noch so?
Ich kann Continuous Integration, Continuous Delivery, Continuous Deployment,
wollen wir das einfach nochmal abgrenzen, damit allen klar ist, worum es uns hier geht?
Ja, das halte ich für eine gute Idee.
Insbesondere, weil die Definitionen ja doch so ein bisschen schwammig sind.
Und es mag auch den einen oder anderen,
oder anderen geben übrigens, der unsere Definitionen nicht teilt.
Das ist ja auch völlig okay, sondern wir erklären einfach mal,
was wir darunter verstehen.
Dann weiß jeder, woran er ist.
Und darf uns dann gerne irgendwie für doof halten
und seine eigene Definition weiter nutzen.
Genau, und darf sich auch gerne bei uns melden.
Und dann können wir auch gerne auch im Podcast darüber mal mit der oder demjenigen reden.
Auch das ist eine ausgezeichnete Idee.
Genau.
Gut, also was ist denn dann Continuous Integration, Falco?
Gut.
Also für mich ist Continuous Integration der erste Schritt einer Continuous Delivery Pipeline
mit dem Fokus darauf, alles zu tun, was nach dem Pair Programming passiert.
Das heißt, dem Merge von neuen Code-Bestandteilen, Konfigurationsbestandteilen,
dass man einen Bildprozess abbildet, dass man Testprozesse soweit abbildet,
die mindestens Unit-Tests abdecken auf einer Entwicklungs- oder Testumgebung,
die sehr entwicklernah ist, die letztendlich auch eine statische Code-Analyse beinhaltet,
und erste dynamische Tests.
Fehlt da für dich noch irgendwas?
Sollten wir da noch was ergänzen?
Oder passt die Beschreibung von Continuous Integration für dich?
Die Beschreibung passt für mich.
Es gibt bloß eine Sache, auf die es mir immer wichtig hinzuweisen,
nämlich, wenn du Continuous Integration jetzt wirklich beim Wort nimmst,
dann lässt du da jetzt diese Pipeline laufen und die macht da irgendwie Dinge
und produziert Artefakte und unterzieht die Tests.
Und was passiert hinterher?
Mit den Artefakten, du schmeißt sie weg.
Weil dir geht es ja gar nicht um die Artefakte,
sondern es geht dir um das Feedback, das du draus ziehst.
Waren alle Tests grün?
War die statische Code-Analyse erfolgreich?
Und so weiter und so weiter.
Das Artefakt selber, wenn man es jetzt wirklich beim Wort nimmt,
verpufft einfach hinterher wieder.
Das ist dann einfach, das ist eigentlich nicht wesentlich.
Das ist nicht wesentlich, aber letztendlich brauchst du es ja doch,
um es dann irgendwann ausliefern zu können, oder nicht?
Ja, aber das machst du ja bei Continuous Integration.
Nein, bei Continuous Integration noch gar nicht.
Sondern dann sind wir eben genau beim nächsten Schritt.
Dann sind wir bei Continuous Delivery.
Weil dann sagen die Leute, ja, das ist ja irgendwie dumm.
Jetzt habe ich mir doch extra so ein schönes neues Inkrement gebaut
und habe das getestet und habe festgestellt, das geht.
Dann wäre das doch irgendwie Verschwendung, das jetzt wegzuschmeißen.
Und dann war die eine andere Antwort zu sagen, ja, dann heb es doch auf.
Und was mache ich dann? Und wie mache ich das am besten, das Aufheben?
Das ist eine gute Frage.
Also das kann man ganz verschieden handhaben.
Das hängt ja auch immer damit zusammen, was ist denn eigentlich dein Artefakt?
Ist das jetzt irgendwie nur ein Softwarepaket oder ist das ein Atomkraftwerk?
Oder wovon reden wir denn hier?
Aber ich sage jetzt mal, der einfachste Fall ist,
dass dann einfach hinten aus deiner Pipeline, aus deinem Jenkins oder was auch immer,
hinten ein Programmpaket rausfällt, ein Binary rausfällt
und das plumpst dann einfach mal in irgendein Netzwerkverzeichnis rein oder so.
Und das war es dann vielleicht schon.
Das ist jetzt, würde ich mal sagen, die einfachste Ausbaustufe einer solchen Delivery.
Du legst dieses Artefakt einfach an einen vereinbarten Ort ab
und von dort kann es in beliebiger Weise weiterverwendet werden.
Und man kann sich dann natürlich beliebig verkünsteln
und es gibt ja Artifactory und alle möglichen anderen Werkzeuge,
die ganz spezifisch zur Artefaktverwaltung entwickelt wurden.
Die kann man natürlich auch einsetzen.
Gut. Wir sind jetzt gerade zwischen Continuous Integration und Delivery hin und her gewechselt.
Was ist denn der Kernpunkt von Continuous Delivery,
über das wir hier eigentlich vorrangig reden wollten?
Genau. Da ist dann eben, wie gesagt, der Witz dabei.
Ich habe jetzt mit Hilfe meiner Pipeline nachgewiesen,
dass dieses neue Inkrement irgendwie erstmal ganz grundsätzlich Hand und Fuß hat.
Die Tests sind grün, es gab eine statische Code-Analyse
und was weiß ich, was für Schritte da halt noch rein gehören aus eurer Sicht.
Und das habe ich jetzt abgelegt zur weiteren Verwendung.
Die weitere Verwendung wird bestimmt sein, dass man es dann staged auf einem Testsystem,
auf einem Präproduktionssystem, was auch immer einem da einfällt.
Ich bin auch da wieder so ein bisschen vage, weil es hängt einfach,
ganz stark davon ab, was passt denn zu euch, zu eurem Produkt, zu euren Kunden.
Was macht denn da Sinn?
Aber genau, man kann es dann aufwendiger in Tests unterziehen beispielsweise.
Man kann aber auch dann sagen, weißt du was,
ich will das jetzt wirklich in die Produktion deployen.
Und dann, glaube ich, sind wir eigentlich, ich sage mal, beim weitesten Schritt,
weil man kann ja auch die Vereinbarung treffen, weißt du was,
wenn immer was Neues delivered ist,
und es ist grün, alle Tests sind erfolgreich gelaufen und so weiter,
dann treffen wir die Vereinbarung, dass wir es auf der Stelle in die Produktion deployen.
Und dann sind wir bei Continuous Deployment.
Das ist also, ich sage es mal im Extremfall, der Entwickler entwickelt irgendwas,
checkt den neuen Code-Industry-Repository ein und dann ohne anhalten, ohne links und rechts schauen,
rauscht das durch die Pipeline durch, bis es auf den Produktionssystemen aufschlägt
und für den Kunden erreichbar ist.
Okay, und ist das nicht gefährlich, wenn dann einfach alles,
was da ein Entwickler tut, in der Produktionsumgebung landet?
Wenn der da einen Fehler macht, dann landet der da auch.
Ja, da darf er keine Fehler machen, ne?
Ne, aber ganz im Ernst, natürlich werden Fehler passieren,
aber zum einen ist das eine Frage des Vertrauens in eine Pipeline.
Sind deine Tests solide genug?
Ich meine, Hand aufs Herz, was passiert denn bei Continuous Delivery,
wo wir es erstmal irgendwie in ein Verzeichnis kippen,
was machst du denn zwischen, liegt in einem Verzeichnis und du deployst es wirklich?
Wirst du es dann nochmal akribisch auf Herz und Nieren prüfen oder sagst du,
naja, wird schon passen und knallst es dann halt manuell auf die Produktionsumgebung?
Das ist also das eine.
Und das andere ist, genauso schnell, wie du halt defekte Inkremente deployen kannst,
so schnell kannst du natürlich auch die Korrekturen deployen.
So schnell kannst du dann irgendwie einen Bugfix hinterher schieben
und du kannst dich sehr, sehr darauf verlassen,
dass dieses Bugfix-Deployment erfolgreich sein wird,
weil du deployst halt jeden Tag.
Weiß Gott, wie oft.
Diese Pipeline, die hört ja quasi gar nie auf zu arbeiten.
Und insofern ist es gar nicht so gefährlich,
wie es vielleicht auf den ersten Blick klingt.
Ich meine, das ist eine Frage, die ich häufig höre in meinen Trainings,
du wahrscheinlich auch, Falco.
Wer traut sich in das? Das ist ja mega gefährlich.
Eigentlich nicht.
Genau.
Und man kann natürlich da auch noch zwei, drei Dinge mit betrachten,
wo wir auch wieder in den Grenzbereich zwischen Continuous Delivery und Deployment,
wenn man dann mit Feature-Switches zum Beispiel arbeitet
oder über Berechtigungen oder andere Verfahren-Nutzern
diese neue Funktionalität, die vielleicht da gerade neu entwickelt worden ist,
noch gar nicht zur Verfügung stellt,
sondern halt sie erstmal nur dark auf ein Produktivsystem deployed
oder mit einer Alpha-Beta-Tester-Gruppe da arbeitet,
dann ist sie ja trotzdem produktiv,
aber die Gruppe kann darauf zugreifen,
aber noch nicht jeder Nutzer.
Deswegen wäre es auch nicht schlimm,
wenn da ein Bug oder ähnliches,
noch nicht gefunden worden ist aus den ganzen Tests,
die vorher automatisiert durchgelaufen sind.
Und natürlich ein weiterer positiver Effekt ist,
man kann diese Technologien auch nutzen,
um zum Beispiel unterschiedliche Benutzerverhalten dann gegeneinander abzuwägen
und ähnliches AB-Testing wäre dann wieder ein Vorteil.
Für mich ist ganz wichtig, Continuous Deployment muss nicht Release beinhalten.
Das ist eines der Learnings, die man auch auf SAFe immer wieder mitnimmt,
diese Trennung zwischen Deployment und Release,
dass man zwar produktiv deployt,
haben kann,
aber es noch nicht zwingend dem Endnutzer damit zur Verfügung stellt.
Zum Beispiel, wie gesagt, über Berechtigungssysteme,
über Feature Switches oder andere Mechanismen,
das Ganze dann zu kontrollieren.
Da sind dann Continuous Delivery und Continuous Deployment recht nah beieinander.
Klar ist eine neue Funktionalität dann Continuierlich Deployed.
Und das finde ich auch ganz wichtig darauf zu achten,
dieses Continuierlich.
Continuierlich heißt nicht unbedingt einmal alle Sekunde,
aber letztendlich mit,
im besten Fall jeder Code-Änderung,
wird halt ein neuer Build-Prozess angestoßen.
Und das kann dann halt, wie du auch sagtest,
mehrfach täglich, mehrfach stündlich, jede Minute passieren.
Je nachdem, wie das Gesamtsystem aufgebaut ist,
wie unabhängig vielleicht einzelne Komponenten voneinander sind,
können auch Teilkomponenten, Microservices,
sind da immer so die Dinge, über die man dann an der Stelle redet,
einzeln unabhängig voneinander deployed werden.
Und so kontinuierlich weiterentwickelt werden.
Genau. Und an der Stelle, wie gesagt,
das ist auch nochmal wichtig, glaube ich,
das hervorzuheben, was du ja auch schon gesagt hast.
Bloß weil ich jetzt mal angenommen jede Minute deploye,
heißt ja auch wirklich nicht,
dass ich jede Minute neue Funktionalität dem Anwender zur Verfügung stelle,
sondern es kann ja durchaus sein,
dass die noch hinter Feature Switches oder dergleichen mehr verborgen ist,
solange bis ich aufgrund anderer Erwägungen mich dazu entschließe zu sagen,
so, das wird jetzt scharf geschaltet,
das wird jetzt sichtbar.
Zum Beispiel einfach nur,
um meine armen Nutzer nicht völlig irre zu machen,
weil alle Nase lang schaut mein Produkt jetzt anders aus oder sowas.
Das macht ja durchaus Sinn,
dann da erstmal noch in den Dialog zu gehen,
ich weiß auch nicht, eine Schulung zu machen,
wenigstens einen Hinweis zu geben, was auch immer.
Vielleicht sind es auch Marketingmaßnahmen,
dass man halt Nutzer auch darüber in Kenntnis setzt,
es gibt jetzt eine neue Version, es ist sinnvoll und hilfreich,
du kriegst ein neues Feature, kostet dich gar nichts extra,
aber bezahl dein Abo trotzdem weiter und so weiter.
Genau.
Das, glaube ich, einigermaßen erschöpfend beleuchtet.
Jetzt stellt sich für mich aber immer noch die Frage,
wie grenzt sich das denn von anderen Dingen ab?
Was ist denn jetzt eigentlich der Zusammenhang
oder der Unterschied zwischen CI und,
also Continuous Integration, Continuous Delivery, Continuous Deployment
und einer Pipeline?
Ist das jetzt dasselbe? Ist das was anderes?
Und wie ist das mit DevOps?
Ist Continuous Delivery gleichberechtigt mit DevOps oder mit Agilität
oder, erklär mir das mal, Falco.
Ist ja schön, dass ich das jetzt erklären darf.
Na ja, fangen wir mal von vorne an.
Wie in unseren Daten,
wie in unseren Definitionen vorhin gesagt,
also eine Pipeline, eine Sammlung von Tools,
die aufeinander aufbauen, bestimmte Prozessschritte
bei der Abarbeitung der Veränderung des Systems
von Off-Code- und Konfigurationsebene
über Build, Test, Deployment und so weiter,
ist letztendlich die Pipeline, die Sammlung der Tools,
die eingesetzt werden.
Continuous Delivery ist eine Praktik,
die sich gut mit verschiedenen Arbeitsweisen verträgt.
Arbeitsweisen, die zum Beispiel agil sind,
das heißt, kontinuierlich mit neuen Anforderungen umgehen,
Produkte kontinuierlich weiterentwickeln,
zum Beispiel Scrum oder Kanban getrieben,
regelmäßig Veränderungen am Produkt generieren.
Und wenn man diese Veränderungen hat
und regelmäßig am Produkt etwas tut,
muss man diese Schritte,
die in der Pipeline automatisiert sind,
regelmäßig wiederholen.
Und bevor das ein Mensch tut,
der dabei vielleicht Fehler einbaut,
ist es sinnvoll, das zu automatisieren.
Da reden wir dann wieder von der Pipeline,
kommen wir wieder zurück zu dem gerade beschriebenen
Praktik der Pflege einer Continuous Delivery Pipeline,
die, wie gesagt, in agilen Arbeitsumgebungen
ganz hilfreich sein kann,
weil eben regelmäßig Veränderungen am System passieren.
Und das kann auch für sowohl die Entwicklung
als auch den IT-Betrieb hilfreich sein,
wenn man letztendlich darüber nachdenkt.
Man hat verschiedene Infrastrukturen,
die genauso bereitgestellt werden
wie eine neue Funktion in einer Anwendung.
Dann könnte man das sowohl in der Entwicklung
als auch im Betrieb umsetzen.
Und so spielt die Praktik von Continuous Delivery Deployment
in die Hände der Teams, die das nutzen wollen,
wenn sie zum Beispiel in einer agilen Arbeitsweise tätig sind.
Nichtsdestotrotz ist es auch in anderen Arbeitsweisen
sinnvoll und hilfreich, darüber nachzudenken,
wie viel Automatisierung in der Softwarebereitstellung,
in der Hardware-Systembereitstellung denn da ist.
Und so bildet sich letztendlich
auch die Toolkette, die Pipeline,
die man in verschiedenen von Cloud-Anbietern
bereitgestellten Systemen zum Beispiel auch wiederfindet.
Wir haben halt dann eine Standard-Pipeline,
die sie definieren, die man dann letztendlich gut nutzen kann.
Viele Tools, die aufeinander abgestimmt sind,
sodass man sie nicht selbst aufbauen muss,
was natürlich wieder in Cloud-Umgebungen der Vorteil ist.
Man kommt relativ schnell in die kundenfokussierte Arbeitsweise.
Das wäre noch so eine Ergänzung,
die aus meiner Sicht ganz sinnvoll ist.
Was sagst du?
Habe ich irgendwas vergessen?
Würdest du das gerne noch ergänzen?
Nee, ich glaube, das passt ganz ausgezeichnet.
Das Einzige, was vielleicht man noch so
als historische Perspektive ergänzen sollte,
ist Continuous Integration.
Was ja immer so ein bisschen,
ich sage jetzt mal, im agilen Umfeld erwähnt wird,
ist eigentlich älter zumindest als das Agile Manifest.
Das ist eigentlich eine Praktik,
die das erste Mal zumindest beschrieben wurde,
unter diesem Namen von Kent Beck
im Rahmen von Extreme Programming Mitte der 90er Jahre.
Unsere Episode heißt ja
Continuous Delivery in erschwerten Bedingungen.
Und was sind denn letztendlich erschwerte Bedingungen?
Oder vielleicht erster Schritt,
was sind denn die einfachen Bedingungen,
wo das gut funktioniert,
wo es vielleicht gut verbreitet genutzt werden kann?
Einfache Bedingungen, würde ich mal sagen,
sind halt genau die, wo die Dinge übersichtlich sind.
Ich habe ein überschaubares Produkt mit überschaubaren Risiken.
Ich sage jetzt mal,
eine einfache SaaS-Applikation,
die Server sind ganz klar unter meiner Kontrolle,
die laufen auch nicht davon oder sowas.
Die Risiken sind überschaubar.
Sollte diese Applikation doch irgendwie mal die Grätsche machen,
dann funktioniert sie halt nicht.
Und das ist zwar ärgerlich für die Kunden,
aber sprichwörtlich stirbt jetzt noch keiner davon.
Aber es gibt ja auch andere Systeme.
Genau, das wären dann die mit den erschwerten Bedingungen.
Genau.
Und eben auch, um das auch noch dazu zu sagen,
auch insbesondere kleine Teams,
wenige Mitarbeiter.
Ein Produkt von überschaubarem Scope.
Das sind die einfachen Bedingungen.
Da schreibt sich so eine Pipeline ja irgendwie schier von alleine.
Dann wird es halt spannend.
Komplexe Produkte, sprich solche,
die einfach sehr, sehr viele Einzelteile haben,
die vielleicht auch eben nicht trivialerweise miteinander zusammenhängen.
Das kann jetzt, ich sage jetzt mal,
das kann ein Atomkraftwerk sein,
aber das kann auch einfach eine gewichtige Software-Applikation sein.
Microsoft World von mir aus.
Stelle ich mir vor,
ist bestimmt schwierig zu managen.
Die ganze Pipeline und die ganzen Bildumgebungen und die Tests
und so weiter und so weiter.
Oder natürlich halt quasi die Umkehrung von all dem,
was wir gesagt haben.
Viele Mitarbeiter in vielen Teams,
womöglich grafisch verteilt.
Produkte, die nicht nur blanke Software
oder gar blanke Software as a Service sind.
Sprich Embedded Systems oder Versicherungsprodukte
oder Trainings, wie wir sie machen, Falco.
Oder so was,
die vielleicht nicht so leicht zugänglich sind für solche Techniken.
Oder Produkte, die mit besonderen Risiken behaftet sind.
Sicherheitskritische Produkte.
Was ein Automobilsteuergerät oder so was,
ein ABS-Steuergerät ist halt dumm, wenn das nicht bremst.
Da hast du dann meistens einen schlechten Tag.
Aber es muss ja gar nicht so schlimm sein,
sondern es kann auch in Anführungszeichen nur darum gehen,
Finanzprodukte beispielsweise,
wenn dann plötzlich dein Kontostand auf Null ist,
fälschlicherweise.
Das ist dann auch nicht schön.
Oder auch schlicht und ergreifend solche,
wo die Plattform nicht leicht zugänglich ist.
Ich sage jetzt mal ein Satellit.
Die Software in einem Satelliten oder so was.
Wenn jetzt mein Deployment fehlschlägt,
kann es ja sein,
dass der ganze Satellit nicht mehr erreichbar ist.
Ja, und dann schickst du den Mechaniker hoch.
Oder was ist dann die Alternative?
Das, glaube ich, ist das,
was wir unter erschwerten Bedingungen verstehen.
Da möchte ich dir noch was einfalken.
Ach, mit Sicherheit gibt es noch Dinge,
wenn organisatorische Grenzen zwischen Unternehmen dazukommen,
wenn man letztendlich Sprach- und Kulturgrenzen hat,
die in ein Produkt mit reinfallen.
Die Trainings mit verschiedenen Sprachen
ist natürlich auch blöd oder anderes.
Also mit Sicherheit kann man erschwerte Bedingungen generieren.
Ich denke, die Beispiele, die du gebracht hast,
sind auf jeden Fall gute Beispiele.
Und die sollten wir uns auch noch mal ein bisschen näher anschauen.
Wenn man jetzt in einem Umfeld Continuous Delivery betreiben will
mit erschwerten Bedingungen, wo fängt man an?
Was ist das Wichtige?
Macht man erst mal, soweit man kommt?
Ist es ein kontinuierlicher Entwicklungsprozess,
kontinuierlicher Verbesserungsprozess?
Oder hängt es auch davon ab,
welche erschwerte Umgebung hat man genau?
Und können wir auch Hinweise für diese Einzelheiten haben?
Kannst du uns ein paar Beispiele geben?
Macht es einen Unterschied, ob man ein komplexes Produkt hat
oder viele Mitarbeiter?
Oder einfach, weil du viele Mitarbeiter hast,
auch ein komplexes Produkt?
Und das beides fällt zusammen
und du hast die gleichen Lösungsvorschläge
für Continuous Delivery in solch einer Umgebung?
Ja, genau.
Also jetzt haben wir, glaube ich, ganz, ganz viele verschiedene Varianten angerissen.
Und ich glaube, jetzt läuft es darauf raus,
dass wir dann einfach nur sagen können,
na ja, kommt drauf an.
Wo sind denn deine Hürden?
Wo sind deine Schwierigkeiten?
Man sollte ja auch nicht verschweigen,
es gibt ja auch Hürden, die nicht rein,
ich sage jetzt mal, objektiver Natur sind,
irgendwie technischer Natur oder organisatorischer Natur,
sondern es gibt ja auch kulturelle Hindernisse.
Ist die Organisation überhaupt willens,
sich dem auszusetzen,
dass man so schnell iteriert?
Oder hat man da aus guten oder schlechten Gründen Angst davor?
Beispielsweise.
Gut, kommt drauf an.
Du hast vorhin so schöne Beispiele genannt
für Hürden im Bereich Continuous Delivery.
Gehen wir doch einfach mal durch.
Wenn man jetzt ein komplexes Produkt hat,
was sind da Vorschläge?
Was macht ein komplexes Produkt aus?
Also sehr viele Komponenten, Softwarekomponenten,
die integriert werden müssen,
sehr viele Schnittstellen vielleicht zwischen den Komponenten,
vielleicht auch unterschiedliche Programmiersprachen,
teilweise für die einzelnen Komponenten,
vielleicht auch unterschiedliche Middleware
oder unterschiedliche, äh,
Serverumgebung, in dem diese Applikation läuft.
Das wären jetzt so Gedanken, die ich hätte.
Wie geht man in solchem Umfeld
dann entsprechend mit Continuous Delivery um?
Genau, also jetzt mal ausgehend von dem Berühmten,
kommt drauf an, dass ihr jetzt, glaube ich,
noch öfter hören werdet.
Ich glaube, da liegt ein großer Wert einfach im Pragmatismus.
Zu sagen, kann ich zum Beispiel mein Produkt irgendwie aufbrechen?
Gibt es irgendwelche Nahtstellen, wo ich sagen kann,
da mache ich nicht eine riesen Pipeline,
die wahnsinnig verzwickt ist,
sondern kann ich zum Beispiel mehrere kleine Pipelines haben,
die Teilbereiche dieses Produkts überdecken
und die mir schon mal, na,
lass uns mal einen Schritt zurückgehen und zu sagen,
was ist denn der Zweck davon?
Der Zweck davon ist doch, leichter an Feedback zu kommen,
Risiken rauszunehmen, technische Risiken wie auch Produktrisiken.
Und wenn man es aus dieser Warte betrachtet,
dann, glaube ich, fällt es einem leicht, pragmatischer zu sein
und zu sagen, pass mal auf,
ich muss hier gar nicht alles auf einmal schaffen,
sondern hier habe ich ein paar Teile,
die kann ich in Isolation testen.
Oder die kann ich vereinfachen.
Gerade wenn es um das Problem geht,
dass komplexe Produkte häufig haben,
dass Prototypen sehr teuer werden.
Gerade wenn es nicht mehr reine Software ist,
sondern wenn du eine Brücke baust oder so.
Also Prototypen sind halt irgendwie ganz schön teuer.
Gut, das ist gut.
Gut, das ist aber, glaube ich, einer der nächsten Punkte,
die wir besprechen wollten.
Produkte, die über reine Software hinausgehen.
Ich sehe jetzt komplexe Produkte als schon softwarefokussiert.
Das heißt, letztendlich mit sehr vielen Komponenten,
mit sehr vielen Schnittstellen zwischen den Produkten.
Da hätte ich jetzt gesagt, es ist sicherlich sinnvoll,
so etwas einzubauen wie Contract First mit Schnittstellentests
und Ähnlichem zwischen den einzelnen Komponenten zu arbeiten.
Und diese dann auch in den Pipelines mit zu verankern.
Dass man halt sagt, okay, du kannst halt eine neue Version von einem,
keine Ahnung, Service X oder einer Komponente Y
nicht in die Integrationsumgebung deployen,
wenn sich der Vertrag verändert hat
und die ganzen Konsumenten darüber noch nicht informiert sind
und noch nicht Bescheid wissen.
Solche Dinge würde ich an der Stelle ansetzen,
wo man in Richtung komplexe Softwareprodukte geht.
Wir hatten als Stichpunkt auch den Punkt lange Zyklen,
dass man sich halt auch die Zeit nimmt, die man braucht
und vielleicht schaut, wie weit man mit Automatisierung kommt
und an den Stellen halt, an denen Automatisierung geht,
sie zuerst umsetzt und an denen, wo es halt schwieriger ist,
sich dann später die Zeit nimmt.
Also auch so einen kontinuierlichen Verbesserungsprozess darauf ansetzt,
Continuous Improvement über einen längeren Zeitraum,
dann diese komplexe Pipeline, die man dann halt für ein komplexes Produkt braucht,
dann entstehen zu lassen.
Und dann auch aus dem Feedback entsprechend zu lernen,
wäre jetzt für mich der Punkt.
Wie sieht es bei vielen Mitarbeitern aus?
Was ist da der Ansatz?
Da ist, glaube ich, das Wesentliche, dass man…
Das ist ja, sagen wir mal, ein Nebenaspekt von komplexen Produkten.
Wenn ich viele Leute habe, die Hand in Hand miteinander arbeiten müssen,
dann hat das in sich eine gewaltige Komplexität,
sowohl wahrscheinlich des Produkts,
als auch einfach die Interaktionen zwischen den Leuten.
Die müssen miteinander reden können,
die müssen sich austauschen können,
Fehler müssen gesucht werden können.
Da macht es also einfach sehr viel Sinn,
besonders viel Augenmerk zu legen auf möglichst reibungsarme Kommunikation.
Das bedeutet auch solche Dinge wie zum Beispiel
besonders starke Visualisierung des Zustands in der Pipeline,
dass einfach möglichst viel Klarheit darüber herrscht,
was passiert denn eigentlich gerade in meinem Produkt
und übrigens auch in meiner Pipeline.
Ist meine Pipeline überhaupt ganz grundlegend gesund?
Was passiert denn in der…
Unter welcher Last steht die und so fort?
Und dass man die Pipeline da so ein bisschen auch vielleicht als…
oder Continuous Delivery da als Mittel zum Zweck nutzt und sagt,
wir definieren Standards, indem wir sagen,
das, was sich mit den technischen Mitteln unserer Pipeline umsetzen lässt,
das gilt jetzt erstmal als genehmigt,
dass man da also einfach ein bisschen für Klarheit sorgt,
ein bisschen Kommunikation vielleicht vorwegnimmt oder unnötig macht.
Mhm.
Also ich sehe auch hilfreich, einheitliche Sprachen zu definieren.
Wenn man jetzt sieht, wie weit zum Beispiel
so ein Framework wie SAFe in der Wirtschaft angewendet wird,
ist es natürlich auch ein Vorteil,
dass es eine gewisse Definition von
wie nennen wir Teams, wie nennen wir Teams von Teams,
wie nennen wir letztendlich Produktkomponenten und ähnliches,
welche Rollen gibt es, dass man in der Richtung halt die Vorteile nutzt und sagt,
okay, wir haben kommunikationsgleiche Sprache,
gleiche Frameworks, gleiche Arbeitsweisen,
um so ein bisschen darüber hinwegzukommen,
dass jeder in seiner eigenen Welt lebt und Dinge unterschiedlich versteht.
Das ist aus meiner Sicht wichtig.
Und natürlich ist dann, ich habe, als du das gerade beschrieben hast,
Meryl Conway so ein bisschen um die Ecke winken hören,
technische Systeme, die komplex sind.
Brauchen natürlich auch die entsprechende Teamstrukturen und anderes.
Kann man natürlich auch mit an der Stelle betrachten und mit einbeziehen.
Vielleicht auch Team-Topologies mit einsetzen und mal zu visualisieren,
inwiefern passt denn die Komplexität, die im Produkt steckt,
auch mit den Team- und Mitarbeiter- und Kommunikationsprozessen überein
und wo kann man da optimieren, wäre letztendlich so ein Ansatz.
Also Frameworks notwendig,
Frameworks nutzen, Visualisierung nutzen
und das Ganze dann in die Pipeline bringen
und sie halt über die Zeit weiterentwickeln.
Magst du noch was ergänzen?
Ja, nämlich etwas wird an der Stelle immer deutlicher und wichtiger,
je mehr so eine Pipeline, so ein CD-System an Komplexität zunimmt,
desto mehr wird es dann plötzlich selbst zu einem Produkt,
einem Produkt, das eben zum internen Verbrauch bestimmt ist,
für die eigenen Mitarbeiter.
Für die eigenen Ingenieure.
An das dann auch all dieselben Maßstäbe angelegt werden,
wie wir es an gewöhnliche Produkte tun.
Da liegen Qualitätsmaßstäbe an.
Das muss getestet sein.
Das muss dokumentiert sein.
Da muss ein Monitoring dahinter stehen und so.
Das entwickelt dann unter Umständen ganz plötzlich ein Eigenleben,
was ja zum Beispiel auch SAFE auch ganz ausdrücklich sagt.
Die haben doch dann diese zwei Arten,
diese zwei Arten von Wertströmen.
Wie hießen die gleich wieder, Falco?
Ich komme nicht drauf.
Entwicklungswertströme und operative Wertströme.
Ja, genau. Richtig.
Wo das dann also wirklich sein eigenes Produkt wird irgendwann mal,
diese ganze Pipeline-Klempnerei.
Ja, passt ganz gut zu einem Zitat,
was auch mal ein Elon Musk in einem Interview gebracht hat,
oder ja, eigentlich definiert hat,
was denn das Produkt von Tesla sei.
Da ist die Aussage nicht gewesen, die Fahrzeuge,
sondern die Gigafactory ist das Produkt.
Die Gigafactory ist das Produkt von Tesla,
die dann hinterher die Fahrzeuge ausspuckt
und teilweise sogar so ausspuckt,
dass nicht jede Fahrzeugserie gleich ist,
sondern jedes einzelne Fahrzeug ein eigenes Produkt ist
mit eigenen anderen Eigenschaften als das,
als gegebenenfalls ein Vorgängerprodukt
oder ein Produkt von einer Woche vorher,
weil sich die Fabrik verändert hat
und damit halt die Produkte anders werden.
Zum Beispiel eine Schraubverbindung
durch eine Klebeverbindung ersetzt wurde oder anderes kontinuierlich,
was dann halt mit verschiedenen Prozessen, Tests und anderem halt einhergeht
und auch eine Automatisierung bis hin zur Freigabe dieser Produkte,
zur Anmeldung von bei den entsprechenden Behörden,
dass halt auch diese veränderten Versionen entsprechend
auf der Straße fahren dürfen,
also freigegeben werden vom Kraftfahrtbundesamt
oder ähnlichem.
Ganz interessante Sicht darauf,
dass letztendlich das Produkt, die Pipeline,
dann ein internes Produkt wird
und ich gehe davon aus,
dass so auch die AWS und Azure und Co. entstanden sind,
dass sie halt für die eigenen Entwickler
als internes Produkt da waren
und dann die Qualitätsmaßstäbe
auch für externe Entwickler irgendwann erfüllt haben
und so dann halt auch direkt als Produkt für Firmen wie Netflix,
die auf AWS bauen oder andere,
dann weiter genutzt werden können.
Also so wird dann halt das interne Produkt
auch sogar zum externen.
Okay, wir waren gerade immer noch bei den erschwerten Bedingungen
für Continuous Delivery
und eine von denen, die du vorhin erwähnt hattest,
sind Produkte, die über reine Software hinausgehen,
also eben nicht nur die App oder die Web-Anwendung,
die dann irgendjemand nutzt,
sondern mit Hardware-Komponenten beinhaltende Produkte,
Cyber-Physical Systems,
verteilte Systeme mit dem Abstand von RGAP oder anderem.
So Produkte, die mir da einfallen, wären halt so ein Drucker,
der halt auch physische Komponenten hat,
die Druckerpatrone, die Steuerungselemente und anderes.
Wie baut man da Continuous Delivery Pipelines auf?
Worauf muss man achten?
Und was ist letztendlich Tipps und Hinweise,
die wir unseren Hörern mitgeben können?
Genau, das ist eine ganz, ganz wichtige Frage,
glaube ich.
Wie fängt man denn an solchen Stellen an?
Und dort gilt noch mehr als allgemein diese Weisheit,
wie isst man einen Elefanten Gabel für Gabel?
Einfach mal irgendwo anfangen, agil sein,
auch bei diesem Produkt Pipeline,
bei diesem Produkt Continuous Delivery.
Das erlebe ich ganz häufig in Trainings,
dass die Teilnehmer dann so ein bisschen wie das Kaninchen
auf die Schlange, auf diesen Riesenberg an Möglichkeiten starren
und sagen, wir sind ja noch so weit weg davon.
Aber man muss halt mal irgendwo anfangen.
Und man darf da auch gerne pragmatisch sein
und man kann da auch mit Fug und Recht einfach mal Sachen rauslassen.
Ein Beispiel aus meiner eigenen Praxis ist vielleicht
ein Kunde von vor einigen Jahren.
Die haben im weiteren Sinne Industrieroboter gebaut.
Und wir haben es so weit gebracht, dass wir eine Pipeline hatten,
die neue Software-Inkremente von diesem Roboter über Nacht
auf den Roboter drauf geflasht hat.
Und dann eine einzige ganz banale Trajektorie abgefahren ist.
Das war also, wenn man so will, eigentlich echt nur ein Smoketest.
Na ja, zuckt das Ding überhaupt noch?
Aber das war schon mal sehr, sehr viel wert.
Wir konnten uns jeden Tag aufs Neue davon überzeugen,
dass unser Bildprozess nach wie vor richtig ist,
dass unsere Deployments nach wie vor funktionieren
und dass wir nach wie vor in der Lage sind,
erfolgreich diesen Roboter anzusteuern
und definierte Koordinaten anzufahren,
das auch zu beweisen, dass wir dort gelandet sind.
Nur dieser eine Test hat schon wahnsinnig viel uns gebracht.
Und natürlich, man hätte das dann noch weiter ausbauen können.
Es ist dann auch aus anderen Gründen nicht dazu gekommen.
Meine Beauftragung hat geendet und so weiter.
Aber lange Rede, kurzer Sinn.
Allein dieser Schritt von null Tests zu einem Test
und sei ja auch nur so trivial,
hat, ich weiß nicht, ob 80 Prozent,
aber sehr, sehr viel des Werts erzeugt, des Gesamtwerts.
Ja, so wie bei Pareto.
Ich glaube, das ist ein sehr guter Schritt,
um zu schauen, wo kann man anfangen,
dass man die Dinge, die halt vielleicht viel Zeit kosten,
dass die Dinge, die viel Aufwand in der Wiederholung
oder vielleicht auch eine hohe Fehleranfälligkeit haben,
diejenigen werden, die man halt zuerst automatisiert,
um sich damit dann Zeit zu schaffen,
auch später weitere Elemente zu bedenken.
Sowas wie, wie gehe ich damit um,
wenn ein Flaschen von einer Komponente,
von einem Steuersystemgerät
oder von einem Router
oder anderer Komponente im System
letztendlich nicht funktioniert,
dass es halt ein Fallback gibt,
dass dieses System halt zumindest auf einen vorherigen Stand
wieder zurückkommt.
Dass man letztendlich darüber nachdenkt,
Techniken einzusetzen,
die bestimmte Prozesse verkürzen.
Ich bin ja aus der Ingenieurinformatik heraus
auch mit Prototyping,
zum Beispiel bei der Entwicklung von neuen Geräten,
neuen Systemen im Kontakt gewesen,
dass man 3D-Druck,
dass man verschiedene Techniken halt einsetzt,
bis hin zu Drucken von Leiterplatinen und ähnlichem,
dass man all das nutzt, was halt da ist.
Genauso aber eben auch mit Mocking.
Das heißt, dass man Softwarekomponenten einsetzt,
die so tun, als wären sie Hardwarekomponenten,
so ähnlich wie das bei dem DevOps-Handbook
und der Firmware-Tests bei HP beschrieben worden ist.
Dass man halt wirklich sagt,
okay, für jede Druckerserie hat man halt
einen physischen kleinen Drucker irgendwo im System,
der halt angesteuert werden kann,
aber eben auch genauso entsprechend Mocks,
die viel häufiger, viel schneller das Feedback liefern,
letztendlich etwas so funktioniert,
wie es sollte oder nicht
und mit diesen beiden Techniken entsprechend arbeitet.
Oder halt auch den allerersten Schritt,
wie du es immer so gerne sagst,
mit Null-Automatisierung zu starten.
Dass man halt okay sagt,
ich baue mir erstmal ein Framework auf,
mit dem ich anfangen kann zu automatisieren,
also eine Pipeline im allereinfachsten Fall
und baue die kontinuierlich weiter auf
und für einzelne Komponenten integriere die,
habe vielleicht erstmal einen Fokus auf eine Testumgebung
oder auf eine Entwicklungsumgebung
und baue die dann über die verschiedenen Stages hin weiter auf.
Vielleicht auch erstmal nur die Continuous-Integration-Sicht
für eine einzelne Komponente,
das dann für alle Komponenten stückchenweise dann aufzubauen
in Richtung Integrationstests
und dann so zu einem Ende-zu-Ende-Pipeline zu kommen,
die Continuous-Deployment ermöglicht.
Genau.
Ich finde, an der Stelle ist es immer sehr hilfreich,
sich wieder vor Augen zu halten.
Das, worauf wir auch zwischendurch
bei unserem DevOps Specify & Verify Training
immer wieder zurückgekommen sind,
nämlich was ist denn eigentlich der Kern,
der Kern hinter Softwarequalität,
weil es ist ja so nebulös, wie lässt sich das fassen?
Es lässt sich so fassen, dass man sagt,
habe ich Vertrauen darein,
dass der Wert tatsächlich erbracht werden kann?
Und wenn ich jetzt an mein Roboterbeispiel von vorher denke,
allein der Umstand, dass ich jede Nacht
das neueste Inkrement geflasht habe,
dass ich jede Nacht den Roboter einmal habe fahren lassen,
hat mir ein ganz großes Grundvertrauen gegeben,
dass das System als Ganzes noch nicht so schlimm im Graben ist,
wie es sein kann.
Selbst wenn da mal irgendwie ein bisschen was faul ist,
wir haben es ja sofort gemerkt.
Und selbst wenn wir natürlich in Einzelheiten
noch jede Menge Bugs hatten oder sowas,
aber ganz grundsätzlich,
das Ding tut, was wir von ihm wünschen.
Und aus dieser Warte, glaube ich,
kommt man dann auch sehr leicht wieder dahin,
wenn Leute sagen,
ja, also CD ist ja an sich eine gute Sache,
aber für uns geht das nicht, weil Grund, Grund, Grund.
Wenn man sagt, okay, was kannst du denn tun,
womit du das Vertrauen heben kannst
in dein Produkt?
Dann finden die meisten Leute doch sehr schlaue Lösungen,
sehr schlaue Antworten,
die vielleicht nicht perfekt sind,
die vielleicht Dinge auslassen,
ganz bewusst auch Dinge auslassen.
Einfach aus der Überlegung heraus,
das Bessere ist der Feind des Guten.
Lieber eine einfachere Version jetzt gleich haben
und jetzt sich gleich davon überzeugen können,
ja, geht,
als sich zu verkünsteln und dann am Ende
hast du ein Dreivierteljahr rumgebastelt
und hast immer noch keine Pipeline am Laufen.
Genau, das kommt auch so ein bisschen
zu dem Schlussthema, was wir noch besprechen wollten,
nämlich eignet sich Continuous Delivery denn wirklich
in allen Fällen?
Oder anders gefragt,
welche Ausreden gibt es denn, keinen CD machen zu können?
Gerade gesagt, okay, fangt an, macht es mit kleinen Schritten,
versteckt euch nicht hinter dem perfektionistischen Ansatz,
alles von Ende zu Ende automatisiert zu haben
und das ist nie erreichbar,
weil das halt so ein großer Klotz ist,
sondern schneidet den Elefanten klein,
esst ihn Gabel für Gabel und fangt an.
Continuous Delivery umzusetzen,
von mir aus in einzelnen Komponenten,
um dann über die Zeit eine Pipeline zu bauen,
die Continuous Deployment und Release on Demand möglich machen.
Genau so ist es.
Also aus meiner Sicht gibt es keine Ausrede,
um nicht Continuous Delivery in irgendeiner Form umzusetzen.
Mag sein, dass das anders ausschaut als bei anderen.
Mag sein, dass ihr halt nicht mehr
zwei Wochenzyklen hinkriegt,
sondern bloß drei Monatszyklen,
weil das ist halt das Beste, was man so erreichen kann,
wenn man Atomkraftwerke baut oder so.
Alles okay, alles wunderbar.
Solange man sich darauf zurückbesinnt,
dass man sagt, es geht mir darum, kurz zu iterieren,
was auch immer kurz heißt,
es geht mir darum, Feedback zu gewinnen,
es geht mir darum, Vertrauen zu schaffen,
es geht mir darum, um die Erzeugung von Artefakten abzukoppeln,
von der Auslieferung von Wert.
Dass ich sagen kann, ich generiere ständig irgendwie neue Produktinkremente,
ich schreibe jede Menge JavaScript-Code oder was auch immer
und das ist vollkommen getrennt davon,
wann ich jetzt eigentlich eine neue Version meines Produkts
meinen Kunden vorsetze, dann bin ich auf dem richtigen Weg.
Und alles, was ihr dann macht, wird schon stimmen.
Solange ihr dieses Ziel im Auge behaltet,
könnt ihr ja gar nicht verkehrt sein
und dürft sehr gerne natürlich auch an der Stelle agil sein und sagen,
ich mache auch die Weiterentwicklung meiner Pipeline.
Kurz, zyklisch, Feedback getrieben in dem Bewusstsein,
dass ich bestimmt auch ab und zu mal einen Bock schieße,
aber macht ja nichts, dann machen wir es nächstes Mal besser.
Und jetzt will ich trotzdem noch mal kurz darauf eingehen,
auch wenn die Zeit schon ein bisschen lang wird.
Falco, wenn jetzt jemand sich ernstlich bemüht, Continuous Delivery einzuführen
und es fällt ihm aber irgendwie schwer, es klappt nicht gut,
die Pipeline ist doof und worauf mag das hindeuten?
In was für Probleme mag er sich?
Kann er vielleicht hineingelaufen sein?
Was für Erfahrungen hast du da gemacht?
Das ist auch relativ breit gefächert.
Da kann man halt verschiedene Gründe ansetzen.
Einerseits kann es fehlendes Wissen sein,
wo man mit Schulungen, mit Erfahrungen von Entwicklern,
die das vielleicht zwei, drei Mal in ihrer Vergangenheit schon gemacht haben,
gut nach vorne kommen kann,
wo man sich auch mit einem entsprechenden Berater vielleicht gefallen tut.
Letztendlich muss man halt schauen,
wird es überhaupt auch genutzt,
was man sich da als Continuous Delivery Pipeline aufgebaut hat.
Wenn man es letztendlich einmal gemacht hat, dann feststellt,
ja, ist okay, wir nutzen das jetzt.
Und derjenige, der es vielleicht gebaut hat, hat das Unternehmen verlassen,
Wissen geht an der Stelle vielleicht verloren,
es ist nicht gut genug dokumentiert.
Dann schläft auch solch ein Produkt, auch wenn es ein internes ist,
oder gerade wenn es ein internes ist, dann auch schnell ein.
Das sind so die Gedanken, die mir jetzt ad hoc zu dieser Frage kommen.
Magst du das noch ergänzen?
Hast du noch Hinweise aus deiner Sicht?
Ja, klar.
Also ich meine, was du beschrieben hast, ist natürlich auch so ein Klassiker.
Das war irgendjemand ein Steckenpferd und der hat das jetzt aufgebaut.
Und dann wendet er sich neuen Themen zu.
Dann verfällt das irgendwie so ein bisschen.
Das ist natürlich immer sehr traurig, wenn das passiert.
Und das hat für mich dann auch immer so ein bisschen,
entweder deutet es darauf hin,
dass derjenige am tatsächlichen Bedarf seiner Kollegen vorbeigebaut hat,
oder es deutet darauf hin,
dass der Wert vielleicht noch gar nicht erkannt wurde,
vielleicht auch tatsächlich noch nicht realisiert wurde,
weil die wirklich coolen Sachen, zu denen ist man vielleicht noch gar nicht gekommen.
Wir haben es ja schon ein paar Mal erwähnt.
Es geht darum, sich selbst Vertrauen zu erschaffen,
sich selbst in die Lage zu versetzen, schneller zu iterieren.
Nicht zum Selbstzweck, sondern um auf diese Weise noch leichter dem Wert folgen zu können.
Aber was halt auch sehr häufig ist,
ist, dass das auch schlicht und ergreifend ein kulturelles Problem ist.
Schon klar, wir haben da jetzt irgendwie eine technologische Plattform,
die uns ganz viel ermöglicht.
Wir machen dann gar nichts draus.
Wir bleiben bei, ich weiß nicht, quartalsweisen Releases.
Oder wir bleiben dabei, dass wir ganz viele manuelle Freigabeprozesse brauchen,
weil das muss so sein, weil das haben wir schon immer so gemacht.
Man darf sich sehr stark eingeladen fühlen,
das jetzt wirklich auch als Gelegenheit zu nutzen,
zu sagen, wo gibt es denn hier alte Zöpfe, die ich abschneiden kann.
Es steht ja außer Frage, dass Prozessschritte,
die mal eingeführt wurden, mit Fug und Recht eingeführt wurden,
um bestehende Probleme zu lösen oder wenigstens zu lindern.
Aber existiert das Problem noch?
Wenn ich zum Beispiel häufig ausliefere,
ist das Risiko einer Auslieferung wirklich immer noch so hoch,
dass ich dafür einen manuellen Freigabeprozess brauche?
Oder kann ich nicht sagen, wird schon stimmen,
und wenn nicht, dann schiebt man einen Bug-Fix-Release gleich hinterher?
Wir haben ja die technischen Möglichkeiten.
Lasst uns einfach riskieren.
Das Risiko der Langsamkeit ist plötzlich größer als das Risiko der Schnelligkeit.
Da kommt man natürlich auch zwei Schritte weiter gedacht
in Richtung Wertstromanalyse,
Richtung Wertstromdesign,
dass man sich, bevor man in die Automatisierung geht,
natürlich auch darüber Gedanken macht,
welche Prozessschritte sind überhaupt werthaltig,
die wir jetzt aktuell haben?
Und können wir die ersetzen?
Können wir sie wegautomatisieren?
Also können wir sie in der Automatisierung tun
und dann gehen sie halt relativ schnell und einfach?
Oder sind sie gar nicht mehr relevant,
gar nicht mehr werthaltig,
weil sie vielleicht früher mal einen Wert geschöpft haben,
der jetzt gar keiner mehr ist,
weil Kunden daran gar nicht mehr interessiert sind,
weil vielleicht auch andere Abteilungen,
für die man das mal gemacht hat,
nicht mehr daran interessiert sind?
Und auch da hat man natürlich eine gute Grundlage,
dann über Continuous Delivery nachzudenken.
Genau.
Also, welche Gründe gibt es dafür,
dass Continuous Delivery schwierig sein kann?
Kultur, haben wir gerade gesagt.
Das Zweite ist, ich nenne es mal Featureitis,
dass man sich nicht ausreichend zurücknimmt,
und sagt, wie klein kann ich Inkremente überhaupt machen?
Wie kann ich es mir überhaupt ermöglichen,
dass ich kurze Zyklen fahren kann,
dass ich die umsetzen kann,
dass die für mich auch Sinn machen,
dass ich die im Griff behalten kann?
Also ich sage jetzt mal etwas,
was völlig auf der Produktebene passiert,
was passiert lange bevor ich geschweifte Klammern tippe,
sondern schon wirklich in der Phase von Produktmanagement
und Product Ownership.
Und das Dritte,
was glaube ich auch oft ein Paradebeispiel ist
oder ein Paradethema ist,
ist Architektur.
Genauso wie beim Testen,
man weiß ja die Binsenweisheit,
wenn Tests schwer zu schreiben sind,
dann bist du entweder einfach nur inkompetent im Testen,
aber viel wahrscheinlicher ist es,
dass deine Architektur es einfach schwer macht,
Dinge so weit zu entkoppeln,
dass sie vernünftig testbar sind.
Und genauso ist es mit Continuous Delivery.
Wenn sie dir schwer fällt,
dann ist das häufig ein Signal dafür,
dass in den Strukturen,
die bestehen in deinem Produkt oder in deiner Organisation,
Conway lässt grüßen,
übermäßig enge Verknüpfungen vorhanden sind,
die es dir schwer machen,
eine Pipeline wirklich erfolgreich zu bauen und zu betreiben.
Das wären so die drei Klassiker,
sage ich mal,
die mir auch immer wieder mal unterkommen.
Finde ich letztendlich wirklich hilfreich,
dass man darüber nachdenkt,
dass man auch diese unterschiedlichen Gründe,
Kultur, Feature,
Architektur unabhängig voneinander betrachtet
und dann schaut,
ob man dagegen vorgehen kann
oder wie man damit gut umgeht.
Okay, wollen wir zum Schluss kommen?
Gibt es noch Bemerkungen?
Gibt es noch Punkte,
die wir bis jetzt nicht erwähnt haben,
die es noch wertvoll sind für die Zuschauer, Zuhörer?
Wenn wir sie vergessen haben,
meldet euch auf jeden Fall
und sagt uns, was euch wichtig ist.
Ansonsten erst mal Luca.
Genau.
Also ich glaube,
ich kann mich der Einladung von Falco anschließen.
Falls ihr Fragen oder andere Fragen habt,
dann schreibt uns sehr gerne.
Vielleicht machen wir mal eine Follow-Up Episode
mit Hörerzuschriften,
Hörerinnenzuschriften.
Ich glaube, dass das ein Thema wäre,
das sich dafür sehr eignen würde.
Insofern immer her mit dem Zeug.
Ich möchte aber auf jeden Fall noch auf etwas hinweisen,
nämlich es gibt eine Webseite,
die mich momentan sehr beschäftigt,
die nennt sich minimumcd.org.
Die ist ins Leben gerufen,
ich glaube von Brian Finster
und noch so ein paar Leuten,
die alle sehr, sehr schlau sind.
Und die versucht haben,
eine argumentative und technische
oder wie soll ich sagen,
organisatorische Basis für Continuous Delivery
niederzuschreiben.
Und ich lege euch allen ans Herz,
diese Webseite mal anzuschauen,
die ist sehr, sehr kurz und knackig
und euch einfach mal anzuschauen,
welche Prinzipien dort aufgezählt werden,
an die man sich halten sollte,
um erfolgreich Continuous Delivery zu betreiben
und damit in der Verlängerung
auch erfolgreich agil zu arbeiten.
Wir packen natürlich den Link noch in die Shownotes,
aber minimumcd.org,
könnt ihr auch einfach direkt jetzt schon mittippen.
Genau, da warst du ja sehr fleißig bei der Übersetzung.
Ich habe nochmal drüber geschaut.
Sind jetzt auch offizielle Mitarbeiter
oder Kontributoren, deutsch das Wort.
Ja, auf jeden Fall sinnvoll und hilfreich,
um zu schauen, wie minimum,
cd darüber denkt,
was Continuous Delivery wirklich ausmacht,
wo die Kerne des Themas sind.
Und ja, können wir gerne nochmal ein wenig tiefer darauf eingehen
in einer späteren Folge.
Besonders dann, wenn ihr uns sagt,
es interessiert euch.
Oder auch, es interessiert euch nicht
und dann hört ihr nie wieder davon.
Das ist auch okay.
Ja, das glaube ich nicht.
Gut, aber wir, Falko, sollten, glaube ich,
ganz dringend zum Schluss kommen.
Die Episode wird doch schon wieder ganz schön lang.
Mir hat es sehr viel Spaß gemacht.
Vielen Dank für das interessante Gespräch.
Vielen Dank für deine Einsichten, Falko.
Ja, liebe Hörerinnen und Hörer, bis bald.
Da schließe ich mich ein, auch von mir.
Bis bald.