So, und dann Gnade einem Gott, wenn dann noch irgendwie Änderung reinkommt, was irgendwie geändert werden muss, weil dann bricht das halt irgendwann komplett auseinander. Coding Body rund um Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Ein herzliches Hallo und Willkommen zur neuen Folge vom Coding Buddies Podcast. Es ist wieder soweit, eine neue Folge startet und damit begrüße ich dich. Tino, schön, dass du auch wieder dabei bist.
Ja, herzliche Willkommen auch von meiner Seite. Liebe, zuhören, liebe Zuhörer und Hallo Fabi. Was geht ab? Wie geht's dir, bist du fit, bist du bereit für die Folge? Ich habe richtig Bock, sehr gut, ja. Mir geht es auch gut. Ich habe auch Lust auf die neue Folge, und zwar weil wir ja auch mal wieder uns überlegt haben, dass wir eine neue Reihe starten wollen. Auch etwas, sagen wir mal, technischer Reihe. Genau. Und es geht in dieser Reihe um das Thema Dev Ops.
Also wir wollen jetzt quasi einmal mit in dieser Folge mal so ein bisschen. Das Thema einleiten. Gucken. Was ist dev ops? Wie kam es zu DEV OPS und. Was für Vorteile bringt denn vielleicht dieses Def Ops, was wahrscheinlich auch schon die ein oder andere Person gehört hat?
Genau wie sieht's aus, Tino? Ja, ist auf jeden Fall ein sehr spannendes Thema und ich finde es auch cool, dass wir da eine direkt eine Reihe draus machen wollen, weil es einfach auch sehr umfangreich ist und wir da bestimmt so einige Folgen zusammen bekommen mit. Themen, über die es sich lohnt
zu sprechen. Denn ja, also ich glaube, wenn man in der Softwareentwicklung oder allgemein so in der IT unterwegs ist, dann gibt es eigentlich kaum noch einen Weg daran vorbei, seit einigen Jahren an dem Wort Dev Ops und alles was dahinter steckt. Und deswegen, glaube ich, ist das auch für den einen oder anderen sehr interessant, da mal so einen Einblick zu bekommen. Was auf jeden Fall ein guter Punkt, dass du sagst, dass das eine Menge umfasst.
Ich glaube, das könnte man. In einer Folge überhaupt nicht alles umfassen die Ganzen, sagen wir mal Punkte, die da eine Rolle spielen in diesem Bereich. Na ja, also es geht schon, dann hole ich mir jetzt noch eine Kanne Kaffee und liebe Zuhörerin, liebe Zuhörer, du nimmst dir jetzt 24 Stunden Zeit und. Würdest ein kleiner Podcast Marathon? Nee, also hast du absolut recht, das ist einfach viel zu umfangreich, deswegen macht das Splitten natürlich Sinn. Genau.
Aber lasst uns doch mal gucken, dass wir uns so ein bisschen vorhangeln und mal ein bisschen beleuchten, wie es denn überhaupt dazu gekommen ist. Zu diesem Begriff Dev Ops oder wieso sich es das überhaupt so etabliert hat. Du hast ja gesagt, man kommt heutzutage eigentlich gar nicht mehr so richtig daran vorbei. Und die Frage ist natürlich auch warum. Also es muss sich natürlich etabliert haben, wenn man nicht mehr daran vorbeikommt.
Und da können wir erstmal vielleicht anfangen und gucken okay, wo kommen wir eigentlich in der Softwareentwicklung her? So Stichwort. Traditionelle Softwareentwicklung von früher, vielleicht sogar vor dem Jahr 2000 ungefähr roundabout, sagen wir mal so. Und. Wieso gibt es jetzt dev Ops? Ne, dass man so genau diese diese Brücke schlägt, weil ich Spoiler mal n bisschen wahrscheinlich gab es irgendwie
etwas was sich ändern musste. Ja, meistens entsteht ja sowas da aus dem Need heraus, dass Probleme auftreten und Änderung her muss. Ja, da hast du natürlich voll recht. Ja, also ordnen wir das ganze Mal ein. Also ich fand den Begriff traditionelle Softwareentwicklung ganz cool, den du da gerade gebracht hast. Also quasi so die Zeit bevor dieser Change da war und dev Ops in aller Munde war. Wo man noch mit Dreinen entwickelt hat, so ganz. Genau also mit dem Rechenschieber.
Über die Zeit? Nein, ganz so schlimm nicht. Aber geht man zum Beispiel mal so in das Projektgeschehen oder allgemein in die Softwareentwicklung zurück, in die, ja, sagen wir mal roundabout vor 20 Jahren.
War das ja oftmals so. Es ist auch nicht ganz weg, aber damals war es halt viel, diese klassische Wasserfall Entwicklung, man kann sich das halt auch so vorstellen wie bei einem Wasserfall, dass quasi es mehrere Phasen gab innerhalb eines Projekts und die Sequenziell abgelaufen wurden, das heißt das Wasser quasi von oben nach unten sozusagen
feldblöcke. Gesagt, du hast halt erst eine Stufe, wenn die abgeschlossen ist, kommt die nächste und so weiter das heißt du hattest nen festen Ablauf an Phasen und der hat dann im Prinzip zu deinem Produkt am Ende geführt. Das heißt das war ne relativ starre Prozesse. Fangen wir beispielsweise an, dass man erstmal ne anforderungsanalyse macht. Man definiert halt die Anforderungen an das Produkt oder an die Software.
Man macht n Design. Wie soll das ganze Aussehen später, wie könnte man das implementieren, dann geht es in die Implementierung, das heißt, die Coder fangen an, anhand der Anforderungen das zu implementieren und dann irgendwann testest du das hoffentlich. Und schaust quasi dann. Was am Ende dabei rumgekommen ist, das heißt, du stellst es dann dem Kunden beispielsweise bereit. So, und das ist halt wirklich n
sequentieller Prozess gewesen. Was halt einige Probleme mit sich bringen kann und auf die würde ich gerne mal eingehen um so n bisschen zu motivieren. Warum Deff Ops entstanden ist. Also warum dann die ich sage mal die Community in der Softwareentwicklung sich gedacht hat, nee so geht das nicht weiter, aber wenn du jetzt. Zum Beispiel sagst, dass du. Diese Schritte durchläufst und dann die Software oder das
Produkt an den Kunden bringst. Dann suggeriert mir das ja schon, dass so damals, ich sag mal so ein bisschen das Mindset geherrscht hat. Okay ich bastel jetzt ein Produkt und das ist fertig und das gebe ich jetzt an den Kunden. Genau. Genau, und da haben wir nämlich auch schon ein erstes großes
Problem dabei. Und zwar angenommen, du hast jetzt Mitarbeiter, die sich um die Anforderungen kümmern, die überlegen sich einfach über einen gewissen Zeitraum, was für Anforderungen haben wir denn an die Software, was muss die Software können und sind dann provokativ gesagt der Meinung wir sind fertig, wir haben es komplett spezifiziert und jetzt geben wir das ans nächste Team. Gehen wir mal davon aus, jede Phase ist ein eigenes Team. Das heißt, es geht jetzt an in
den, was hatte ich gesagt, sagen wir mal, Design so, jetzt wird halt designt, wie diese Software aussehen könnte anhand der Anforderungen. Also nicht. Optisch nein, nein, Software Design genau also auch so Architekturiell etc. Und das basiert ja auf den Anforderungen. Das heißt du überlegst dir jetzt, wie könnte ich diese Software bauen anhand meiner Anforderungen, die ich bekommen habe, weil Phase 1 ist ja
abgeschlossen. Und jetzt hab ich halt quasi n Set an Anforderung und das ist mein Input für meine Arbeit.
Mhm, dann bin ich fertig oder das Team und sag OK wir haben jetzt designt wie die Software aussehen soll, das ist jetzt der Input für die Coder und die entwickeln nach diesen Anforderungen und dieser Architektur jetzt die Software so das klingt ja in der Theorie erstmal sinnvoll so okay ja hier wir machen alles schön ordentlich Schritt für Schritt, wir haben unsere Prozesse und wir wissen genau am Ende kommt denn die Software raus die wir haben wollen.
In der Praxis läuft das so aber nicht. Hat sich dann ja auch herausgestellt, weil welche Probleme haben wir denn jetzt an der Stelle Fabi, wenn wir quasi sagen, wir haben feste, starre Sequenzen, was könnte denn beispielsweise einfach passieren währenddessen, und das ist ja der große Knackpunkt. Dabei ja. Also wenn du jetzt natürlich, man kennt es, ich glaube, wenn man in der Softwareentwicklung auch selber tätig ist heutzutage, dann kennt man es. Zwar ist es ja durchaus möglich,
dass man eventuell. Bestimmte. Also du hast jeder hat so seinen eigenen Scope, also seinen eigenen Blick auf auf den Sachverhalt und. Vielleicht übersieht das eine Team, vielleicht irgendwas oder rechnet mit etwas nicht, was vielleicht zu Problemen führen
kann. Das heißt, wenn du jetzt zum Beispiel aber durch diese Software Design durch bist und dann am Ende in der Entwicklung merkst, das funktioniert so vielleicht gar nicht so richtig, dann hast du natürlich laut diesem Wasserfall Modell. Nach diesem Prinzip läuft das Wasser ja nicht mehr nach oben, das heißt du kommst ja rein theoretisch nicht mehr in den Schritt vorher. Das ist übrigens eine sehr coole Analogie, dass du dieses Wasserfall Modell quasi nutzt, um die Schwäche direkt
aufzuzeigen, finde ich gut. Ja genau, das Wasser kann nicht wieder nach oben laufen, korrekt? Und das ist ja so das Grundproblem an der Stelle und. Wenn man sich noch mal so n bisschen anguckt, was wie wieso die Softwareentwicklung aussah und dann merkt, dass ja mit der Zeit, das ist ja heute ist das ja ne ganz andere Art der Softwareentwicklung als damals. Hat sich ja quasi.
Sind ja auch Sachen reingekommen, wie zum Beispiel, dass das Marktumfeld sich schneller verändert, ne, also die Anforderungen verändern sich und die verändern sich gefühlt mit der Zeit haben die sich immer schneller verändert, das heißt, am Ende musst du ja immer schneller auf Veränderungen eingehen können und wenn man jetzt gerade davon ausgeht, dass man zum Beispiel oben am Wasserfall ein kleiner Tropfen ist, der einmal runter fließt und wie gesagt, der kann ja
nicht wieder hoch. Aber vielleicht hast du auf der Hälfte des Wasserfalls einen Impact und das heißt, Wir haben Änderungen. Wir müssen uns anders aufstellen, es muss irgendwas passieren. Dann hast du halt ein Problem, dann bist du sehr unflexibel und kannst halt nicht mehr hoch und musst erst mal wieder runter. Bist du vielleicht wieder oben einmal wieder hochkommst und
wieder runter fließen kannst. Und das ist natürlich genau das Problem und dazu kommt ja noch, dass rein theoretisch man ja auch, dass dieser Wasserfall jetzt, wir reden hier nicht von der Woche. Dass sozusagen dieser Wasserfallende Woche geflossen ist, sondern das waren ja das, das war ja ne ganze Zeit, ne, also das waren ja, ich sag mal so, früher waren das Monate, da hattest du genau, also gehen wir mal davon aus, du läufst einmal des Wasserfallmodell durch und
es kommt ne neue Version der Software raus. Also du hast n neues Release, dann hattest du ja locker release Zyklen von mindestens 6 Monaten, wenn nicht sogar ein Jahr also das war ja nicht unüblich und dann hast du halt erst dein Kundenfeedback nach 6 Monaten. Und das ist witzig, weil. Erstmal, glaube ich, gibt es immer noch heute. Zumindest habe ich auch schon davon gehört, dass auch Released wird in solchen großen Zyklen. Das heißt? Das ist nicht vom Tisch.
Genau, es ist nicht vom Tisch. Also sowas gibt es ja immer noch, aber die State of the Art Entwicklung sage ich jetzt mal, ist ja vielleicht eine andere, aber. Dass du das mit den Releases angesprochen hast, das ist auf jeden Fall ein guter Punkt und auch, dass du dein Feedback dann erst natürlich. Wenn du nach einem halben Jahr Release doch erst ein halbes Jahr später bekommst. Da hab ich nämlich beziehungsweise ich weiß, dass du es auch gelesen hast. Da haben wir ja das The Dev Ops
Handbook gelesen. Das können wir auf jeden Fall mal verlinken, weil das. Ist ja, das ist ein sehr gutes. Genau also zum Thema Dev Ops. Sehr zu empfehlen, wenn das jemanden interessiert. Und da wird von der sogenannten Down Ward spiral geredet, also eine Abwärtsspirale, und die quasi genau dadurch entsteht, dass vielleicht hat damals, also wirklich vor über 20 Jahren diese Entwicklung so funktioniert. Wahrscheinlich hat sie funktioniert, weil sonst hätten wir ja gar nicht die Produkte
damals gehabt. Also sie hat ja funktioniert, aber auf jeden Fall hatte sie massive Schwächen und irgendwann konntest du das nicht mehr ignorieren, sozusagen genau. Durch eben diese, durch die eben diese Impacts, die kamen, durch diese Veränderungen, die dann also auch auf die Anforderungen, also eingebracht sind, sage ich jetzt mal. Da hattest du einen guten Punkt vorhin gebracht.
Soll den muss ich mal kurz noch mal in Erinnerung rufen, weil du es vorhin schon angesprochen hast, weil die Entwicklung ja immer schnelllebiger wurde oder die Zeit immer schnelllebig. Oder aus technischer Sicht. Und demnach musstest du dich ja auch schneller adaptieren können oder neue Sachen in deine Software einbauen und dann ist sonnenträger Prozess halt n absoluter ja no go gewesen, im Prinzip ne.
Ja richtig, also stell dir vor, du hast n Release Zyklus von einem Jahr und innerhalb dieses Jahres kommen 2 neue Frameworks raus, die sich viel besser nutzen lassen um irgendwas zum Beispiel. Rauszubringen, zu Releasen. Wie lange will man darauf warten, also noch ein halbes Jahr, noch ein dreiviertel Jahr, oder will man es am besten sofort machen im Optimum und je schneller man dann sozusagen auf Änderungen reagieren kann, desto besser.
Aber kommen wir mal nochmal auf. Downloadspiral zurück. Was eigentlich genau dieses Grundproblem eigentlich ganz gut darstellt, gerade weil du ja auch zum Beispiel von so langen Releasezyklen gesprochen hast. Die ja auch einfach, sag ich jetzt mal, existiert haben. Die. Halt eben. Da waren auch nicht ohne Grund ne. Also im Endeffekt war es ja so, dass man damals manuell. Auch manuell Software Released hat. Und das war eben dann noch
aufwendig. Ne, also alles was du manuell machst ist natürlich n bisschen aufwendiger und natürlich auch fehleranfälliger und da beißt sich dann schon die Katze n bisschen in den Schwanz, weil du ja dir sagst, OK, ich möchte vielleicht nicht häufig releasen, weil es halt Zeit frisst, weil ich es manuell machen muss, was aber bedingt, dass wenn du zum Beispiel alle halbe Jahre oder wenn du jedes Jahr einmal released, dann ist das ja niemals eine Routine, die
Eintritt. Also du kannst nicht routiniert darin werden, was ja auch dazu führt, dass du das Ganze noch fehleranfälliger wirst. Dass Leute, das habe ich sogar. Selber Punkt, dass ich auch. Sehr. Ich habe auch selber schon erlebt, dass dass es so eine gewisse Angst vor Release Tagen gibt, weißt du? Release Day da. Das löst bei einigen ordentlich Panik aus, auf jeden Fall auch heute noch.
Und ist ja eigentlich Spoiler. Eigentlich eine doofe Sache, aber können wir, gehen wir vielleicht später noch mal
darauf ein? Aber dann durch diese Fehleranfälligkeit, durch diese Unroutiniertheit treten halt eben Fehler auf und diese Fehler müssen logischerweise behoben werden und dann ist auch wieder die Frage OK, wie gut kann ich zum Beispiel Fehler der Infrastruktur fixen, wenn ich eben zum Beispiel. Unroutiniert darin bin, wenn ich zum Beispiel Fehler am Code habe, ist die Frage OK, wo kommt denn dieser Fehler her, wo ist der Ursprung dieses Fehlers, der
kann bei einem Release Zyklus von einem Jahr vor einem dreiviertel Jahr gewesen sein. Finde mal diesen Fehler ne, also kannst du dich noch dran erinnern was du letzte Woche Montag gegessen hast zu Mittag. Sag jetzt nicht, ja. Nee, tatsächlich nicht. Ich habe gerade wirklich mal
überlegt, aber nein. Aber weißt du, da fangen die Sachen ja schon an und das heißt, du brauchst natürlich Zeit, um diese Fehler zu fixen, aber diese Zeit geht natürlich von der Weiterentwicklung ab und das Problem ist, dass gerade wenn du so ein Wasserfall Modell zum Beispiel hast, dann hast du auch oft quasi einen zeitlichen Plan, den du festgezurrt hast.
Und dann fängt natürlich der Druck an so, das heißt, es wird dann Druck aufgebaut auf die Entwickler und Entwicklerinnen, weil du musst ja quasi neue Features liefern bis zurzeit x bist aber noch damit beschäftigt deine alten Fehler überhaupt auszubügeln. Was natürlich dann wiederum dazu führt, dass du vielleicht. Release Releases.
Verschieben musst. Und was natürlich auch dazu führt, dass die Moral irgendwo im Team sinkt, was natürlich auch dazu führt, dass die Produktivität sinkt, weil wenn du dir irgendwann denkst, boah, das ist irgendwie blöd und das funktioniert alles nicht und ich kämpfe die ganze Zeit nur noch damit, Brände zu löschen, anstatt eigentlich irgendwie neue tolle Sachen zu bauen, dann ist das natürlich irgendwann auch ein Problem und dann, und das ist dann sozusagen schon
fast der letzte Punkt. Mangels irgendwann auch an der Kommunikation. Also du hast zum Beispiel, ich habe ja von Entwicklung gesprochen und ich habe von der Infrastruktur gesprochen und das spielt ja Hand in Hand. Und die Kommunikation wird aber dadurch, dass auch irgendwann Frust sich breit macht zwischen diesen Parteien, halt auch
geringer. Und irgendwann kommt es dann wahrscheinlich auch so zu, so, sage ich mal, Schuldzuweisung, so nach Motto. Ja, das ist ja nicht mein Problem, das ist ja deren Problem, ich habe damit nichts zu tun. Und damit hast du dann im Endeffekt einfach ne Kluft, die sich auftut.
Auch ne geringere Kooperation. Die Teams arbeiten immer isolierter voneinander und dann hast du halt im Endeffekt quasi genau das Problem, dass alle anderen Aspekte, die ich gerade vorher genannt hab, sich eigentlich nur noch verschlimmern, also das eine bedingt das andere und im Endeffekt wird alles dadurch immer schlimmer und das ist halt genau sag ich jetzt mal diese downward spiral, die dann im Endeffekt eintritt, so und dann Gnade einem Gott.
Wenn dann noch irgendwie Änderung reinkommen, was irgendwie geändert werden muss, weil dann bricht das halt irgendwann komplett auseinander und ich finde das. Ist dann zum Beispiel erst am Ende vom Testen zum Beispiel Auftritt, weil wir ja vorhin hatten, diese einzelnen Prozessschritte, und auf einmal merkst du okay, was wir hier releasen wollen, das funktioniert einfach gar nicht genau, und dann geht es richtig. Zur Sache und dann geht's richtig. Ja, also auf jeden Fall finde
ich diese downward spiral. Extrem aussagekräftig und du hast es auch ganz sehr cool zusammengefasst. Danke dafür. Weil daraus eigentlich genau klar wird, welche Probleme wir in dieser traditionellen Entwicklung haben. Ich würd das gern noch mal kurz zusammenfassen und das sozusagen als Aufhänger nehmen für diese ganze Reihe, da kann man sich einfach super dran langhangeln, weil Spoiler Warnung. Natürlich wurde Death Ops ins Leben gerufen um diese Probleme zu lösen.
Und ja, also wie gesagt, diese altmodischen Prozesse nach dem Wasserfall Modell oder so sind halt super unflexibel. Das hattest du ja auch gut beschrieben. Das Wasser kann ich wieder nach oben fließen, ganz einfache Analogie dahinter macht also ich denke das sollte jedem klar sein, da will ich jetzt nicht weiter darauf eingehen, diese Silostrukturen, die hattest du gerade auch super aufgeführt, weil das finde ich jetzt auch ein extrem großer Punkt dabei,
wenn ich meine. Prozessschritte habe. Dann habe ich natürlich auch die Teams, beispielsweise die für diese Abschnitte der Entwicklung verantwortlich sind und dadurch, dass ich dann so eine getrennte. Arbeitsweise sozusagen.
Hab oder Themen hab ist Kommunikation extrem entscheidend zwischen diesen Silos Teams wie man es auch immer nennen möchte und da hapert es halt ganz oft dran, gerade wenn Unmut reinkommt, wenn Druck reinkommt und Schuldzuweisung als höchste Stufe der Eskalation, weil dann ist eigentlich schon echt viel verloren wenn du anfängst dich gegenseitig fertig zu machen sozusagen, da ist halt ein Riesenpunkt den ich da auch sehe, weshalb es Änderungen
geben musste. Und. Auch natürlich die langen Entwicklungszeiten, weil die führen ja dazu, dass du auf jeden Fall eine hohe Komplexität in deinen Änderungen hast, weil in einem Jahr entwickelt man nicht wenig und da jetzt ein neues Release von zu machen, bedeutet einfach auch eine hohe Komplexität, sei es in die Integration der bestehenden Software, was auch immer du hast auf jeden Fall einen großen Batzen angesammelt, um es mal ganz sinnbildlich zu machen und der muss.
Jetzt irgendwie in die Software oder muss irgendwie an den Kunden gelangen und da hast du halt ein so hohes Fehler Potenzial wie du schon meintest, dass es halt auch n riesen Punkt dabei der geändert werden müsste. Na fein, muss man sich überlegen. Wenn du jetzt zum Beispiel dieses typische Nadel im Heuhaufen. Suchst so. Je kleiner der Heuhaufen ist, desto schneller kannst du die Nadel einfach finden und der Heuhaufen ist sozusagen.
Der Analogie. Und wenn du jetzt quasi die ganze Scheune voll hast und da ist irgendwo eine Nadel, die irgendwie direkt in der ersten Woche des letzten Jahres da irgendwo hingelegt wurde. Blöd gesagt. Ja, wie? Das ist sehr aufwendig. Dann brauchst du gefühlt die dreifache, vierfache Zeit, um die überhaupt wieder zu finden und dann ist noch nichts gefixt. Wenn das jetzt ein Bug ist. Die Nadel sind wirklich.
Ja, und natürlich, was damals auch der Fall ist, dass es viele manuelle Prozesse gab, weißt du auch, meintest mit, es kann keine Routine reinkommen, wenn manuell relevant wird einmal im Jahr und man sagt so, jetzt ist es soweit, das ist jetzt, jetzt ziehen wir eine Version fest, da ist hoffentlich alles drin, was wir uns vorgenommen haben laut der Antwort und ab zum Kunden
damit. Und einmal im Jahr etwas durchführen, wie du schon meintest, kann keine Routine bedeuten und diese ganzen Punkte jetzt noch mal zusammengefasst. Das ist ne große Katastrophe. Führt zu dieser Downword Spiral und deswegen musste eine Bewegung geschaffen werden. Ins Leben gerufen werden die auch bis heute anhält. Und diese Bewegung nennt sich Death Orbs und deswegen würde ich sagen, lass uns doch mal kurz erklären, ganz.
Als obergeordnetes topic sag ich mal was ist dev orps und wie kann es dabei helfen aus dieser Downword Spiral auszubrechen. Wie würdest du das mal so in paar Sätzen zusammenfassen? Ja, also erstmal so grob von dem was ist eigentlich genau das ist
im Endeffekt also def. Steht halt für Development und OPS steht für Operations, also eine Entwicklung und Betrieb der Software und in der traditionellen Softwareentwicklung waren das Halt auch immer 2 verschiedene Teams. Die komplett sage ich jetzt mal oder verhältnismäßig autark gearbeitet haben und. Das Hauptproblem war halt sag ich jetzt mal, der Kommunikationsweg zwischen diesen beiden ne. Also die Kommunikation war sehr gering, sagen wir mal so.
Und. Dev Ops soll genau diese beiden Bereiche zusammenführen, also Development und Operations, und halt eben für ne höhere Zusammenarbeit und ne viel viel bessere Kommunikation sorgen. Zwischen diesen beiden Teams. Ne, man kann theoretisch sogar soweit gehen, dass man sagt es könnte ein Team sein am Ende. Genau, aber.
Sei mal dahingestellt. Und ja, genau, und im Endeffekt sind mal blöd gesagt, was sind was die Ziele am Ende sind, ist natürlich genau die Probleme die du so n bisschen angeschnitten hast. Ne. Also es soll natürlich darauf, also es soll möglichst versucht werden, dass. Ne ne. Software in einer hohen Qualität schnell und zuverlässig bereitgestellt werden kann. Ne, also wenn die Entwicklung
stattgefunden hat, dann muss. Sag ich jetzt mal grob auf den Punkt gebracht, die Software in kürzester Zeit zur Verfügung stehen für die, die damit arbeiten. Sagen wir mal den Usern. Ja. Und das natürlich zuverlässig, also dass man halt nicht sagt. Ich weiß nicht, ob das jetzt funktioniert, sind da irgendwie
Probleme drin, ne? Also im Prinzip also im Prinzip, um genau diese Release Zyklen, diese elendig großen, die wir ja angesprochen haben, muss natürlich um dieses Problem zu lösen, ist ja der logische Schritt zu sagen, wir müssen öfter. Releasen genau, kleinere Release. Zyklen also, damit du nicht diesen diese Riesenkomplexität da drin hast, macht es ja Sinn zu sagen, dann releasen wir öfter.
Mit kleinerer Komplexität, weil wir einfach eine höhere Zuversicht haben und weniger fehleranfällig sind. So, das ist ja so die Theorie, quasi was man versucht mit DEV ops zu lösen, absolut richtig. Wie findest du also die Kommunikation, die du, sage ich mal herausgestellt hast? Ist ja auch. Also es muss ja ein Wandel stattfinden innerhalb, also bei den Mitarbeitern, wie du schon meinst. Wir haben jetzt nicht Operation und Development, sondern default.
Du beides zusammen, das heißt, man versucht ja, wie du vorhin so schön gesagt hast, diese Kluft zu überbrücken, diese Mitarbeiter wieder aneinander zu führen und miteinander arbeiten zu lassen. Das heißt, da muss ja auch so n Wandel im im Mindset stattfinden. Und ich finde, das ist halt auch ein großer Teil von Dev ops. Dass da also Kommunikation ist, n Riesenpunkt dabei.
Ich meine, am Ende ist es ja auch wieder ne mal blöd gesagt ne Art. Ne Art und Weise zu arbeiten, irgendwo ganz gewisse gewisses Framework. Also dir dir wird ja keiner sagen, bei dev ops macht genau dies und das und das, sondern das ist ja kein. Tool was du installierst und dadurch kannst du jetzt besser Software release. Ist ja wie du meinst ein Framework, aber im Sinne von. Richtlinienprozessen und Mindset halt, wie die Leute damit umgehen mit diesem Problem.
Ne und wenn wenn du halt dieses Mindset nicht hast, dann dann wird es halt auch nicht richtig gut funktionieren. Also ich sag mal so, wenn du sagst Release die Software schnell, dann gibt es vielleicht die einen die sagen ja gut, wir haben vorher in einem Jahr Release und jetzt releasen wir in einem halben Jahr das ist doch schnell so und andere sagen ein halbes Jahr ist nicht schnell jeden Monat ist schnell und andere sagen. Release jeden Tag, keine Ahnung.
Ja, genau das ist ja dann wieder projektabhängig. Also klar, es macht nicht Sinn. Bei manchen Projekten macht es keinen Sinn wöchentlich zu releasen und bei anderen macht es wiederum keinen Sinn ein halbes Jahr zu warten, weil du einfach schnell deine Änderungen, also schnell wirklich im Sinne von schnell wöchentlich raushauen möchtest und dem Kunden bereitstellen möchtest. Beispielsweise. Du hast jetzt ne Website und dein Frontend, da willst du schnell Änderungen raushauen.
Das haust du einfach direkt raus sag ich mal ne oder sagen wir mal wöchentlich wie auch immer kurze Zyklen, das ganze würde ja jetzt bei ner Entwicklung von irgendeiner großen Software. Nicht unbedingt Sinn machen, dass du sagst, wir hauen jetzt jedes jede Kleinigkeit direkt an den Endkunden raus. Keine Ahnung nimmst du weiß ich nicht irgendein Office Produkt Skype weiß ich nicht, irgendwelche kaufsoftware ne.
Weil da würden sich die Leute auch denken, ja, was ist denn jetzt passiert, also was ist denn jetzt die, die die neuen Features an der Software, das ne also das ist ja projektabhängig einfach absolut klar. Wichtig dabei ist ja aber auch, dass du halt irgendwie schaffen musst, so Feedback einzubauen, damit du halt von diesem traditionellen Wasserfallmodell wegkommst und schnell n Feedback bekommst, ob du quasi überhaupt
auf dem richtigen Weg bist. Und das betrifft ja wiederum alle Projekte. Ne und was ich halt spannend finde ist wenn man sagt gehen wir mal davon aus oder bezeichnen wir es wirklich als Mindset, weil wir beide betrachten das ja auch so. Dann kann man ja auch sagen, wie ist denn, wie ist denn DEV OPS entstanden und gerade in einer Zeit, wo eh sage ich mal so agile Methoden aufkam.
Agile Arbeitsweisen, was ja auch wiederum ein Mindset ist zu sagen okay, wir gehen jetzt von diesen starren Prozessen weg und versuchen eine agile um also ein agiles Umfeld zu schaffen in in unserem Projekt geschehen, um einfach Feedback zu haben, um reagieren zu können, nicht so stark zu sein und genau in dieser Zeit ist ja auch diese Dev ops Bewegung entstanden, weil du halt verwandte Probleme hast. Oder wie siehst du das? Auf jeden Fall.
Also es kommt ja sogar auch noch dazu, dass sich Technologien verändert haben, also gerade in Bezug zum Beispiel auf Cloud Computing hattest du ja irgendwann auch einfach die die Möglichkeit durch. Sag ich jetzt mal infrastructure as code. Auch im Endeffekt über dein, also über eine Art von von Code Beschreibung deine Infrastruktur aufzubauen. Was ja auch zusätzlich zu der agilen Arbeitsweise auch noch dazu geführt hat, dass zum Beispiel. Den Entwicklern oder den
Entwicklerinnen? Immer mehr sage ich jetzt mal Zugriff zu der Infrastruktur gewährt wurde und demzufolge hast du ja teilweise sogar auch, dass es, dass es Sinn macht, dass du sagst, du führst Development und Operations vielleicht zusammen oder sage ich. Mal. Die Kommunikation dazwischen ist sehr eng oder es ist sogar das gleiche Team, wie gesagt. Also dass das bedingt sich dann im Endeffekt auch ein bisschen. Also du hast würde ich sagen, so ein bisschen diese Erkenntnis.
Also erstmal hast du die die grobe sage ich jetzt mal gesamtsituation, dass du halt immer schnellere auf immer schnellere Veränderungen eingehen musst. Du musst quasi darauf agieren können und sagen können okay es kommt eine neue Anforderung rein, wir müssen darauf irgendwie reagieren, wir müssen damit umgehen können. Das hat natürlich dazu geführt, dass es neue Methoden und Arbeitsmodelle gab, wie du meintest.
Diese agilen Methoden und zusätzlich kam ja zumindest dann auch noch wahrscheinlich auch einfach aus. Der Möglichkeit, dass es, dass sich die Technologie entwickelt hat und natürlich auch, weil es einfach Sinn macht, sowas zu
tun. Aber das ist eine andere Folge, dass man halt eben auch so Infrastructure AS Code hat und im Endeffekt auch die Möglichkeit hat, als Entwickler oder Entwicklerin Zugriff auf die Infrastruktur zu erhalten, auf einer ganz anderen Art und Weise, wie es vorher möglich war. Ja, da kann man ja sagen, dadurch, dass quasi diese Möglichkeit geschaffen wurden, hat sich ja damals dann auch so eine Art Community, was heißt so eine Art, definitiv eine Community gebildet mit Koma.
Wir haben jetzt neue Möglichkeiten beziehungsweise wir müssen neue Möglichkeiten schaffen, wie machen das denn andere, und das ist ja auch das geile dabei. Das Communities sich gebildet haben, das ist erste Konferenzen gab, das hat mich mal interessiert, habe ich mal so ein bisschen recherchiert, also scheinbar gab es 2009, das ist halt wirklich schon eine Weile her, also mit 20 Jahren zurück waren wir gar nicht so schlecht, wo es denn so langsam los ging.
Dass sich 2009 das erste Mal die Konferenz Dev OPS Days gab und das so als Meilenstein gilt zu sagen, OK, jetzt tun sich die Leute zusammen und tauschen Best Practices aus. Wie löst ihr Probleme, was habt ihr für? Reicht OK, hier gibt es ein neues Tool. Wie sieht es aus? Ah ja cool, das löst ja das und das Problem im Bereich Automatisierung ist ja so unfassbar viel entstanden in den letzten Jahren, weil man einfach sagt, OK, in diesem traditionellen.
Dieses manuelle integrieren und ausliefern, das war so fehleranfällig, da ist so viel schief gegangen und das hat so unfassbar viel Geld gekostet am Ende, weil Zeit ist Geld für ne Firma, das heißt es kostet Unmengen an Geld, da irgendwelche Sachen. Fixen oder überhaupt dann erstmal ne ne vernünftige Version quasi an den Kunden zu bringen und deswegen sind da halt so unfassbar viele Themen und Tools entstanden und das find ich halt extrem extrem
spannend muss ich sagen und da würd ich halt auch gerne dann im Laufe dieser. Dev Ops Reihe auch mal so auf verschiedene Sachen eingehen, weil es halt ja in meinen Augen wirklich ein spannendes Thema ist. Natürlich sind wir auch in der Zeit.
Absolute Klassiker nenn ich's mal an Büchern entstanden, die sich mit diesen Themen auseinandergesetzt haben und dieses Wissen, was gesammelt wurde, zusammenfassen, beispielsweise Steff Ops Handbook ist so ein wirklich wirklicher Klassiker, den man sich ruhig mal anschauen sollte, wenn man sich für den Bereich der Forbes interessiert. Ich glaube dieses wie heißt es, Fenix Project ist so ein richtiger Klassiker, der immer genannt wird, wenn es um Death
Ops geht. Witzigerweise kennst du das Unicorn Project, das ist nämlich quasi glaube ich das gleiche. Gegensatz. Na ja, ja, können wir auf jeden Fall auch mal verlinken. Das sind wirklich gute Bücher, die wir empfehlen können. Ja, genau, und dann ist halt diese Bewegung entstanden. Es wurden Best Practices ausgetauscht, Communities haben sich gebildet und es gab halt ne Riesen. Ja, ich, ich übertreibe mal. Revolution in dieser Softwareentwicklung aus Sicht.
Der der Operations sag ich mal und natürlich auch Development. Das hat ja genauso Einfluss gehabt. Aber ich möchte auch nicht zu viel vorweggreifen. Wir haben es mal so n bisschen abgesteckt, was es zu beheben gibt und wie dev ops das quasi, also wie das entstanden ist.
Die Frage ist ja, und das ist so jetzt so n bisschen der Ausblick auf die Reihe, was für Punkte beinhaltet denn DEV Ops für dich, also welche Punkte haben sich denn so über die Jahre herauskristallisiert, die dazu führen, dass man aus dieser, wie du gesagt hast, Down Words spiral? Ausbrechen. Kann. Ja, also was, was fallen dir denn so für Punkte ein, damit man schon mal gleich so eine Übersicht hat für die kommenden Folgen? Ja, genau so ein Ausblick ist
wahrscheinlich nicht schlecht. Ist jetzt vielleicht auch nicht absolut vollständig und sehr detailliert, aber im groben und ganzen, was wirklich ein wichtiger Punkt ist, ist halt eben. Automatisierung, da geht es ja genau darum, um halt eben manuelle Prozesse möglichst.
Zu automatisieren dann sowas wie Continuous Integration oder kontinuierliche Integration des Codes in die Codebasis und natürlich auch eine kontinuierliche Bereitstellung, also Continuous Deployment. Das ist sozusagen dann wirklich. Dass die Code Änderung auch sag ich jetzt mal beim User ankommen. Ne grob. Zusammengefasst einmal sehr wichtige. Punkte auf jeden Fall. Genau dann natürlich auch die Zusammenarbeit und Kommunikation. Wie gesagt, wie das so n bisschen verbessert wurde oder
was da genau mit gemeint ist. Zum Beispiel welche Möglichkeiten es da gibt, was ich schon angesprochen hatte war Infrastruktur als Code. Und auch ein sehr wichtiger Punkt, um halt eben dieses Nadel im Heuhaufen finden.
Möglichst zu vereinfachen, ist zum Beispiel sowas wie die Anwendung Monitoren und auch loggen, was in der Anwendung passiert, also Monitoring und Login und was auch wichtig ist, ist die Kultur, die dann sich sozusagen daraus daraus aufgebaut hat, und zwar sage ich jetzt mal eine Kultur der ständigen Verbesserung, also du möchtest am Ende sagen okay. Wenn es etwas zu verbessern gibt, dann wollen wir es
verbessern, weil wenn. Man so n bisschen das Gefühl gehabt hat wahrscheinlich, dass die traditionelle Softwareentwicklung zu lange, wie wir sie besprochen haben, zu lange so geblieben ist, wie sie geblieben ist und wenig die Probleme, die die Issues adressiert. Hat oder vielleicht weggehört? Hat. Und wenn du aber jetzt eine Kultur aufbaust, die sich sagt, wir müssen uns ständig verbessern, wir müssen gucken,
wo die Pain Points sind. Und müssen da auch reingehen in diese Paintpoints. Dann ja, das ist also die letzten 2 Punkte, die du genannt hattest. Ich hoffe es waren die letzten 2 halbwegs sicher. Sind sehr wichtige Punkte in meinen Augen und habe.
Ich habe auch das Gefühl, dass sie oft so ein bisschen hinter hinten runterfallen, was dem nicht gerecht wird, weil diese ganze Feedbackkultur und auch diese Kultur sich ständig verbessern zu wollen und halt hinzuschauen, wo schmerzt das denn in der Entwicklung und was können wir besser machen, sind halt ein wirklich essentieller Bestandteil dabei. Und da freu ich mich auch drauf, wenn wir diese Themen bisschen genauer beleuchten. Dann, was heißt n bisschen
ausführlich beleuchten. Ja, ansonsten würd ich sagen, haben wir es doch eigentlich ganz geil eingeleitet. Also ich hab jetzt richtig Bock auf die Reihe mit dir, weitere Folgen dazu aufzunehmen. Ich hoffe du auch fabi und natürlich hoffe ich liebe zuhören liebe Zuhörer, dass dir diese Folge diese Einleitungsfolge auch gefallen hat und du jetzt Feuer und Flamme bist mehr über Deathrops
zu erfahren. Deswegen würde ich sagen, falls du Feedback zu der Folge hast oder auch Anmerkungen, vielleicht auch noch ein paar coole Punkte hast, wie Death Ops entstanden ist, wie das früher aussah, schreibt uns gerne über die Podcast Mail, die links auch zu allen anderen Plattformen findest du wie immer in den Shownotes, wenn du allgemeine Anmerkungen zu unserem Podcast hast, auch gerne uns schreiben, wenn du Verbesserungsvorschläge hast, weil wir leben auch diese
verbesserungs Feedback Kultur und freuen uns über jedes Feedback was wir bekommen. Ansonsten würde ich sagen. Eine letzte Sache noch, falls. Du unseren Podcast weiterempfehlen empfehlen möchtest, ans Vielleicht 23 freuen würde uns das auch sehr sehr dolle helfen und gefallen. Das wäre super. Vielen Dank, denn schon mal dafür. Und ansonsten würde ich sagen, hören wir uns beim nächsten Mal wieder. Macht ihr noch einen schönen Tag bis dahin deine Coding Boys. Gemeinsam besser. Was?