Folge 13: Continuous Delivery

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

Inhalt laden

Continuous Delivery spielt bei DevOps ein zentrale Rolle. Der Experte Eberhard Wolff erläutert den Begriff sowie die Verbindung zu Microservices, die Vorteile und technische Fragestellungen.

In dieser Folge des Podcasts „DevOps auf die Ohren und ins Hirn“ diskutiert Dierk Söllner mit dem Gast Eberhard Wolf, einem Experten für Microservices und Continuous Delivery, die Konzepte und Praktiken rund um Continuous Delivery und deren Unterscheidung von DevOps. Wolf erklärt die organisatorischen und technischen Aspekte von Continuous Delivery, Continuous Integration und Continuous Deployment, deren Bezug zum Agile Manifest und wie diese Konzepte die Softwareentwicklung und -auslieferung beeinflussen. Der Podcast geht auch auf die Herausforderungen und Potenziale von Microservices in Verbindung mit Continuous Delivery ein und diskutiert wichtige Studien und Literatur in diesem Bereich.

Inhalt

  • DevOps and Continuous Delivery: Unterschiede und Zusammenhänge
  • Continuous Delivery: Konzepte, Praktiken und deren Bedeutung
  • Continuous Integration vs. Continuous Deployment: Technische Details und Abgrenzungen
  • Microservices: Rolle und Bedeutung für Continuous Delivery
  • Herausforderungen und Potenziale: Bezug auf Microservices und größere Software-Projekte
  • Wichtige Studien und Literatur: Überblick und Empfehlungen
  • Testing in Continuous Delivery: Bedeutung von automatisierten und manuellen Tests

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söll.
Hallo und herzlich willkommen zu einer neuen Podcast-Folge DevOps auf die Ohren und ins Hirn.
Wir haben heute das Thema Continuous Delivery und haben zu Gast den Eberhard Wolf.
Eberhard Wolf hatten wir schon im letzten Jahr zu Gast zum Thema Microservices und Eberhard Wolf ist Experte für das Thema Microservices, für das Thema Continuous Delivery.
Insofern freue ich mich, dass ich ihn hier zu Gast habe und wie immer beginnen wir mit der Vorstellung.
Eberhard, ich würde sagen, stell dich einfach mal ganz kurz vor und dann kommt ja bei uns im Podcast immer die Frage nach der Definition von DevOps.
Das heißt, wie verstehst du, wie würdest du DevOps beschreiben?
Eberhard, bitte sehr.
Ja, danke für die Einladung.
Mein Name ist Eberhard Wolf.
Ich arbeite für die Firma InnoQ.
InnoQ hat 120 Mitarbeiter über Deutschland und die Schweiz verteilt.
Wir machen im Wesentlichen Software-Projekte.
Ich bin ein bisschen eine Ausnahme.
Das heißt, ich laufe rum und mache vor allem Consulting, Training, bin auch auf ein paar Konferenzen und habe Bücher geschrieben.
Unter anderem ein Buch über Continuous Delivery.
Das ist mittlerweile in der zweiten Auflage.
Und mittlerweile zwei Bücher über Microservices.
Das Microservices-Buch, das ist mehr so Architektur.
Und zum anderen das Microservices-Praxis-Buch, das ist mehr so über Technologien.
Genau.
Die Definition von DevOps.
Also nach meinem Dafürhalten ist das erstmal etwas Organisatorisches.
Das heißt, es geht nicht unbedingt darum, Technologien zu machen oder so etwas wie Continuous Delivery ist für mich da auch ein getrenntes Thema.
Und was der Name hat schon sagt, ist, dass eben Dev.
Also Entwicklung und Ops, Operations, Betrieb zusammenwächst zu einem.
Und das bedeutet für mich in erster Linie eine stärkere Kollaboration.
Also das bedeutet nicht unbedingt, dass die jetzt im Organisationsdiagramm eine Einheit sind.
Aber die müssen halt eben zusammenarbeiten und halt gemeinsam versuchen, Ziele zu erreichen.
Und damit steht eben im Mittelpunkt auch der Abbau von Silos.
Was eben insbesondere bedeutet, dass ein DevOps-Ingenieur, den es ja neuerdings irgendwie gibt,
eigentlich ein Widerspruch in sich ist.
Also die Idee ist halt, dass man Dev-Ingenieurs hat und Ops-Ingenieurs, die enger zusammenarbeiten.
Das ist eigentlich das Ziel bei der ganzen Veranstaltung.
Sehr schön.
Ja, ich glaube, ich erinnere mich, das war beim Microservices auch, wie ich finde, eine sehr, sehr schöne Darstellung, als du das ähnlich dargestellt hast.
Habe ich das eben richtig verstanden?
Du hast gesagt, dass DevOps und Continuous Delivery im Prinzip zwei unterschiedliche Paar Schuhe sind.
Also DevOps siehst du eher kulturell und Continuous Delivery.
Dann eher technisch.
Das würde ich so nicht unbedingt sagen.
Also für mich, es sind einfach unterschiedliche Dinge.
So Continuous Delivery bedeutet, dass ich kontinuierlich Software ausliefere.
Das sagt ja der Name schon.
Das hat einen sehr starken Bezug zu dem Agile Manifest.
Also in dem Prinzipien des Agile Manifest steht eben auch drin, dass das Ziel der ganzen Veranstaltung ist,
kontinuierlich wertvolle Software auszuliefern.
Da steht also wirklich Continuous Delivery im englischen Original.
Und das impliziert ja jetzt nicht erstmal irgendeine Art von Organisation.
Das heißt, da steht irgendwie nicht, Betrieb und Entwicklung arbeiten zusammen.
Natürlich ergeben sich da Berührungspunkte.
Also es ist eben so, dass sinnvollerweise Betrieb und Entwicklung zusammenarbeiten müssen,
um kontinuierlich Software auszuliefern.
Das geht eigentlich nicht anders.
Aber das sind eben zwei unterschiedliche Sachen.
Es ist einmal die kontinuierliche Auslieferung von Software.
Und zum anderen ein Organisationsmodell.
Und ehrlich gesagt finde ich das immer ein bisschen schade, wenn die Sachen halt vermischt werden,
weil eben die sprachliche Präzision eigentlich schon, glaube ich, ein wichtiges Thema bei uns in der Branche sein sollte.
Das heißt, Continuous Delivery, sagst du, kommt aus dem Agilen oder bezieht sich auf die agilen Werte, auf das Agile Manifest.
Ich habe noch so zwei andere Begriffe, die man da vielleicht noch ein bisschen reinbringen könnte,
gerade weil du ja sagst, sprachliche Feinheit, Genauigkeit.
Continuous Integration und Continuous Deployment.
Wie kann man das mit dem Continuous Delivery zusammenbringen?
Genau, also Continuous Integration bedeutet, dass immer alle Änderungen in der Software möglichst kontinuierlich integriert werden.
Das heißt, wenn ich einen Commit mache, sollte das mit allen anderen Commits zusammen integriert werden, getestet werden und dann anschließend eben ein Software Stand entstehen.
Da gibt es eine andere Technik, die sich davon auswirkt.
Davon deutlich abhebt.
Das sind Feature Branches.
Feature Branches versuchen gerade das Gegenteil.
Feature Branches versuchen eben die Integration bestimmter Features aufzuheben bis zu einem bestimmten Zeitpunkt, an dem ich das dann eben alles integriere.
Das bedeutet nicht unbedingt, dass jetzt Feature Branches nicht funktionieren oder das Continuous Integration nicht funktioniert.
Das sind eben zwei alternative Verfahren, mit denen ich Software entwickeln kann.
Und beide funktionieren halt.
In bestimmten Projekten, sodass man da eben das eine oder das andere machen kann an der Stelle.
Continuous Integration ist historisch älter, also ist eine Reaktion darauf, dass eben in vielen Projekten Software entwickelt worden ist,
dann nach einiger Zeit die Änderungen aus den verschiedenen Quellen integriert worden sind und man dabei halt festgestellt hat,
naja, das dauert erstmal, bis man das zum Kompatieren bringt, das dauert erstmal, bis man die Tests alle zusammen zum Laufen bringt und so weiter und so weiter.
Und da war die Idee eben, das früher zu machen und eben eigentlich ständig.
Das ist genau die Idee von Continuous Integration.
Die Beziehung zu Continuous Delivery ist, dass man dann diese Continuous Integration Pipeline, die also die Softwarestände nimmt, auscheckt und durchkompatiert und testet.
Und zwar eben alle Änderungen, nicht etwa nur die von einem Branch.
Dass man das dann letztendlich logisch verlängert bis hin in Produktion.
Und dort.
Und dort hat man dann eben eine Continuous Delivery Pipeline, die die Änderungen nimmt und eben bis in Produktion durchschleust.
Das ist für mich der Unterschied.
Also Continuous Delivery ist eben sozusagen die Verlängerung von Continuous Integration.
Und bei Continuous Delivery würde ich auch argumentieren, dass ab einer bestimmten Geschwindigkeit man eigentlich nicht mehr wirklich mit Feature Branches arbeiten kann,
weil die Integrationsprozesse dafür zu lange dauern.
Also wenn ich halt versuche, öfter pro Tag zu deployen.
Dann ist die Zeit, die halt dabei draufgeht, ein Feature Branch zu integrieren, möglicherweise so lang, dass ich das nicht mehr ernsthaft tun kann.
Also ab einer bestimmten Geschwindigkeit muss ich wahrscheinlich eben echtes Continuous Integration machen, um Continuous Delivery zu machen.
Aber ich würde grundsätzlich nicht Probleme lösen, die ich nicht habe.
Von daher muss man eben schauen, wie das in der jeweiligen Umgebung funktioniert.
Der andere Begriff, den du eingebracht hast, ist Continuous Deployment.
Das ist tatsächlich nach dem, wie es definiert ist, etwas anders.
Das ist tatsächlich nach dem, wie es definiert ist, etwas anders.
Der Unterschied ist, dass ich bei Continuous Deployment tatsächlich jede Änderung in Produktion bringe.
Bei Continuous Delivery ist das nicht unbedingt so.
Da ist es eben so, dass ich kontinuierlich irgendwie neue Softwarestände in Produktion bringe.
Es ist nicht gesagt, dass ich jetzt jeden in Produktion bringen muss.
Ich würde halt denken, dass es so sein sollte, dass man im Prinzip jeden in Produktion bringen könnte.
Aber man kann sich natürlich dagegen entscheiden.
Bei Continuous Deployment bringt man tatsächlich jede Änderung in Produktion.
Das hat noch, glaube ich, ein paar weitere Konsequenzen.
Beispielsweise bedeutet es eben, dass die Software-Entwickler nochmal ganz anders mit ihren Änderungen umgehen müssen,
weil sie ja wissen, dass diese Änderung in Produktion geht.
Wenn also die Continuous Delivery Pipeline durchläuft, geht die Software eben in Produktion.
Und da muss man dann eben noch verantwortungsvoller mit der ganzen Geschichte umgehen,
als das der Fall wäre in einem anderen Continuous Delivery Szenario.
Sehr schön.
Ja, das heißt, wenn ich das so aus meiner Sicht interpretiere, ich bin ja kein Techniker,
ich bin ja eher der Betriebswirt, dann erfordert Continuous Deployment einen höheren Reifegrad
bei den Entwicklern und wahrscheinlich auch in der gesamten Organisation, richtig?
Ja, also du stellst jetzt in gewisser Weise einen Kausalitätszusammenhang her und sagst,
naja, wenn ich nicht reif bin, kann ich nicht Continuous Deployment machen.
Das hat natürlich was für sich.
Man kann es auch umgekehrt sagen.
Wenn ich Continuous Deployment mache, werde ich einen höheren Reifegrad erreichen,
weil ich eben dort ganz anders davorstehe und ganz anders inzentiviert bin.
Also das ist ja ein bisschen die Idee, die hinter Continuous Integration, Continuous Delivery und auch Continuous Deployment steht.
Da gibt es diesen englischen Satz von
Also wenn es halt weh tut, mache es häufiger und sorge dafür, dass die Probleme früher auffallen.
Und der Hintergrund ist dort, dass man nicht jetzt in einem Meer von Schmerzen enden soll,
sondern dass man dadurch, dass die Sachen früher gemacht werden und früher auffallen,
man früher Fehler eliminieren kann und halt zu einem besseren Reifegrad des Prozesses kommt.
Und an der Stelle, wo ich sage, dass jede Änderung eben in Produktion geht,
werde ich einen Prozess erzeugen müssen, der halt einen anderen Reifegrad hat.
Und dadurch kann das eben beschleunigt werden.
Natürlich ist es so, wenn man jetzt in der Produktion geht,
wenn man jetzt sagt, okay, wir haben überhaupt keine vernünftigen Tests,
wir machen Continuous Deployment, das ist vielleicht super optimal,
aber es wird eben dadurch eine starke Inzentivierung entstehen,
eben tatsächlich kontinuierlich zu deployen und auch automatisierte Tests zu haben,
die einen erlauben, das überhaupt zu tun.
Und dadurch wird daraus, glaube ich, ein Schuh.
Du hast es eben schon angesprochen, so Sinn und Unsinn, Vorteile von Continuous Delivery.
Also warum sollte man denn deiner Meinung nach Continuous Delivery machen,
und wo gibt es Schwierigkeiten, wo gibt es Probleme, die man dann beachten sollte?
Ja, also die Frage nach der Motivation von Continuous Delivery, finde ich, ist eine total spannende.
Eine Antwort, die halt auf der Hand liegt, ist, ich mache Continuous Delivery,
weil ich schneller Software in Produktion bringen will.
Und dadurch kann ich ein besseres Time-to-Market erreichen.
Und dadurch wird sozusagen an der Stelle alles gut.
Die Argumentation hat auch was für sich.
Und sie hat ein paar, nach meinem Empfinden, Schwierigkeiten,
weil wenn ich jetzt mehrmals pro Tag deploye,
ich weiß nicht, ob man halt tatsächlich mehrmals pro Tag neue Features ausliefern möchte.
Und die andere Geschichte ist, also ich weiß nicht, wie es anderen geht,
aber bei mir ist es so, dass ich fast jeden Morgen auf meinem Mobiltelefon neue Software installiere,
weil irgendwelche Apps geupdatet worden sind.
Und es ist eigentlich selten so, dass mir neue Features tatsächlich auffallen.
Und der dritte Punkt ist dann Time-to-Market.
Das ist eben so eine Geschichte, die Management, Product Owner und solche Leute halt interessiert
oder interessieren sollte.
In der Praxis tut sie das bedauerlicherweise oft nicht, weil zum Beispiel solche Sachen anstehen,
dass man sagt, naja, die Kunden wollen gar nicht so oft neue Software deployen
oder wir müssen sie halt schulen, was in gewisser Weise bizarr ist,
weil eigentlich lebt die Software durch die Features und dadurch sollte man einen Vorteil bekommen.
So.
Ja, so stellt sich die Frage, ob man da andere Vorteile noch außerdem irgendwie realisieren kann.
Und ich muss gestehen, ich habe eigentlich mit Continuous Delivery angefangen zu beschäftigen
und in der Folge auch mit Microservices, weil ich der Meinung war, dass diese Mechanismen die Mechanismen sind,
die uns versprechen, dass wir noch produktiver und noch besser werden bei der Softwareentwicklung ganz allgemein.
Und mittlerweile ist es so, dass man das auch tatsächlich nachweisen kann,
oder sehr gute Indizien dafür hat.
Es gibt diese State-of-DevOps-Studie und die behauptet jetzt,
naja, wenn ich kontinuierlich deploye, und zwar mehrmals pro Tag,
im Gegensatz zu einmal alle paar Wochen oder einmal pro Monat,
was ja auch schon relativ aggressiv ist,
wenn ich also mehrmals pro Tag deploye, dann kann ich deutliche Vorteile erreichen,
nicht nur in der Lead-Time, also bis zur Änderung,
produktiv ist, sondern auch in der Stabilität und der Zuverlässigkeit der Deployments,
in der Zeit, die ich benötige, bis ein System wieder funktioniert und ich kann sogar,
das haben dort die Statistiken ergeben, mehr Zeit aufwenden, um neue Features zu implementieren.
So, und das, also diese Studie basiert halt auf einer Umfrage, diese Umfrage hat,
ich weiß nicht, ich glaube, also hat ein paar tausend Teilnehmer gehabt,
so dass es da eine relativ umfängliche statistische Grundlage gibt,
das hat die Nicole Fersgreen im Wesentlichen gemacht, die hat einen Doktor,
hat das also wissenschaftlich begleitet, und die anderen beiden, die daran beteiligt waren,
waren Jess Humble und Jean Kim, die ja auch im DevOps-Bereich ganz bekannt sind,
Jess Humble hat eben das Continuous Delivery Buch geschrieben, das ursprüngliche, mitgeschrieben,
und dadurch können wir jetzt mittlerweile eigentlich sagen, naja, wir haben dort generell,
große Produktivitätsvorteile, wenn wir Software kontinuierlich ausliefern,
und zwar eben tatsächlich mehrmals pro Tag, und das finde ich ist halt ein relativ starkes Argument an der Stelle,
in diesen Bereich tatsächlich zu investieren, und auf der anderen Seite muss man halt sagen,
wenn man jemandem halt mal die Frage stellt, naja, was ist denn nun weniger risikobehaftet,
was wird weniger häufig schiefgehen, Quartalsrelease oder mehrere Releases pro Tag,
kommen diese Antworten sowieso, also intuitiv ist das offensichtlich klar,
dass man mit mehreren Releases pro Tag weniger Risiko fährt und insgesamt besser aufgestellt ist,
aber mittlerweile haben wir eben, wie gesagt, auch einen statistischen Datensatz, der das eben belegt,
und das ist für mich ein ziemlich starkes Indiz dafür, dass man das generell tun möchte,
also dass man halt an der Stelle einen relativ guten Hebel hat, um insgesamt produktiv zu sein,
produktiver, besser und sicherer zu werden, ganz abgesehen davon, dass man eben abends nach Hause gehen kann
und sagen kann, okay, ich habe halt ein paar mal Software deployed, und das ist, glaube ich, auch eine deutlich bessere,
also ist, glaube ich, eine deutlich bessere Herangehensweise, als wenn man sagt,
ja, nächstes Wochenende geht es wieder darum, Software in Produktion zu bringen,
ich kann das ganze Wochenende irgendwie abschreiben und habe irgendwie mega Stress,
also ich glaube, dass das eben auch an der Stelle einfach vorteilhaft ist.
Ja, Pampi hat ja gefragt, wo gibt es Probleme, wo gibt es mögliche Nachteile,
oder Herausforderungen gibt es nicht auch in dem Bereich, den ich mir so vorstellen kann,
SAP oder Oracle, also mit großen, althergebrachten, monolithischen Systemen,
geht das dort auch, das Continuous Delivery umzusetzen?
Das ist eine sehr, sehr gute Frage. Ich muss gestehen, du fragst ja konkret nach SAP,
im SAP-Umfeld bin ich mir unsicher. Es scheint so zu sein, dass es dort Möglichkeiten gibt,
zumindest habe ich das eben in einigen Projekten aus der Ferne gesehen,
tatsächlich auch relativ schnell und kontinuierlich Software in Produktion zu bringen,
aber wie gesagt, ich bin da halt kein Experte.
Ansonsten ist es so, dass du da eigentlich, glaube ich, nach meinem Empfinden,
wichtigen Punkt ansprichst, auch eine Geschichte, die ja durchaus im Kundenszenario passiert,
also ich habe dort irgendwie diese Software, diese Software wird im Moment so was wie sechs Wochen getestet,
sie wird irgendwie an einem Wochenende deployed und das ist ja etwas, was so ungewöhnlich gar nicht ist.
So, wenn man jetzt sagt, was eben in solchen Szenarien durchaus vorkommt,
man möchte mehrmals pro Tag deployen, dann ist die Frage, wie kommt man da hin?
So, und dann kann man halt irgendwie ausrechnen, ja, ich brauche halt irgendwie ein, zwei Größenordnungen,
also Faktor 100 oder sowas muss ich schneller werden bei Tests oder auch eben beim Deployment.
Da kann man sich überlegen, also am Wochenende sind 48 Stunden,
wenn ich mehrmals pro Tag deployen will, wie viel muss das Deployment schneller werden?
Und noch deutlich schlimmer, sechs Wochen Tests sind eben 30 Arbeitstage,
wenn ich mehrmals pro Tag deployen will, komme ich da tatsächlich eben auf so einen Faktor wie 100 oder so,
wenn ich das eben auf einen Dritteltag runterbekommen will.
So, und an der Stelle ist nach meinem Empfinden die Stellschraube, um die es geht, das System klein zu hacken
und zu sagen, wir haben kleine, unabhängig deploybare Einheiten und das sind eben genau,
das sind eben Microservices, weswegen es eben dort eine Architektur,
also weswegen ich mich eben auch mit der Architektur beschäftigt habe,
weil das eben etwas ist, was man eigentlich machen muss, ab einer bestimmten Größenordnung,
um Continuous Delivery zu erreichen.
Und umgekehrt, also Microservices sind halt ein Hype, sodass man eben durchaus fragen kann,
muss ich das eigentlich tun?
Mir fehlt in so einem Szenario, wie ich es gerade beschrieben habe, sechs Wochen Tests, ein Wochenende Deployment,
die Idee, wie ich sowas, wie ich mehrmals pro Tag deployen kann, ohne die Architektur zu ändern.
Also jenseits des Hypes sehe ich nicht, wie ich das hinbekommen soll, ohne Microservices einzusetzen.
Und der dritte Aspekt ist vielleicht, das impliziert eben auch, dass Microservices unabhängig deploybar sein müssen.
Also ich gewinne ja nichts, wenn ich sage, ja, ich habe da halt einzelne Dinger, die in Docker-Containern laufen
und dann habe ich eine große Continuous Delivery Pipeline, die eben alle diese Sachen zusammen deployt.
Dann habe ich mir eben an der Stelle den Vorteil genau verschenkt.
Und das kann relativ schnell der Fall sein.
Also wenn ich jetzt zum Beispiel sage, ja, ich möchte die ganzen Sachen Ende zu Ende testen,
dann komme ich eben sehr schnell darauf, dass ich diese sechs Wochen, die ich halt vielleicht bei einem Monolithen habe,
gar nicht so sehr beschneiden kann.
Und dann habe ich eben das nächste Problem.
Und aus dem Grund ist eben genau dieses getrennte Deployment und insbesondere eben auch die getrennte Testbarkeit,
die sich daraus ergibt, eine wichtige Eigenschaft von Microservices.
Und Microservices sind eben eine wichtige Eigenschaft,
eben eine wichtige Maßnahme, um vernünftig oft zu deployen.
Und eben diese Bereiche, wo die DevOps-Studie sagt, wo man eigentlich hin möchte,
also mehrmals pro Tag, sind nach meinem Empfinden nicht erreichbar,
wenn man nicht kleine Deployment-Einheiten hat, also eben Microservices oder sowas.
Ja, okay, das heißt eigentlich Microservices als wichtige oder fast zwingende Voraussetzung
oder notwendige Voraussetzung für Continuous Delivery.
Ab einer bestimmten Geschwindigkeit, die man aber eigentlich erreichen will, genau.
Sehr schön. Ja, du hast das Thema eben schon angesprochen.
Microservices und Continuous Delivery sind ja auch die Themen deiner beiden Bücher
und an sich auch deine Arbeitsthemen.
Wo würdest du diese noch Zusammenhänge sehen zwischen diesen beiden Begriffen
oder zwischen diesen beiden Ansätzen, außer dem, was du eben schon ausgeführt hast?
Ja, also was ich jetzt schon gesagt habe, ist, wenn ich Continuous Delivery umsetzen will,
muss ich eigentlich Microservices machen.
Das gilt auch ein bisschen umgekehrt.
Also es macht wenig Sinn, dass ich Microservices habe
und keine automatisierten Continuous Delivery Pipelines,
weil ich bei der großen Menge an Systemen, die ich mit Microservices habe,
ohne Automatisierung die Sachen nicht mehr vernünftig in Produktion bekommen kann.
Also das bedingt sich, glaube ich, gegenseitig.
Da gibt es dann halt auch irgendwie die Idee, dass man sagt,
ja, wenn du halt eine bestimmte Reifegrad in Continuous Delivery nicht erreicht hast,
dann solltest du nicht Microservices machen.
Da muss ich gestehen, das kaufe ich nicht.
Weil das bedeutet, dass ich eigentlich in so einer Art Deadlock ende.
Also ich sage dann halt, okay, ich kann nicht Microservices machen,
weil ich bin ja nicht Continuous Delivery reif
und ich kann nicht Continuous Delivery machen,
weil ich habe ja diesen blöden Deployment-Monolithen.
Meiner Ansicht nach ist es so, dass man mindestens den ersten Microservice, den man baut,
also ich würde anfangen, das ist das typische Szenario aus einem existierenden monolithischen System,
einen Microservice rausschneiden.
Und da ist jetzt irgendwie die Barriere nicht so super hoch,
weil also der Betrieb, den ich habe, wird dazu in der Lage sein, so ein System erstmal zu betreiben.
Also die können Systeme betreiben.
Die können das nicht in voller Schönheit.
Aber ich kriege halt sicherlich jetzt ein zusätzliches System erstmal in Produktion.
So, und dann würde ich eben parallel zwei Handlungsstränge aufmachen.
Zum einen eben den Handlungsstrang, der sagt,
wir bauen diesen Microservice.
Und zum anderen der Handlungsstrang, der irgendwie sagt,
wir bauen eine vernünftige Umgebung,
in der wir auch dann später eine Vielzahl von Microservices betreiben können.
Und das ist für mich halt auch wichtig,
weil ich sonst Gefahr laufe,
dass ich sehr viel Geld investiere in eine Infrastruktur,
die ich dann aber nicht vernünftig benutzen kann
oder nicht vernünftig ausnutzen kann oder so etwas.
Und deswegen würde ich eben genau an dieser Stelle versuchen,
diese beiden Aufgaben zu parallelisieren.
Und das sind eben auch,
und das sind eben auch Prozesse,
die sich gegenseitig befruchten.
Also ein Microservice eben,
für ein Microservice den Continuous Delivery Pipeline aufzubauen,
ist eben einfacher als die für einen Monolithen.
Also sollte ich eben diese beiden Sachen nach meinem Empfinden parallel angehen.
Ja, Hand in Hand bedingt sich dann wahrscheinlich auch.
Jawohl.
Du hast eben schon so ein, zwei Tools genannt.
Das wird auch ja immer gerne nachgefragt.
Mit welchen Tools arbeitet man dann?
Insofern gibt es,
Docker hast du genannt,
gibt es noch andere Tools, wo du sagst,
die sind einfach, die sind gerade State of the Art
und da sollte man einfach Bescheid wissen.
Und was haben die für Auswirkungen auf Continuous Delivery?
Ja, das hängt halt ein bisschen davon ab,
wie man Continuous Delivery interpretiert.
Und wenn wir jetzt bei meinem Beispiel bleiben,
von dem ich vorhin sprach,
also sechs Wochen Test, zwei Wochen irgendwie,
zwei Tage Deployen.
In der Continuous Delivery Diskussion wird häufig
das Thema Continuous Delivery mit einer Deployment Automatisierung gleichgesetzt.
Wenn ich jetzt in diesem Szenario
eine Deployment Automatisierung ansetze,
setze ich bei diesen zwei Tagen an.
Und das hat offensichtlich nicht so sonderlich viel Potenzial.
Und auch ansonsten würde ich eben sagen,
wenn ich mich hinstellen würde und sagen würde,
hey, hier ist ein Bugfix, der muss sofort raus.
Dann wird er auch relativ schnell in Produktion sein.
Also das wird nicht zwei Tage dauern.
Das wäre unwahrscheinlich.
Das heißt, die Frage ist, was ist eigentlich das Problem?
Und die Antwort ist meiner Ansicht nach,
ich habe nicht genügend Vertrauen in ein neues Stück Software.
Das ist genau das, was bei einem Bugfix gerade nicht der Fall ist.
Weil beim Bugfix weiß ich, da gibt es einen Fehler.
Und das neue Stück Software ist sehr präzise so zugeschnitten,
dass eben einfach nur dieser Fehler raus ist,
sodass ich Vertrauen habe, dass sich die Situation auf jeden Fall verbessert.
Und dann kriege ich das Zeug auch schneller in Produktion.
Das heißt, die Werkzeugfrage ist meiner Ansicht nach in erster Linie eine Frage nach Testing.
Also wie kriege ich das Zeug getestet?
Und dann gibt es noch eine andere Komponente, die glaube ich wichtig ist,
die halt auch an einigen Stellen übersehen wird.
Also wir könnten sagen, ich will eigentlich eine Continuous Delivery Pipeline aufbauen.
Ich brauche ein Werkzeug, um diese Continuous Delivery Pipeline zu automatisieren.
Und dann brauche ich eine Deployment Automatisierung und dann hat sich das,
dann ist das Zeug in Produktion und ich bin fertig.
So nochmal, das Problem ist nicht meiner Ansicht nach häufig das Deployment zu automatisieren,
sondern dafür zu sorgen, dass ich mehr Vertrauen in das Deployment habe.
So deswegen teste ich.
So und jetzt gibt es den Bereich von so Kapazitätstests.
Und bei Kapazitätstests geht es eben darum, zu schauen, ob die Software schnell genug ist.
Und dazu brauche ich eine vernünftige produktionsnahe Umgebung.
Dazu brauche ich vernünftige produktionsnahe Daten.
Dafür brauche ich vernünftige produktionsnahe Szenarien und so weiter.
Spätestens an der Stelle, wo ich sage, ich habe ein neues Feature, kann ich das alles vergessen.
Also wenn ich da irgendwie dem PO sage, hör mal zu lieber PO, sag mir doch mal, wie das in Produktion laufen wird.
Da kann der PO, wenn er ehrlich zu sich ist, nur sagen,
naja, ich hoffe, dass Leute das benutzen.
Und ich hoffe, dass das halt die folgende Anzahl an Leuten benutzen.
Und zwar folgendermaßen.
Aber er könnte genauso gut völlig andere Zahlen geben.
Und das bedeutet, und das gilt auch im Allgemeinen.
Also das Problem ist eben, ich weiß nicht genau, wie die Leute die Sachen benutzen.
Ich kann nur sehr schwer oder vielleicht gar nicht Produktionsdaten haben für Tests.
Und es ist auch sehr schwer oder fast oder unmöglich,
ein produktionsnahes System für das Testing zu bekommen.
Meistens ist es so, dass die Abteilungen genügend damit zu tun haben, überhaupt irgendeine Umgebung aufzubauen.
Also wenn man das alles subsummiert, muss man eben sagen,
naja, wenn ich mit einem Kapazitätstest in Produktion gehe,
der Kapazitätstest ist grün, dann ist es reichlich naiv anzunehmen,
dass ich halt in Produktion keine Performanceprobleme haben werde.
So und um das zu lösen, werde ich halt in Produktion Monitoring machen.
Und schauen müssen, ob ich irgendwo sehr lange Antwortzeiten habe oder sonst irgendetwas.
Das kann ich noch weiter kombinieren mit anderen Maßnahmen.
Ich kann Sachen erstmal blind mitlaufen lassen und schauen, wie es sich performancemäßig verhält.
Oder ich kann eben dort erstmal nur einige Knoten im Cluster mit einer neuen Version versorgen
und später dann alle und erstmal die neuen überprüfen und anschauen.
Das ist Canary Releasing.
Und das bedeutet im Allgemeinen,
ist ein wichtiger Teil von Continuous Delivery die Möglichkeit,
auch in Produktion genauer hinzugucken, Sachen zu monitoren
und dadurch das Risiko eines Deployments weiter zu verringern.
Das hört sich ein bisschen an wie Tests in Produktion,
aber mindestens an der Stelle, wo wir halt über Performance-Tests reden,
würde ich argumentieren, dass wir keine andere Möglichkeit haben.
Wenn wir uns hinstellen und sagen, wir haben Performance-Tests, die sind grün,
und dann können wir sicher sein, dass wir in Produktion keine Fehler haben.
Das ist naiv.
Also sollten wir eben auch in Produktion entsprechende Maßnahmen haben,
um dort zu überwachen, zu schauen, dass wir halt im Notfall eingreifen können.
Und das ist für mich eben auch ein Continuous Delivery-Anteil.
Eben Risikomanagement jenseits von Tests ist das für mich letztendlich.
Ja, okay.
Das klingt alles für mich, sag ich mal, plausibel an der Stelle.
Wahrscheinlich sehr schwierig.
Wahrscheinlich ist die Schwierigkeit, das dann in gewachsenen Strukturen umzusetzen.
Du hast eben das Thema auch angesprochen, Test.
Test ist, glaube ich, ein großer Anteil von Continuous Delivery, ein großer Treiber.
Für mich als Betriebswirt finde ich immer so zwei schöne Begrifflichkeiten da ganz herausstechend.
Du hast bestimmt sicherlich noch ein paar mehr, wenn ich mir das Test anschaue.
Also Test-Driven Development und Behavior-Driven Development.
Wie passen die in das Continuous Delivery-Umfeld hinein?
Ja, also Test-Driven Development bedeutet, dass ich erst den Test schreibe und dann die Implementierung.
Das kann man auf verschiedenen Ebenen machen.
Das kann man zum Beispiel für Unit-Tests machen.
Also ich schreibe halt, ich will irgendwie eine Klasse schreiben oder eine Methode.
Ich schreibe erstmal einen Test, der irgendwie sagt, wie diese Methode aussehen soll und wie sie reagieren soll.
Dann baue ich die Implementierung.
Und dann baue ich irgendwie den nächsten Test, der irgendwelche Sonderfälle umfasst oder sowas.
Und dann baue ich eben die Implementierung so um, dass sie halt die Sonderfälle umfasst.
Dieses Vorgehen ist nach meinem Empfinden etwas, was sozusagen aus dem Continuous Delivery-Bereich rausfällt,
weil das zu fein granular ist.
Das ist für mich etwas, was eben ein Entwickler vor seiner Maschine einfach tut
und hat mit einer Continuous Delivery Pipeline nicht so wahnsinnig viel zu tun.
Eine der Ideen von Behavior-Driven Development, das ist ja das, was du genannt hast,
ist, genau diesen Mechanismus, Test-Driven Development, auch auf grob granularer Resonanz,
grob granularere Sachen loszulassen.
Das heißt, die Vision ist, zusammen mit einem Experten, einem Fachexperten,
der irgendwie aus dem Fachbereich kommt oder im Product Owner oder sowas,
definiere ich einen Test, der sagt, wie dieses System sich verhalten soll im Sinne eines Akzeptanz-Tests.
Also, wenn der Test grün ist, wird das System eben abgenommen.
Und dafür nutzt Behavior-Driven Development solche Sachen,
dass ich halt Szenarien hinschreiben kann, tatsächlich in Englisch also oder in Deutsch nicht,
gegeben ein Kunde, da gibt es solche Teile, die eben voll definiert sind, also gegeben beispielsweise,
da würde ich also hinschreiben, gegeben ein Kunde mit einem Namen und einem bestimmten Kreditscoring.
Dann sage ich, was für ein Ereignis passieren muss, wenn der Kunde eine Bestellung über 1.000 Euro abgibt.
Und dann sage ich noch, was ich erwarte.
Dann erwarte ich, dass eben diese Bestellung abgelehnt wird.
Sowas in dem Dreh.
So, und das kann ich jetzt hinschreiben als eine fachliche Definition.
Und ich kann das dann eben so lange den Code ändern, bis das entsprechend umgesetzt ist.
Das ist nicht nur relevant, weil es eben die Qualität der Software erhöht,
sondern auch insbesondere deswegen,
weil ich dadurch,
den Kunden beim Akzeptieren der Software sozusagen eliminiere.
Also der Kunde, wenn er die Akzeptanztest versteht und akzeptiert,
dann brauche ich, bevor die Software in Produktion geht,
nur noch die Software eben durch den Akzeptanztest zu bekommen,
durch den automatisierten Akzeptanztest und dann kann ich es in Produktion geben.
Und das ist ein wesentlicher Schlüssel.
Also an der Stelle, wo ich sage, der Kunde will manuell noch durchtesten,
fehlt mir die Fantasie, wie das funktionieren soll,
mit mehrmals Deployment pro Tag.
Also das kann ich im Prinzip noch machen,
aber das ist dann nicht mehr sinnvoll.
Ich weiß nicht, was der da noch rausfinden will.
So, und das ist eben der Grund, weswegen genau dieser Bereich
eigentlich einer der wichtigen Bereiche von Continuous Delivery ist.
Und weswegen eben in meinem Buch auch ganz viel irgendwie über Testen drinsteht,
weswegen der Continuous Delivery Pipeline ganz viel über Testen schreibt oder eben sagt.
Und das ist eben dem geschuldet, dass genau dieser Bereich
Testing das höchste Optimierungspotenzial hat
und dass man da auch am meisten eigentlich ändern muss,
wenn man eben mehrmals pro Tag deployen möchte.
Ja, ich würde da gerne nochmal einhaken.
Für mich klingt dieses Behavior Driven Development so ein bisschen wie
die Idee, die es damals ja auch gab.
Ich modelliere mit ARIS, also mit einem Prozessmodellierungstool,
modelliere ich einen Prozess.
Und dann drücke ich auf den Knopf und dann kommt da eine SAP-Routine raus.
Und wenn ich das vergleiche, wie mein Verständnis wäre,
hier zu sagen, ist das überhaupt möglich?
Also was sind so auch deine praktischen Erfahrungen?
Lässt sich das umsetzen an der Stelle?
Hast du nun wirklich auch Projekte, wo das gemacht wird?
Also das wird umgesetzt, ja.
Und das ist eben auch etwas, was gemacht werden kann.
Aber, also du hast halt recht, das ist eben nicht einfach.
Und der Grund, warum ich eben darauf rumreite, ist gerade,
weil es eben nicht einfach ist und weil es aber eigentlich unabdingbar ist.
Und also das geht schief an vielen verschiedenen Stellen.
Also irgendwann, ich weiß nicht mehr, was für ein Szenario das war,
da war irgendwie die Aussage, wir haben einen Akzeptanztest,
aber der Kunde wird trotzdem irgendwie nochmal draufgucken.
Sondern da habe ich irgendwie gefragt, naja, wie sieht das aus?
Weiß der Kunde, was für Akzeptanztest das sind?
Hat er die schon mal gesehen?
Und dann stellte sich heraus, nein.
So, und das ist natürlich irgendwie tödlich.
Und das ist, glaube ich, eines der Missverständnisse,
das halt an vielen Stellen existiert.
Es geht eben nicht darum, dass jetzt der Entwickler
mit Hilfe von irgendeinem BDD-Tool die Tests schreibt, die er eh schreibt.
Sondern es geht darum, dass der Kunde Vertrauen entwickelt in die Tests,
sodass die automatisierten Tests ausreichend sind,
um Softwareproduktion zu bekommen.
Das ist auch ein bisschen ein Problem,
den ich mit der Diskussion an der Stelle manchmal habe.
Das ist eben keine Tool-Diskussion.
Es geht darum, dass der Kunde diesen Test vertraut.
So, das bedeutet an der Stelle,
das war auch zum Beispiel etwas, wo ich so für mich etwas gelernt habe,
man kann ja so ein Akzeptanztest jetzt auch mit einem UI-Test machen.
Dass ich eben sage, okay, ich habe ein automatisiertes Ding,
wo irgendwie rumgeklickt wird und am Ende sagt man halt,
ja, die Software funktioniert oder eben auch nicht.
UI-Tests sind nicht so toll, die dauern lange,
die sind auch fragil, wenn ich irgendwie Buttons umbenenne,
dann können die UI-Tests brechen,
obwohl die Funktionalität immer noch da ist und so weiter.
So, und in dem konkreten Szenario war es eben so,
dass ich gesagt habe, nee, lass uns doch keine UI-Tests machen,
sondern lass uns das irgendwie anders machen.
Also eben mit so einem Behavior-Driven Development Tool.
Und das hat sich nicht durchgesetzt, weil die Aussage dort war,
naja, die Kunden testen jetzt im Moment UI-basiert.
Wenn die Kunden testen jetzt im Moment UI-basiert,
wenn wir das ändern, wenn wir also dort
einen automatisierten UI-Test haben,
dann haben wir eine höhere Wahrscheinlichkeit dafür,
dass die Kunden das akzeptieren.
Und mittlerweile würde ich sagen, ja, genau,
das ist eigentlich der wesentliche Punkt.
So, und da gibt es viele andere Potenziale,
also an der Stelle, wo der Kunde so ein lustiges
Excel-Spreadsheet hat, wo irgendwie draufsteht,
wie er schrittweise die Software testen will,
kann man eben versuchen, dieses Excel-Spreadsheet zu nehmen
und automatisiert einzulesen, um dann eben einen entsprechenden Test
daraus abzuleiten oder den Test eben automatisiert durchzuführen.
Wenn da irgendwie steht, klick hier, klick hier, klick hier,
in diesem Excel, kann man das ja entsprechend ausführen.
Das ist ja kein großer Unterschied zu dem,
was Behavior-Driven Design da eh tut,
weil die eben dort dann entsprechend Textdateien haben.
So, und das ist eben der wesentliche Punkt an der Stelle.
Und ich kann nur nochmal wiederholen, das ist nicht trivial,
aber wie will ich sonst von diesen Textdateien,
wie will ich sonst von diesen sechs Wochen runterkommen,
auf wie viele Malts pro Tag?
Also wenn ich halt die Software dem Kunden in die Hand gebe,
wird das nicht funktionieren.
Also entweder schaffe ich das, die Akzeptanztests zu automatisieren,
oder ich werde mein Ziel nicht erreichen.
So einfach ist das nach meinem Empfinden.
Ja, und was ich bei dir raushöre, ist dann die Schwierigkeit ja auch,
dass letzten Endes das, was ich als Herausforderung für die,
ich sag mal aus psychologischer Sicht bei Test-Driven Development,
für die Entwickler, weil sie ja anders vorgehen müssen als früher.
Also früher sind sie ja häufig eher so als freischaffende Künstler unterwegs gewesen.
Sie müssen jetzt anders arbeiten und genauso müssen sich auch die Kunden anpassen.
Sie müssen das, was sie testen wollen, sauber und eindeutig beschreiben,
damit es dann eben automatisiert werden kann, oder?
Ja, genau. Wobei ich halt gestehen muss,
an der Stelle existiert für mich so ein bisschen so eine philosophische Frage.
Also wenn ich nicht sagen kann, was ich teste, wie teste ich es dann?
Also wenn ich nicht klar sagen kann, die Software soll sich folgendermaßen verhalten,
dann mag es ja sein, dass es irgendeinen unstrukturierten Test gibt,
der hat irgendwie einen Eindruck vermittelt, ob die Software vernünftig funktioniert.
Aber das ist ja nicht wirklich zuverlässig.
Also würde ich halt behaupten, dass an der Stelle, wo das nicht formalisiert aufschreibbar ist,
das sowieso wenig Sinn macht.
Vielleicht an der Stelle noch ein Hinweis, weil das finde ich halt auch ganz interessant.
Wir reden jetzt ein bisschen sehr stark, so wie es damals bei Extreme Programming war.
Extreme Programming hat damals gesagt, also das ist ja mittlerweile 20 Jahre her,
irgendwie im letzten Jahrhundert entstanden.
Und Extreme Programming hat damals gesagt, eine vernünftige Anforderung ist ein automatisierter Test.
Und das war eben eine sehr radikale Meinung.
Das läuft jetzt ein bisschen auch in diese Richtung.
Ich würde das nicht ganz so sehen.
Und das ist auch etwas, was tatsächlich sich in der Continuous Delivery Pipeline anders niedersteckt.
Ich kann manuelle Tests in der Continuous Delivery Pipeline haben.
Also es gibt explorative manuelle Tests.
Die dürfen nur nach meinem Empfinden kein Vetorecht haben, ob Software in Produktion geht.
Also will heißen, wenn ich mehrmals pro Tag deployen will, muss ich die Tests automatisieren.
Dafür darf es nicht so sein,
dass irgendein manueller Test sagt, ja, ich verbiete, dass dieses für Fan-Produktion geht.
So und jetzt ist die Frage, was machen dann überhaupt diese manuellen Tests?
Naja, es gibt bestimmte Sachen, die kann ich nicht so einfach automatisieren.
Also beispielsweise UX-Tests, wo ich irgendwie schaue, ob das Ding benutzerfreundlich ist.
Und das macht irgendwie auch nicht so sonderlich viel Sinn.
Und ich wüsste auch nicht, ob die nun unbedingt sozusagen betriebsverhindert sein sollten.
Vielleicht auch sowas wie Penetrationstests, obwohl man da eben diskutieren kann.
Unsicher, Software sollte vielleicht wirklich nicht in Produktion gehen.
Oder solche Sachen wie, naja, wir haben bei der Registrierung im Moment bekanntermaßen Performance-Probleme.
Guck da doch mal rein.
So und das ist offensichtlich in Produktion schon aufgefallen.
Also werde ich weiter Software in Produktion bringen, die dieses Problem hat.
Weil das verschlechtert eben die Produktion nicht.
Aber durch diese explorativen Tests kann ich eben einen Handlungsstrang lostreten.
Der dafür sorgt, dass das ausgemerzt wird.
Und dann vielleicht auch eben automatisierte Tests irgendwann ergibt.
So lange Rede, kurzer Sinn.
In diesem Continuous Delivery Bereich sind automatisierte Tests nicht das, was immer gemacht werden muss.
Grundsätzlich, so wie bei Extreme Programming.
Es gibt manuelle Tests, nur die sollten eben nach meinem Empfinden nicht produktionsverhindernd sein.
Sonst macht das eben keinen Sinn und ich kriege halt die hohe Geschwindigkeit nicht hin.
Ich würde auf das Thema Automation nochmal eingehen.
Du hast eben an vielen Stellen in deiner Ausführung immer wieder von Automation gesprochen.
Und wenn ich jetzt mal so eine naive Frage stelle, wäre denn Continuous Delivery ohne Tools überhaupt denkbar?
Sicher nicht.
Und also Test-Tools, diese Tools, die die Pipeline zusammenhalten und die halt durchführen, wie auch die Test-Tools, sind natürlich notwendig.
Ja.
Ja.
Das ist aber etwas, wo zumindest im Bereich Testing ja vorher schon es viele Tools gab.
Und die Innovation ist eben tatsächlich eher einmal in dem Bereich der Pipelines und zum anderen eben in dem Bereich von, wie kriege ich die Software nachher in Produktion.
Okay.
Das heißt letzten Endes einfach nur eine Art Veredelung.
Und vor allen Dingen die Unterstützung des gesamten Prozesses, des Pipeline-Prozesses.
Ja.
Letztendlich geht das halt in diese Richtung.
Und wir haben halt in dem Bereich, wir haben halt in diesem Bereich von, gerade die Pro mit Automatisierung, halt erhebliche Fortschritte.
Mittlerweile durch sowas wie Docker ist das sehr einfach geworden.
Und ich glaube auch, dass sich da so ein bisschen so ein Standard rausschält.
Umgebungen wie Kubernetes unterstützen auch.
Und unterstützen auch bestimmte Release-Taktiken.
Also ich habe gerade von Canary-Releasing gesprochen, wo man erstmal auf einem Knoten die neue Software deployt und dann später erst auf allen.
Das ist etwas, was Kubernetes beispielsweise direkt unterstützt.
Mit Kubernetes kann ich eben Docker-Container in einem Cluster laufen lassen und kann dann eben genau solche Deployment-Ticks wie Canary-Releasing direkt unterstützen.
Und von daher ist eben in diesem Bereich Deployment-Automatisierung, aber auch im Bereich von dem Management-Programm.
Aber auch im Bereich von dem Management, von den Pipelines, da ist sicherlich sehr viel Innovation zu sehen im Moment.
Ja, ich gucke ein bisschen auf die Uhr und die sagt mir, dass wir jetzt bei einer Zeit sind, die so angestrebt ist von der Planung her.
Ich finde auch, dass wir ziemlich viele gute Themen behandelt haben.
Gibt es aus deiner Sicht noch fachliche Dinge, die du anführen würdest zum Thema Continuous Delivery im Kontext DevOps?
Mir fällt jetzt so ad hoc nicht wirklich etwas ein.
Ich habe halt hingewiesen auf diese Studie.
Die kriegt man halt kostenlos.
Die, finde ich, ist eine ganz gute Argumentationshilfe und zeigt halt irgendwie auch, wo wir Optimierungspotenzial haben.
Ich glaube, das ist ein wichtiges Thema.
Ansonsten, also sich mit dem Thema Continuous Delivery auseinanderzusetzen und mit dem Thema Microservices macht halt sehr viel Sinn.
Neben den Büchern, also gerade im Microservices-Bereich ist halt neben den Büchern, die ich geschrieben habe, die man kaufen kann, gibt es auch ein paar kostenlose Bücher von mir.
Da kann man sich also auch, denke ich, suchen.
Da kann man sich auch, denke ich, sehr gut einarbeiten und mal schauen, was da voraus ist.
Ja, also die Hinweise auf deine Bücher werde ich in den Shownotes bringen.
Da hast du ja eine ganze Reihe von nützlichen und interessanten Websites dazu.
Das heißt, das kann man dann auch in den Shownotes sehen.
Den State of DevOps Report finde ich auch sehr interessant, wenn ich in meinen Schulungen diese Zahlen dort auflege.
Ich glaube, wir haben die Zahlen aus 2016 noch drin stehen.
Dann schlackern die alle mit den Ohren.
Natürlich sind das Zahlen.
Man erstmal überprüfen und hinterfragen muss.
Aber trotzdem sind es einfach Zahlen, die mal da sind und da stehen und die manche klassische IT ganz schön ins Schwitzen bringen.
Ja, genau.
Also, wenn man sich das tatsächlich anguckt, die haben ja so eine Segment-Analyse gemacht und haben irgendwie gesagt, wie stark unterscheiden sich eben die Elite-Performers von den Low-Performers.
Und die bekommen da tatsächlich Faktoren raus und zwar sehr hohe in Bezug auf Lead-Time und bessere Zuverlässigkeit, neue Releases und so weiter und so weiter.
Und auch in Bezug auf neue Arbeit.
Also, wie viel Zeit kann ich in neue Arbeit investieren?
Ich glaube, es ist 50 versus 30 Prozent oder sowas.
Ich würde das auch kritisch hinterfragen.
Klar, auf der anderen Seite ist es eben so.
Ich muss gestehen.
Intuitiv ist es eigentlich vielen Leuten, glaube ich, schon klar.
Also, wenn man jetzt einfach jemanden fragt und sagt, hey, Quartalsreleases, Mehrmalsportal-Releases, was wird häufiger schiefgehen?
Es ist absolut überraschend, wenn da jemand sagt, ja, Quartalsreleases werden weniger häufig schiefgehen.
Und das führt eigentlich ja zu der Frage, warum haben wir es nicht immer so gemacht?
Und ich glaube, dass eben der Kern dessen, warum wir es eben nicht immer so gemacht haben.
Oder warum das so entstanden ist.
Das Problem ist, dass das Deployment der verschiedenen Systeme koordiniert werden muss in vielen Architekturen.
Und das führt eben wieder genau zu dem Microservices-Ansatz, wo man an sich nach die wesentliche Aussage ist, nein, muss nicht koordiniert werden.
Und dadurch sprengen wir halt dieses Problem.
Wie übrigens auch, wie wir übrigens auch an der Stelle Voraussetzungen eliminieren, die SAFe hat, nicht?
Also das SCALE-Agile-Framework sagt,
wir müssen ein System haben.
Wir müssen ein Release-Train haben, in dem wir alle Projekte gemeinsam in Produktion bringen.
Deswegen müssen wir die Entwicklung der verschiedenen Projekte eng koordinieren.
Den müssen wir nicht.
Wenn wir halt irgendwie die Releases voneinander entkoppeln und dafür sorgen, dass eben diese Systeme getrennt deployed werden können, müssen wir auch nicht so ausführlich koordinieren.
Und deswegen ist eben genau dieser Ansatz so wichtig, glaube ich, an der Stelle.
Gut, dann würde ich mal sagen, Ewald, ich bedanke mich.
Ja, danke.
Ich finde es immer wieder schön, wenn Experten ihr Expertenwissen so erklären können, dass es auch ein Nicht-Experte versteht.
Und ich habe heute einiges mitgenommen, habe einiges verstanden.
Schön.
Insofern bedanke ich mich an der Stelle und ich hoffe, dass auch den Zuhörern das auch so geht.
Und also vielen Dank und bis demnächst, Ewald. Tschüss.
Ja, danke.
Vielen, vielen Dank.