Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #1 - Die Bewegung

Transcript

DevOps #1 - Die Bewegung · Coding Buddies | Tech & Dev-Mindset

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