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?