Folge 70: Minimum Viable CD

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge unterhalten sich Luca und Falko erneut über Continuous Delivery, dieses Mal aus der Perspektive des Projekts MinimumCD.

MinimumCD versucht einen allgemeingültigen Grundstock an Continuous Delivery Praktiken bzw. Sichtweisen zu definieren, der bei der richtigen Unsatzung als Leitfaden dienen sollte.

Falko und Luca haben sich mittlerweile aktive an diesem Projekt beteiligt, was uns zusätzlichen Schwung verleiht, ihm zu größerer Bekanntschaft zu verhelfen.

In dieser Podcast-Episode steht das Konzept des Minimum Viable Continuous Delivery (MinimumCD.org), mitbegründet von Bryan Finster und Dave Farley, im Fokus. Die Gastgeber, erfahrene Experten im Bereich DevOps, diskutieren technische und kulturelle Aspekte des Continuous Delivery. Sie teilen ihre Erfahrungen mit Continuous Integration und Deployment in verschiedenen Arbeitsumgebungen und betonen die Wichtigkeit von automatisierten Systemen im DevOps. Die Konversation beleuchtet auch Herausforderungen und Entwicklungen in der Softwareentwicklungspraxis, einschließlich trunk-basierter Entwicklung und der Auswirkungen dieser Methodologien.

Inhalt

  • Einführung in Minimum Viable Continuous Delivery
  • Erfahrungen mit Continuous Integration und Deployment
  • Technische Aspekte von DevOps und automatisierten Systemen
  • Kulturelle und organisatorische Herausforderungen im DevOps-Bereich
  • Trunk-basierte Entwicklung und ihre Auswirkungen
  • Evolution und Herausforderungen in der Softwareentwicklung

Shownotes

Minimum Viable CD manifesto

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 Ingiarni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dirk 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.
Heute haben wir ein recht spannendes Thema für euch, das wir schon so ein bisschen mal angerissen haben,
vor einer Weile, als Bryan Finster bei uns im Podcast zu Gast war,
der da berichtet hat von einer Initiative, die er zusammen mit ein paar anderen Leuten,
Dave Farley, glaube ich, unter anderem, ins Leben gerufen hat,
nämlich Minimum Viable Continuous Delivery, zu finden unter minimumcd.org.
Dieser Bericht, den uns da der Brian Finster gegeben hat,
hat Falko und mich irgendwie auch beide sehr begeistert,
weil ich finde, dass diese Initiative Minimum Viable Continuous Delivery, minimumcd.org,
ich weiß nicht, sehr den Nagel auf den Kopf trifft und viele Dinge zusammenfasst,
die, glaube ich, wir alle für wichtig halten.
Und insofern bin ich gespannt, weil ich habe ja einleitend gesagt,
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Continuous Delivery klingt ja jetzt erstmal sehr technisch,
aber ich bin gespannt, wie kurz wir brauchen, bis wir plötzlich nach oben purzeln,
in Richtung Organisation und Kultur.
Aber vielleicht einleitend, mal so der Neugehalber,
wie lange ist es eigentlich her, Falko, dass du das erste Mal mit solchen Dingen wie Continuous Delivery zu tun hattest?
Na, letztendlich seit meiner Zeit als Entwickler, in der ich hauptberuflich Software entwickelt habe.
Meist im Automotive-Umfeld hatten wir zum Beispiel ein Portalprojekt mit Java-Basis
und Continuous Delivery Pipeline, die Jenkins-basiert war,
in der Zeit, bevor ich da war, noch die Hudson-Setups, die dann migriert worden sind,
wo dann so ein bisschen Testprozesse mit integriert waren,
aber auch viel händisches Deployment am Ende des Prozesses,
also mehr Continuous Build und halb Continuous Testing
und nicht ein komplett durchgängiger Prozess, der in Richtung Produktiv-Deployments oder so ging,
weil da teilweise Zugangspotenzial war.
weil da teilweise Zugangspotenzial war, weil da teilweise Zugangspotenzial war,
zur Hausberechtigung und Co nicht vergeben werden sollten an solche automatisierten Systeme.
zur Hausberechtigung und Co nicht vergeben werden sollten an solche automatisierten Systeme.
Wie sieht es bei dir aus, wann hattest du mit Continuous Delivery zuerst zu tun?
Also ach, du hattest an einer Zeit gefragt.
Ich hätte jetzt gesagt, irgendwo um 2016, 2015 war das bei mir. Wie sieht es bei dir aus?
Also bei mir war es noch früher und ich frage mich, Iggy, ob das bei dir nicht auch früher war?
Also bei mir war es noch früher und ich frage mich, Iggy, ob das bei dir nicht auch früher war?
Also als Jenkins noch Hudson hieß, da war das länger her als 2015 sogar.
Also als Jenkins noch Hudson hieß, da war das länger her als 2015 sogar.
Ich weiß es gar nicht mehr genau. Aber bei mir fing das sehr früh an und wie viele solche Sachen ja auch mehr so ein bisschen versehentlich. Das war jetzt nicht so, dass ich das irgendwie von langer Hand geplant hätte und gesagt, oh, ich muss eine Continuous Delivery Pipeline aufbauen oder sowas, sondern seien wir ehrlich, das war halt in der Hauptsache Faulheit.
Statt dass ich dieselben Handgriffe irgendwie hundertmal händisch mache, habe ich sie dann halt irgendwann mal wegautomatisiert. Das schlicht sich dann häufig so ein bisschen ein, dass man sich halt ein paar Skripte geschrieben hat, um sich die Arbeit zu vereinfachen, vielleicht auch nur punktuell, vielleicht irgendwelche Make Targets oder sowas.
Und das erste Mal, als ich ein, ich nenne es jetzt mal ein klassisches CICD-Werkzeug verwendet habe, das war eben damals Hudson, dass er sich dann irgendwann mal in Jenkins umbenannt hat.
Nachdem Oracle sich irgendwie die Supremacy…
… direkt einverleibt hat und die Namensrechte nicht mehr hergegeben hat, das muss im Jahre 2009, 2010 irgendwie so die Art gewesen sein. Ich weiß das schon gar nicht mehr genau, aber es ist schon sehr, sehr lange her.
Ich habe gerade noch ein bisschen recherchiert nebenbei. Also initial wurde Hudson 2005 released. Das letzte offizielle Release, die 3.3.3er Version, ist 2016 rausgekommen. Insofern kann das schon sein, dass es bei mir auch ein bisschen früher war, dass wir nicht mit der allerletzten Hudson-Version gearbeitet haben.
Aber ich denke viel…
… viel früher als 2012 war es bei mir nicht.
Okay. Und wenn du dir jetzt so mal anschaust, was so die Forderungen sind von minimumcd.org, wie viel von dem hast du denn damals schon umgesetzt? Was steht denn da drin?
Die minimalen Aktivitäten sind Continuous Integration, eine Applikationspipeline, unveränderliche Artefakte, Rollback on Demand. Was hast du denn damals schon einfangen können?
Na gut, also wir haben damals angefangen, kontinuierlich…
… die Integration, das heißt schon JAR-Files bauen, die dann als WARP-gepackaged auch auf die Produktivsysteme gekommen sind. Also das waren letztendlich auch Artefakte, die dann nicht nochmal angefasst worden sind, irgendwie händisch bei den Tests auch in Testumgebungen automatisch deployed worden sind.
Das war ja letztendlich auch nur Kopieren auf dem Application-Server und der hat das dann schlauerweise gleich mit ausgepackt. War schon ganz okay, was das anging.
Eine Anwendungspipeline ging halt bis in die Testumgebung. Also alles, was QA-Umgebung, Prerelease und Produktiv anging, war halt alles händischen Deployments versehen. Wir hatten an der Stelle eine Continuous Delivery Pipeline, die halt bei Tests aufgehört hat.
Wir hatten produktionsähnliche Testumgebungen, also es waren vergleichbare Server, waren halt in anderen Netzbereichen, nicht von außen erreichbaren Netzbereichen.
An sich von der Middleware, von den Versionen der verwendeten Software und Co. sehr gleich. Bisschen weniger Hardware, bisschen weniger Datenbank-Performance, aber an sich schon vergleichbar zu den Produktionsumgebungen.
Ein Rollback ist so eine Sache. Gab es für alle Datenbank-Anpassungen halt nicht. Das war dann teilweise ein händischer Prozess.
Das heißt, wir haben halt nur auf der Testumgebung immer wieder die Datenbank.
Wir haben die Datenbank frisch aufgesetzt und halt getestet, ob die Schema-Anpassungen passen.
Und ja, eine Anwendungskonfiguration war in den Artefakten teilweise mit abgebildet, dass du von Umgebungsvariablen ausgelesen bestimmte Anpassungen automatisch in der Produktiv-Umgebung, in der QA-Umgebung entsprechend hattest.
Also das war schon ganz in Ordnung.
Also Minimum-CD, Minimum Viable Continuous Delivery.
Ja, kontinuierliche Integrationsformate.
In der Konfiguration war es mehr als in eine Produktionsumgebung auch zu deployen oder in eine QA-Umgebung zu deployen.
Aber zumindest die Artefakte waren stabil, nicht zum Anpassen.
Die Umgebungen waren vergleichbar und wir hatten auch keine Testdaten in irgendeiner Form oder andere Konfigurationen in den Produktiv-Artefakten enthalten.
Also diese waren halt dann auf den Systemen hinterlegt. War ganz okay.
Wie sah es bei euch aus?
Wie sah es bei euch aus in der Zeit?
Da warst du nicht als Entwickler, sondern als Tester aktiv, ne?
Genau, da war ich Tester und habe mir da auch wiederum halt aus purem Eigennutzen eine Pipeline gebaut, weil ich es irgendwie leid war,
dieselben Tests irgendwie zu Fuß zu machen oder auch nur zu Fuß anzustoßen.
Und entsprechend war das zumindest für mich viel mehr ein U-Boot alles.
Das habe ich halt irgendwie gemacht.
Ich kann mich auch erinnern, ich bin damals in der Abteilung auf gar nicht so viel Verständnis gestoßen.
Die haben alle nicht so ganz verstanden, was ich da eigentlich so mache und wieso eigentlich.
Das ist ja komisch.
Das ist ja komisch, so alles automatisiert und so.
Aber ich kann mich erinnern, dass es für mich halt irgendwie eine echte Erleuchtung war,
weil all die Dinge, von denen man immer redet, das schwimmt dich halt, das gibt dir Ellenbogenfreiheit,
um dich auf die wichtigen Dinge zu fokussieren, explorative Tests zu machen und so.
Das ist dann halt tatsächlich alles passiert.
Und das ganz viel von diesem täglichen Klein-Klein und so war dann halt weg.
Das war übrigens ganz interessant.
Ich habe das auch seinerzeit für akzeptiert.
Ich habe einen Akzeptanz-Test eingesetzt von Komponenten, die von außen kamen.
Wir haben da ein Spezial-Testsystem für Avionik-Komponenten gekauft von einem Zulieferer
und die haben mit ziemlich hoher Frequenz neue Versionen uns gegeben.
Nicht deswegen, weil die irgendwie so gut waren, sondern weil ständig irgendwas anderes schief ging
und dann mussten sie immer nachlegen und nochmal nachlegen und nochmal nachlegen.
Und ich musste dann immer mich nochmal vergewissern, dass das Testsystem überhaupt noch richtig getestet hat.
Und insofern habe ich mir dafür dann auch sehr viele…
Abnahmetests für Produkte von außen geschrieben, was, glaube ich, ein gewaltiger Wert war.
Wie war denn die Testabdeckung, Unit-Tests und ähnliches in dem Zeitraum bei euch?
Weil wenn ich mir das vor Augen führe, war halt sehr viel Entwickler-Tests und wenig wirklich automatisierte J-Unit und Co.
Ja, da musst du natürlich stark unterscheiden, weil das eigentliche Produkt, an dem ich gearbeitet habe damals,
das war ja Helikopter-Avionik.
Die war natürlich stark reglementiert, die war sicherheitskritisch.
Da gab es natürlich fixe Ziele für Testabdeckungen, wobei die hauptsächlich manuell erreicht wurden.
Da haben wir wochenlang an irgendwelchen Helikopter-Eingabegeräten gesessen und Tests durchgeklackert und so.
Aber diese Eingangstests, die ich da gemacht habe, die waren dann schon ziemlich massiv automatisiert.
Also da bin ich dann auch quasi das komplette API von diesem Testsystem durchgegangen und habe da,
gegen jeden Mist, Tests geschrieben, im Rahmen der Zeit, die ich so hatte.
Und wie gesagt, das hat sich sehr bezahlt gemacht und das weiß ich noch, das hat auch damals den Zulieferer irgendwie sehr aus dem Konzept gebracht,
weil die irgendwie nicht damit gerechnet haben, dass ich so schnell Feedback liefern konnte.
Die haben gedacht, die schmeißen mir was über den Zaun, dann bin ich erst mal ein paar Wochen beschäftigt damit.
Und dann irgendwie habe ich ihnen dann am nächsten Nachmittag aber schon eine Liste von neuen Defekten geschickt.
Und das hat so ein bisschen gedauert, bis sie das tatsächlich für sich auch als Plus wahrgenommen haben.
Du meinst, dass vorhin…
Ja, vorhin, wann wir dann bei Kultur ankommen, das ist ja dann schon Kommunikation, Kollaboration,
erste Aspekte, die auch unternehmensübergreifend dann mit Erwartungen und Co. zu tun haben.
Das sind ja schon die ersten Kulturaspekte, die wir an der Stelle haben.
Unternehmenskultur, Erwartungen, Feedback, Zeiträume, Feedbackschleifen, mit denen man dann leben muss
und wo man dann halt auch erst mal geschockt ist, dass man nach einem Tag statt nach einer Woche oder nach einem Monat Feedback bekommt.
Ja, das war auch interessant, weil zunächst haben die natürlich auch so ein bisschen irgendwie…
Wurden die dann so ein bisschen nervös.
Aber nachdem sie dann gemerkt haben, ich meine es ja gar nicht böse mit ihnen,
sind wir dann auch tatsächlich auf eine sehr schöne, produktive Arbeitsebene gekommen
und konnten dann halt wirklich zusammenarbeiten.
Die haben dann auch gemerkt, oh, es lohnt sich auch für uns, da zuzuhören und aufzupassen,
weil wir haben ja einen Verbündeten, der uns hilft, das Produkt besser zu machen.
Also in dieser Hinsicht war es echt toll und da hast du recht.
Das war so ein Kulturwandel, so ein bisschen durch die Hintertür.
Das hat auf einmal die ganze Dynamik mit diesem externen Zulieferer verschoben.
Auch wenn das ja, schau mal, damals war ich ja noch ein junger Hupfer
und wusste noch gar nicht so richtig, wie die ganze Bude läuft.
Das ist mir alles mehr so passiert.
Ja, aber es war gut, wenn das so läuft und funktioniert.
Jetzt haben wir ziemlich viel über unsere frühen Erfahrungen gesprochen,
so 2010er Jahre, 11, 12, 15 oder so.
Wie sieht es denn aktuell aus?
Hast du noch Projekte, in denen du Continuous Delivery einsetzt?
Oder was waren die letzten, wo du aktiv damit gearbeitet hast?
Puh, das ist eine ganz interessante Frage,
weil in einem gewissen Sinne schwingt dieses Thema jetzt natürlich immer mit.
Ich vermute, das wirst du mir dann auch bestätigen können.
Das ist zwar häufig jetzt nicht mehr die Ebene, auf der ich mit den Teams spreche,
die ich berate beispielsweise,
aber natürlich haben die alle im Hintergrund eine mehr oder weniger wirkungsvolle Automatisierung,
Continuous Integration, Continuous Deployment oder solche Dinge.
Und jetzt geht es vielmehr um die Frage,
können Sie dieses mächtige Werkzeug, das es jetzt ja umso mehr geworden ist
und auch in einem gewissen Sinne ein viel einfacheres Werkzeug,
können Sie das überhaupt noch gut einsetzen?
Insbesondere, glaube ich, weil auch die Komplexität zugenommen hat.
Falco, du und ich, wir arbeiten jetzt ja weniger in Projekten,
die von einem Team gestemmt werden,
sondern wo dann sehr schnell viele Teams drin sind.
Und das gibt natürlich dann ganz neue Hürden für die Art und Weise,
wie man mit CI-Systemen umgeht und wie man auch mit deren Feedback,
umgeht.
Das ist ja was, was auch in den Minimum-CD drin steht.
All feature work stops when the pipeline is red.
Das ist eine von diesen typischen Sachen, die sagen sich sehr leicht,
aber hältst du das dann echt durch?
Genau, also die Arbeit an den Features wird dann unterbrochen,
wenn es eine Warnmeldung gibt aus dem System.
Also wenn die Continuous Delivery Pipeline rot meldet.
Das finde ich sinnvoll und richtig,
wenn man sich als Team so weit auf die Technik einlässt,
dass man auch die Pipeline letztendlich davon abhängig macht.
Also die gesamte Deployment-Prozesskette davon entkoppelt,
dass jemand dort händisch irgendwas tut,
sondern die Pipeline so weit automatisiert hat,
dass eben auch sehr viele Tests,
sehr viele Überprüfungen dort stattfinden von statischer Code-Analyse
über Unit-Tests, Schnittstellen-Tests,
Deployment mit bestimmten Testumgebungen Ende-zu-Ende abgeprüft werden,
Verhalten abgeprüft wird bis hin zu Unterstützung von Produktivumgebungstests,
die vielleicht auch Teil oder ganz automatisiert sind.
Und wenn man diesen Grad der Abhängigkeit oder Integration,
muss ja nicht negativ belastet sein,
sondern den Grad der Integration erreicht hat,
dann ist es natürlich wichtig, dass die Pipeline kontinuierlich gut funktioniert,
damit dass halt auch jeder Check-In getestet werden kann,
dass auch nach jedem Merge entsprechend bis in die jeweiligen Umgebungen deployed wird.
Und dann ist es natürlich, ich sag jetzt fast lebensnotwendig,
oder ja, auf jeden Fall notwendig für das Team,
dass die Pipeline stabil läuft.
Und wenn es halt einen Fehler gibt, der integriert wurde durch irgendeinen Zutun,
sei es ein Update von einer Library, die man nutzt,
oder von einer neuen Funktionalität,
einen neuen Update des Quellcodes,
dann ist es halt auch notwendig, sicherzustellen, dass die Pipeline weiter funktioniert.
Darum, ja, ähnlich wie beim Toyota-Produktionssystem,
Fließband, wo das Andon-Band, also die kontinuierliche Produktion gestoppt wird,
wenn halt dort ein Qualitätsfehler auftritt,
ist es letztendlich eins zu eins zu sehen wie eine rot meldende Pipeline.
Ja, und das ist ganz interessant, wo ich dir so zugehört habe.
Mir scheint früher…
Als wir da ein bisschen kleinere Brötchen gebacken haben
und auch irgendwie vielleicht niemand so wirklich erwartet hat,
dass wir eine Pipeline haben oder so,
sondern wir hatten die halt, weil wir das für eine gute Idee hielten,
da war irgendwie, da war das alles viel weniger kritisch
und auch viel weniger kulturell und prozessmäßig unterfüttert.
Damals konntest du dich irgendwie viel mehr drauf versteifen,
dass so eine Pipeline halt irgendwie ein technisches Gebilde ist,
wo irgendwie Bytes durchfließen.
Aber wenn jetzt hier zum Beispiel steht,
all feature work stops when the pipeline is red,
dann ist das ja erstens.
Das ist erstmal wirklich eine Vereinbarung auf Prozessebene
und ist etwas, wozu man sich wirklich bekennen muss als Organisation oder als Team,
dass man sagt, ja, das ist ein Wert, den wir dafür richtig empfinden,
für wichtig empfinden, auch wenn er uns vielleicht bisweilen mal auf die Nerven geht.
Weil wir haben ja alle irgendwie, wir haben irgendwelche Verpflichtungen,
wir wollen liefern und dann sagen wir, nein, wir machen es richtig.
Das ist ganz interessant.
Also ich habe das Gefühl, dass dieses ganze Thema,
immer mehr, wie soll ich sagen, seine Tentakel ausstreckt in Richtung nach oben,
in Richtung Prozess, Organisation, Kultur,
obwohl es natürlich weiterhin seine Wurzel in, sagen wir mal,
einfachen technischen Vorgängen hat.
Jemand checkt was ein und dann laufen halt irgendwie Dinge.
Naja, letztendlich ist es ja ein sozio-technisches System mit Komponenten,
die vorrangig in der Vergangenheit vor Einsatz von Continuous Integration,
Continuous Testing manuell abgelaufen sind.
Und immer mehr in Richtung Automatisierung gehen.
Und dann hat man halt diese Integration, diese auch Abhängigkeit.
Und muss man sich um das System kümmern, wie auch da wieder in der Automobilproduktion am Fließband
gibt es halt bestimmte Prozesse, die mit großen Pressenwerken,
mit Robotern, Schweißstationen und Co verbunden sind.
Wenn das Presswerk kaputt ist, muss das auch reparieren.
Wenn da irgendwie Ausschuss produziert wird, bringt es dir nicht weiter, das Presswerk laufen zu lassen.
Oder wenn der Roboter nicht ordentlich geschmiert ist und dann Stück für Stück Schweißpunkte an den falschen Stellen setzt.
Kannst du das auch als Ausschussproduktionsmechanismus verstehen?
Oder du sagst halt, du kümmerst dich auch darum, dass die Roboter an der Stelle funktionieren.
Und letztendlich ist eins zu eins das gleiche wie in der Softwareentwicklung.
Wenn du halt Dinge automatisiert, musst du halt auch sicherstellen, dass die Automatisierung funktioniert.
Wenn du dich darauf verlässt, dass Testumgebungen zur Verfügung stehen,
und du darauf testen kannst, ist es genauso ein Teil der Continuous Delivery Pipeline,
wenn diese Umgebung nicht da ist, dass sie halt dann repariert wird.
Genauso wie das Continuous Deployment oder Continuous Delivery Steuerungssystem,
sei es immer noch ein Jenkins oder sei es irgendein Git-Pipeline oder ein GitHub-System
oder was auch immer da noch so im Einsatz ist.
Wenn diese nicht funktioniert, dann funktioniert die Lieferung der Software nicht.
Dann ist alles,
was ein Entwickler tut, Verschwendung und deswegen gleiche Vorgaben,
gleiche Prozesse wie in Lean Production Systems, muss es repariert werden.
Roboter kaputt, Roboter reparieren.
Ja, aber das ist eben, du sagst es so, als sei das quasi einfach Natur gegeben
und irgendwie Gesetzmäßigkeit und so passiert das.
Aber ich habe das halt auch schon anders erlebt.
Der einzige Kunde, den ich je gefeuert habe, weil ich gemerkt habe,
wir werden da nicht übereinkommen, die waren genau so, die haben gesagt, na ja,
seit vergangenem Sommer sind wir nicht mehr in der Lage, Software zu bauen, aber macht ja nichts.
Ist ja okay, dann haben sie halt keinen Wert darin gesehen.
Die Frage ist halt, wo liegt der Wert in einer Continuous Delivery Pipeline, wenn man sie nicht nutzt?
Man kann sie theoretisch abschalten und kann es wieder händisch machen.
Also wenn sie sagen, sie können letztendlich nicht über die Pipeline deployen.
Wie haben sie dann ein halbes Jahr gearbeitet?
Haben sie halbjährliche Releases und es war egal?
Gut, mag ja sein.
Ja, sie haben,
das war dann genau ihr Problem, dass sie dann nicht mehr releasen konnten.
Und dann haben sich so langsam irgendwie die Features aufgetürmt.
Und dann haben sie gemerkt, das ist irgendwie jetzt doch ungünstig.
Insofern ja, aber das finde ich, ist das Spannende an solchen Pipelines.
Und das ist, glaube ich, auch der Grund dafür, dass ich dieses Minimum CD so spannend finde.
Wenn du es ernst nimmst, was da drin steht, dass du jeden Tag das Gesamtsystem integrierst,
dass du dich verpflichtest, keine weitere Feature-Arbeit zu machen, wenn der Build fehlschlägt
oder wenn die Pipeline fehlschlägt oder sowas, dann zwingt dich das dazu, handwerklich sauber zu arbeiten.
Und dann wirst du natürlich auch, das mag am Anfang vielleicht auch wehtun,
wenn du noch technische Schulden oder Architekturschulden aufzuarbeiten hast oder sowas.
Natürlich ist das dann echt scheußlich.
Aber wenn du dich dann mal rausgearbeitet hast aus dieser Grube, die du dir selber gegraben hast über viele Jahre,
dann wirst du halt wirklich belohnt mit einem sehr sauber funktionierenden, sehr verlässlichen, entspannten System.
Ich wollte mal sagen,
einfach eine Abstraktionsebene wieder zurückgehen und sagen,
wir reden relativ allgemein über Minimum Viable Continuous Delivery, also das Minimum CD Vorgabe.
Wir haben viel über kontinuierliche Lieferung gesprochen.
Wir haben in dem Zusammenhang über kontinuierliche Integration gesprochen.
Und letztendlich ist der dritte Pfeiler, den wir ja mit,
wir haben ja an der deutschen Übersetzung, du viel, ich ein bisschen weniger gearbeitet.
Wenn wir uns
die drei Säulen anschauen, haben wir über zwei davon gesprochen.
Und lustigerweise bildet jede von den Säulen immer auch einen Link auf die nächste.
Das heißt eigentlich so ein Top-Down-Ansatz.
Kontinuierliche Lieferung baut auf auf kontinuierliche Integration und diese baut wiederum auf auf trunkbasierte Entwicklung.
Darüber haben wir noch gar nicht gesprochen.
Deswegen hätte ich jetzt gesagt, wie siehst du das?
Ist das letztendlich so?
Siehst du auch diese Abstraktionsebenen, die Stück für Stück aufeinander aufbauen?
Und wenn wir letztendlich bei
trunkbasierter Entwicklung sind, vielleicht als Folgefrage, ist das dann die Basis?
Oder gibt es noch einen tieferen Kern, den man vielleicht noch erwähnen müsste?
Zunächst mal vielleicht, um alle Zuhörer abzuholen, die jetzt sich ein bisschen wundern,
was eigentlich trunkbasierte Entwicklung ist.
Viele haben den Begriff vielleicht schon gehört, aber nur der Vollständigkeit halber.
Was steckt dahinter?
Dahinter steckt, dass man sich abkehrt von dem jahrelang oder jahrzehntelang verfolgten Ansatz,
dass man Branches hat, Feature-Branches hat.
In der Entwicklung befindliche Sachen,
in der Entwicklung
befindlichen Code erstmal in Quarantäne schickt und dann das zu einem späteren
Zeitpunkt zurück in die Mainline mergt, sodass man da in Ruhe entwickeln kann,
ohne dass man versehentlich die Arbeit seiner Kollegen kaputt macht,
den Bild kaputt macht oder so was.
Erst wenn es fertig ist, dann mergt man es wieder zurück in die Mainline.
Das hat man viele Jahre so gemacht.
Gibt es ja auch bekannte Exponenten, GitHub, Flow und was es alles gibt.
Und man ist aber darauf gekommen, dass das mehr Probleme schafft, als es löst,
weil es halt irgendwie für sehr viel Komplexität sorgt.
Du hast ganz viele
verschiedene Branches und dann musst du die mergen oder nicht mergen.
Und dann gibt es irgendwie ein Mods-Regelwerk und alles sowas.
Dann haben wir gesagt, das ist alles Mist.
Wir machen es uns einfach.
Wir sagen, es gibt nur die Mainline.
Jeder Entwickler, egal wer, bastelt an dem einen Hauptzweig der Entwicklung rum.
Und wie gehe ich jetzt damit um, dass da ja auch halbfertige Sachen drin sind,
die dann naturgemäß nicht gescheit funktionieren?
Die werden dann für Testzwecke oder sogar für Deploymentzwecke totgelegt über
Schalter im Code, also dann kann ich halbfertigen Code, kann ich einfach für
Produktions- oder Testzwecke abschalten und auf diese Weise sorge ich dafür, dass ich
niemals in dieses Problem der Integration komme, dass, wenn man so einen Branch hat,
der zu lange läuft und zu lange nicht integriert wird, irgendwann passen die nicht
mehr zusammen, die dividieren immer weiter und die Schmerzen werden immer größer.
Der Integration.
Also sagt man, wir machen gar keine Integration.
Wir arbeiten sowieso alle immer an derselben Sache.
Integration auf Quellcode-Ebene, richtig?
Genau, weil halt unterschiedliche Personen an unterschiedlichen Stellen arbeiten.
Und alte Stände und neue Stände entstehen, die dann, je länger solche Feature-Branches
gelebt haben, immer weiter divergieren über die Zeit.
Deswegen möglichst kurz.
Nichtsdestotrotz kenne ich immer noch den
Ansatz, Feature-Branches zu machen, die dann aber höchstens einen Tag alt sein dürfen.
Ist das immer noch im Rahmen von Trunk-basierter Entwicklung akzeptabel oder geht das nicht?
Also aus meiner Sicht schon.
Also schau, es ist ja immer die Frage, wie du es machst.
Du kannst ja auch, du kannst ja implizite
Branches haben, indem du dann Feature-Flag hast, dass du einfach niemals einschaltest.
Dann hast du diese Komplexität auch versteckt und du kannst genauso ins Messer laufen.
Das ist, glaube ich, etwas, was man nicht übersehen darf.
Die Komplexität ist die Komplexität.
Du darfst dir Mechanismen überlegen, wie du ihr begegnest.
Seien das Branches, seien das Feature-Switches oder was weiß ich was.
Aber die geht ja nicht weg, die Komplexität, sondern die ist nun mal da.
In der Tat, aus meiner Arbeit mit Embedded Systems sage ich sogar, es gibt immer noch
einen Wert von Feature-Branches.
Insbesondere langlaufenden, weil vielleicht habe ich einfach konkret mehrere
Versionen im Feld über lange Zeiten, die wurden ausgeliefert.
Verschiedene Hardware-Stände oder sowas, für die muss ich dann vielleicht
verschiedene Software-Sätze pflegen und vielleicht macht das einfach viel mehr
Sinn, die in langlebigen, im Sinne von jahrelang lebenden Branches abzubilden,
anstelle von irgendwie mit einem Wust von Feature-Flags.
Insofern, auch wenn viele Leute sagen, Branches sind irgendwie des Teufels.
Ich sage es mal so, wenn man sie vermeiden kann,
glaube ich, das ist eine gute Idee, sie zu vermeiden.
Aber ich bin da weniger strikt als andere Leute.
Ich sage, unter bestimmten Voraussetzungen
kann das das richtige Werkzeug sein, um der Komplexität zu begegnen.
Hat letztendlich ja seine Idee auch gehabt,
hat eine Zeit lang eine recht weite Verbreitung gehabt.
Und ich sehe auch einen Unterschied, ob wir über Versionen, die lange im Feld
unterwegs sind, über die man nachdenken und reden muss, sind wir immer noch bei der
Entwicklung und beim Betrieb.
Das sind ja zwei unterschiedliche Sichten auf das System.
Die Entwicklungen sind letztendlich das,
wo wir hier über trunk-basierte, mainline-basierte Entwicklungen reden, während
der Betrieb ja schon auch mehrere parallel zu betreibende Versionen auf
unterschiedlichen Umgebungen regional oder wo auch immer die Gründe dafür sind, dass
man verschiedene Umgebungen hat, eine nicht etablierte oder nicht geplante
Kommunikation für Updates over DR oder wo auch immer, wo die Schnittstellen an anderen
Systemen liegen, na klar braucht man da mehrere Versionen, die vielleicht live sind,
die man halt weiter pflegen muss, wo man dann aber nicht über eine Weiterentwicklung,
sondern eher eine Maintenance, also eine Pflegephase dann redet.
Klar ist es da sinnvoll, auch in der Versionskontrolle diese Versionen
griffbereit zu haben, um dann halt auch darauf gut testen und sie verwalten zu können.
Aber wir haben uns verzettelt, weil ich
fand deine Frage oder deine Beobachtung ganz spannend, dass da irgendwie Sachen
aufeinander aufbauen, dass ich sage, ich brauche trunk-based Development, damit ich
kontinuierliche Integration erfolgreich oder mit akzeptablem Aufwand betreiben kann.
Das brauche ich, damit ich continuous
Delivery mit akzeptablem Aufwand und akzeptablem Risiko betreiben kann.
Und dann was? Was ist dann?
Ich behaupte, da baut ihr jetzt noch mehr drauf auf.
Das bedeutet ja dann, dass ich mich wiederum in die Lage versetze, kurz
zyklisch zu iterieren, zusammenzuarbeiten, Feedback einzusammeln.
Genau, wobei das steht nicht mehr beim Minimum CD als Minimum Viable
Konzept in dem Dokument.
Letztendlich macht man all das genau, um schnell Kunden Feedback einarbeiten zu
können, um vielleicht auch Dinge zu beachten und zu realisieren, wie
Bugfixes mit einer hohen Testabdeckung, um nicht nochmal neue Fehler oder sowas
mit einzubauen, weil man halt gerade eine sehr schnelle Änderung irgendwo vorgenommen hat.
Und um letztendlich auch kleine Pakete deployen zu können, um zu sehen Ja, jetzt
haben wir eine Änderung, da ist vielleicht ein Fehler aufgetreten.
Wir müssen jetzt aber nicht die ganze Codebasis nach der Ursache durchsuchen,
sondern halt nur das, was seit dem letzten Produktiv Deployment, wo der Fehler noch
nicht drin war, geändert wurde.
Und all diese Vorteile hat man dadurch, dass man Continuous Delivery hat.
Zusätzlich natürlich auch die eingesparte
Arbeitszeit, dass man sich nicht hinsetzen muss und manuell durchtesten muss, dass
man sich nicht hinsetzen muss und vielleicht mehrere hundert oder mehrere tausend Server
aktualisieren muss mit der neuen Software Version, sondern dass man sich dann halt
genau da, wo viel Mühe quasi auftritt, sich die Zeit dann sparen kann und in
exploratives Testen investieren kann, in die Pflege der Plattform, der Deployment
Pipeline Zeit investiert und vielleicht auch eine Verbesserung, eine kontinuierliche
Verbesserung etabliert, für die man vorher möglicherweise keine Zeit hatte.
Das sind dann die Effekte, die man hat mit Continuous Delivery.
Deswegen reden wir drüber.
Aber es gibt
noch was anderes recht Spannendes, nämlich, wenn du jetzt versuchst, diese
Grundsätze einzuführen, dass du sagst, du hast produktionsähnliche Testumgebungen,
dass du sagst, du hast Rollback on Demand, dass du sagst, du machst Trunk Based
Development, lauter solche Sachen, dann ist das ganz häufig ein Prüfstein
für ganz viele andere Aspekte deiner Organisation oder deiner Prozesse.
Kannst du das denn überhaupt?
Oder hast du da, ich weiß auch nicht, ein
Change Advisory Board oder sowas, das dann von dir Dokumentation verlangt?
Oder hast du Deployment Prozesse, die dazu überhaupt nicht in der Lage sind, das abzubilden?
Oder sind deine Produkte so gebaut, dass du gar nicht in der Lage bist, mehr als eine Umgebung zu betreiben?
Und lauter solche Sachen.
Das ist ganz, ganz spannend.
Diese vergleichsweise harmlosen Forderungen, die da drinstehen.
All feature work stops when the pipeline is red.
Das ist immer so mein Lieblingsbeispiel, weil das so unmittelbar ist.
Da gibt es irgendwie nichts daran zu deuteln.
Es kommt meiner Beobachtung nach häufig vor, dass Organisationen dann ziemlich
schnell sagen müssen Ja, eigentlich eine gute Idee schaffen wir aber noch gar nicht.
Und das, finde ich, macht einen der großen
Werte aus von Minimum CD, dass es dir hilft, mit Hilfe von von diesen ziemlich
technisch orientierten Praktiken, dich selbst darauf hin zu überprüfen, ganz
konkret, wie gut du eigentlich schon aufgestellt bist in Bezug auf deine
Architektur, in Bezug auf deine Organisation, in Bezug auf deine Prozesse,
um überhaupt diesen Wunsch, den du wahrscheinlich hegst, Wirklichkeit werden zu lassen.
Das ist einfach ein wahnsinnig instruktives
Werk.
Werkzeug habe ich das Gefühl, wirklich zu einfach mal auszuprobieren.
Wie? Wie weit komme ich denn eigentlich mit
diesen vergleichsweise harmlosen Forderungen, die da stehen?
Kann ich die denn wirklich alle erfüllen?
Das heißt, man könnte es auch für ein Assessment einer Entwicklungs Umgebung
nutzen und halt gucken für jeden Punkt, der hier bei Continuous Delivery, bei
Continuous Integration und bei Trunk Based Development aufgezählt ist.
Haben wir den erfüllt?
Ist der bei uns in unserer Umgebung für unsere Entwickler, für unsere
Betriebsmannschaft, vielleicht unser DevOps Team auch wirklich etabliert?
Und wenn nicht, was müssen wir tun, um ihn zu erreichen?
Letztendlich interessanter Ansatz.
Finde ich gut, auch hier Minimum CD so so einzusetzen.
Ja, das ist das, wonach es schreit für mich, dass man sagt Okay, diese diese
Praktiken als solche, die sind natürlich, sind natürlich auf jeden Fall empfehlenswert.
Aber dass sie auch in ihrer Gesamtschau,
dass man die wirklich als als als Checkliste gerade zu nimmt, um zu sagen, wo
hakt es denn noch in meiner Organisation, wenn ich versuche, das umzusetzen?
Wo finde ich denn da Schwierigkeiten?
Und ganz bestimmt, ihr werdet irgendwo welche finden.
Ich meine, irgendwo gibt es immer Sachen, die besser laufen könnten oder so was.
Und die werden dadurch einfach sichtbar gemacht.
Und das halte ich für wahnsinnig wichtig.
Gerade du hast ja vorhin angesprochen Lean, Falco und industrielle Prozesse.
Und weißt du, es ist halt so, wenn du eine Presse hast, die nicht gut läuft, dann
kannst du sehen, dass sich davor irgendwie Paletten und Paletten von Blechen
stapeln, die nicht durch diese Presse laufen.
Bei Software ist das nicht der Fall.
Du kannst das alles nicht sehen.
Darum musst du dir Hilfsmittel suchen, die es deutlicher machen, wo die
Schwachpunkte des Prozesses sind, weil du dir halt nicht die Zehen anhauen kannst an Bugs.
Ja, direkt nicht.
Aber du kannst natürlich schon schauen, wo du anstelle dessen hinschaust.
Du kannst gucken, wie sich das Kundenfeedback zum Beispiel, wenn du einen
Support hast, in der Support-Bereich entwickelt, steigt da letztendlich die
Rückmeldung von Fehlern aus Kundensicht.
Du kannst genauso auch darauf achten, wenn du zum Beispiel ein Kanban-System hast,
was viele Entwickler haben, ob das jetzt im Tool wie das verbreitete Jira oder eine
andere Bug-Tracking- und Planungssoftware ist, kannst du natürlich schon schauen,
wie sieht das kontinuierliche Flussdiagramm aus, also Cumulated-Flow-Diagramm.
Wie sehen die Entwicklungen über die Zeit aus?
Staut sich hier irgendetwas?
Genau dafür sind ja solche Tools auch für die Entwicklung da.
Und wenn du echt mit physischen Kanban-Boards arbeitest in einem Entwicklungsteam, ob das
jetzt Scrum oder Kanban oder andere Ansätze sind, siehst du ja auch, wo Karten liegen bleiben.
Genau da visualisiert man es ja.
Genau. Aber wie gesagt, ich finde eben, dass solche Dinge wie Minimum-CD das dann auch
wirklich sichtbar machen und dich zwingen und dem Ganzen auch einen Kontext geben.
Das wird dann nicht bloß irgendwie eine intellektuelle Übung, so ja, wir machen
jetzt irgendwie, wir hängen da jetzt ein paar Kärtchen um oder so, sondern wir machen
das einfach, sondern wir wollen hier tatsächlich was erreichen.
Zum Beispiel, so wie es hier steht, Immutable Artifact, no human changes after commit.
Was heißt das auf Deutsch?
Dass du das, was du ins Versionskontrollsystem reingibst und was dann gebaut wird von der
Pipeline, dass du das hinterher nicht nochmal anfassen musst.
Das ist fertig.
Du hast die komplette Beschreibung dessen, was du da bauen willst, in irgendeiner
Weise in deinem Quellcode-Repository drin.
Sei das jetzt Quellcode oder sei das Grafiken oder sei das noch andere
Dinge. Und das ist eine von den Hürden, wo ganz viele Organisationen meiner
Erfahrung nach scheitern, wo die dann sagen, naja, 80% des Weges sind wir schon, aber
jetzt haben wir halt noch 20% harte Nüsse, die uns hindern.
Und wo man dann sich auch, wie soll ich sagen, wo es einem dann häufig im
Alltagsgeschäft passiert, dass man sagt, naja, ist halt irgendwie so.
Und wo dann solche Dinge wie Minimum-CD einem sehr gut dabei helfen können,
das einfach nochmal zu hinterfragen und zu sagen, muss das wirklich so sein?
Okay, es ist jetzt so, verstanden, aber muss es weiterhin so sein?
Oder können wir einen Weg finden, um uns da davon wegzubewegen von diesem Zustand?
Klar, also es ist eine schöne Checkliste, es ist ein schönes Werkzeug, um letztendlich
auch eine Vergleichbarkeit von unterschiedlichen Continuous Delivery
Umgebungen in gleichen Unternehmen, aber auch unternehmensübergreifend zu erreichen.
Also ein Assessment, Hilfsmittel.
Man könnte natürlich wirklich daraus dann auch ein haben wir und Checkbox oder
anderes daraus ableiten, finde ich ein ganz interessanter Ansatz.
Und wäre vielleicht auch eine hilfreiche Ergänzung für Minimum-CD.
Vielleicht machen wir auch da nochmal einen Vorschlag mit den Kollegen.
Ansonsten gefällt mir bei Minimum-CD auch, dass es ein paar Zusatzinfos gibt zu dem
minimal verfügbaren, tragfähigen Continuous Delivery Konzept, dass man halt auch sagen kann,
es gibt so Ergänzungen in Richtung in kleinen Paketen, in Small Badges zu arbeiten, dass man
halt auch noch ein bisschen Ausblick hat, wie man
eine Continuous Delivery Umgebung aufbauen kann, wo man über die Minimum-Anforderungen
auch hinausgehen kann mit vielen Quellen und Referenzen zu den Büchern von Dave Farley
oder Dave Farley mit Jess Humble zu Continuous Delivery, Pipeline Aufbau,
verschiedene andere Bücher, Refactoring Databases, Release It, um solche mal zu nennen,
oder Continuous Integration Zertifizierung von Martin Fowler oder Five Minute DevOps von Brian Finster,
wenn man schon von ihm spricht.
Von ihm reden Blogpost, wie man Produktionsprobleme mit DevOps und Continuous Delivery voranbringen kann.
Finde ich letztendlich eine schöne Ressource zum Thema DevOps, zum Thema auch auf der technischen Ebene zu starten,
sich mit Continuous Delivery auseinanderzusetzen und auch zu schauen, haben wir wirklich das Minimum von Continuous Delivery schon implementiert?
Sind wir an einigen Stellen vielleicht auch darüber hinaus?
Wenn ja, können wir uns vielleicht auch von den anderen Ressourcen, die relevant sind, variieren lassen.
Das Ganze auch noch zu erweitern.
Schöne Geschichte, guter Hinweis von Brian.
Gefällt mir auf jeden Fall als Quelle für Entwicklungsteams, für unternehmensübergreifende Arbeiten, auch im skalierten Umfeld sehr gut.
Ja, genau.
Zumal das ist eben auch toll, da sind dann auch schwierige Handreichungen drin.
Zum Beispiel, wie könnte es denn, was sind so die typischen Problemfelder?
Tests stehen nicht zur Verfügung oder werden nicht gemacht oder ein beliebter Fehler ist, dass man nicht gut genug darin ist,
Storys klein zu machen, Aufgaben klein zu schneiden.
Das ist etwas, was ich auch oft beobachte, dass Teams sich damit schwer tun, weil es halt mehr Sachen reinpacken ist halt immer leicht.
Sachen weglassen ist vergleichsweise viel schmerzhafter.
Und wenn du dann aber eben versuchst, dich an die Dinge von Minimum CD zu halten und das dann tatsächlich in Etat umzusetzen,
dann merkst du halt auch da, oh, jetzt gerate ich in Schwierigkeiten, meine Storys, die kriege ich gar nicht klein genug, die kriege ich gar nicht atomar genug.
Solche Dinge mehr.
Wie gesagt, ich finde, es ist ein wahnsinnig gutes Hilfsmittel, um sich zu zwingen, irgendwie zu den Grundlagen zurückzukehren und zu sagen Ja, was?
Wo müssen wir uns eigentlich verbessern?
Wo tut es denn jetzt eigentlich weh, wenn wir es wirklich mal versuchen?
Insofern ja, ganz, ganz tolles Projekt.
Ich bin irgendwie ganz, ganz begeistert davon.
Und ich finde, man kann sich einfach wahnsinnig viele Lehren daraus mitnehmen.
Und gleichzeitig ist es halt irgendwie auch schön, schön zugänglich und erreichbar.
Das ist jetzt kein ganzes Buch von Zeug, sondern es ist echt nur eine Webseite.
Die kannst du in fünf Minuten durchlesen und dann hast du aber fürs nächste halbe Jahr zu tun, wenn du das alles wirklich umsetzen willst.
Ja, genau. Also ist auch immer die Frage Was bringt einem jeder dieser Punkte, die dort aufgeführt sind?
Ist es wirklich notwendig, jeden Punkt von Minimum Viable City zu realisieren?
Aber es heißt ja nicht Wünsch dir was CD, sondern das heißt Minimum Viable CD.
Also da bin ich auch tatsächlich stur, weil sonst kommt man wieder in das rein, dass man sagt Ja, anderswo geht es.
Aber bei uns geht es irgendwie nicht, sondern da wäre ich dann tatsächlich strikt.
Kann man drüber nachdenken?
Kann man drüber reden, weil jedes Unternehmen ist anders.
Aber ich sehe natürlich auch den den Wert von Minimum Viable CD.
Ich meine, auch das ist eine Seite von Leuten, die viel Erfahrung mit Continuous Delivery haben, haben sich bewusst Gedanken gemacht.
Was ist wirklich Minimum Viable?
Also was ist wirklich tragfähig?
Und ja, vielleicht reicht es aber auch, eine nicht tragfähige Continuous Integration Umgebung erst einmal aufzusetzen, sich nicht zu überfordern, sich nicht.
Oder zumindest an irgendeiner Stelle anzufangen und das Ziel, vielleicht Minimum Viable, also eine tragfähige Continuous Deployment Umgebung aufzubauen, zu erreichen.
Das auf jeden Fall.
Also man muss da ja nicht auf der Stelle alle Maximalforderungen umsetzen, aber man muss dann schon irgendwie den Ehrgeiz haben, alle Punkte von der Liste abzuarbeiten.
Nicht jetzt, aber dereinst.
Das ist schon das Wichtige, weil sonst bringt man sich da.
Bin auch nicht der Meinung, dass es Maximalforderungen sind.
Das heißt ja nicht umsonst Minimum Viable CD, also minimal tragfähiges.
Aber vielleicht hat man halt noch kein tragfähiges Continuous Deployment, Continuous Delivery, sondern man hat halt erst mal einen Startpunkt oder man ist irgendwo mittendrin oder hat vielleicht den Fokus auf etwas anderes gesetzt.
Aber um genau diese Tragfähigkeit zu erreichen, die Viability im Englischen, dafür ist es aus meiner Sicht ein echt gutes Werkzeug.
Und auch hier hätte ich gesagt, die Kollegen sind sicherlich offen für Vorschläge und Veränderungen.
Also wenn man feststellt, dass man auch bei Minimum Viable CD noch etwas hinzufügen muss.
Damit es tragfähig wird oder man etwas wegnehmen kann und es trotzdem tragfähig bleibt, können wir sicherlich genauso darauf hinweisen, dass man mitarbeiten kann.
Gut. Was müssen wir noch beraten, Falco? Was haben wir vergessen?
Ja, also letztendlich gibt es einige Übersetzungen, hätte ich jetzt gesagt.
Also wenn jemand über Deutsch, Spanisch, Französisch, Italienisch, Portugiesisch und Finnisch hinaus noch eine Sprache beitragen will, rufen wir natürlich unsere Hörer dazu auf, mitzuwirken.
Oder bei einer Übersetzung Verbesserungen vorzunehmen, ist natürlich auch immer eine Option.
Das stimmt, auch das ist wahr. Gut.
Falco, dann würde ich sagen, haben wir Minimum CD soweit vorgestellt, wie wir es gerne wollten und hoffentlich einige Leute inspiriert, um diesen Weg noch ein paar Schritte weiter zu gehen.
Insofern vielen Dank für das schöne Gespräch und dass wir hier irgendwie uns mal über dieses Thema austauschen durften.
Und dann würde ich sagen, liebe Hörerinnen, liebe Hörer, bis bald. Lieber Falco auch, bis bald. Macht’s gut.
Ja, macht’s gut. Bis zum nächsten Mal.
Ciao.
Ciao.