Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #2 - Die Grundprinzipien und Methoden

Transcript

DevOps #2 - Die Grundprinzipien und Methoden · Coding Buddies | Tech & Dev-Mindset

• 0:00
  Man kann ja weiter ein kleines Gedankenspiel machen, um sich
• 0:02
  das noch mal bildlich vorzustellen.
• 0:04
  Ja, ich liebe die Damenspiele. Oh Yeah, Gedankenspiele Coding
• 0:07
  Buddies. Dein Podcast rund um
• 0:09
  Softwareentwicklung und aktueller Technews.
• 0:12
  Herzlich Willkommen. Halli Hallo und herzlich
• 0:25
  Willkommen zur neuen Folge des Koding Bodys Podcasts.
• 0:28
  Schön, dass du wieder eingeschaltet hast.
• 0:30
  Meine Wenigkeit ist wieder dabei, der Tino und natürlich
• 0:32
  auch der fantastische Fabi Moin Fabi.
• 0:35
  Grüße dich halli Hallo Tino. Was geht ab?
• 0:39
  Alles gut bei dir? Was geht alles im Lot, wie man
• 0:43
  so schön sagt. Ja, alles das ist schön, das ist
• 0:46
  so n schönes Sprichwort, ne, alles im Lot.
• 0:48
  Zwar nie verstanden wieso man sagt alles im Lot, weil
• 0:50
  eigentlich heißt das ja solche alles senkrecht, aber ich
• 0:52
  versteh es nicht, weil das Boot da nicht umkippt oder was keine.
• 0:55
  Ahnung sicherlich sicherlich. Vielleicht.
• 0:57
  Das macht. Legt also mich, hast du
• 0:58
  überzeugt. Ja, mich hast du überzeugt, das
• 1:01
  klingt gut, klingt gut, ja, auf jeden Fall schön, dass wir alle
• 1:04
  wieder hierhergefunden haben zur neuen Folge.
• 1:07
  Wir haben uns ja überlegt, ich geh einfach mal direkt ins Thema
• 1:10
  rein heute. Wir haben uns ja überlegt, lass
• 1:13
  uns die nächste Folge unserer Dev Ops Reihe machen, wir haben
• 1:17
  ja beim letzten Mal quasi. Eine Übersicht gegeben darüber,
• 1:22
  warum überhaupt diese DEV Ops Bewegung entstanden ist.
• 1:27
  Welche ja, nennen wir es mal nett gesagt, Herausforderungen.
• 1:31
  Diese traditionelle Software Entwicklung hat oder hatte und
• 1:35
  ja genau warum daraus diese Motivation entstanden ist etwas
• 1:39
  zu ändern und diese deops Bewegung aufkam.
• 1:43
  Und an der Stelle würde ich auch sehr gerne wieder ansetzen, dass
• 1:47
  wir sagen, OK, es gibt jetzt quasi diesen Aufbruch oder
• 1:51
  diesen Umbruch, besser gesagt. Und würde gerne mit dir.
• 1:56
  Ja, ich würde jetzt nicht sagen, ne weitere einführungs Folge
• 1:59
  machen, weil die erste war ja eher so ne Art Motivation,
• 2:03
  sondern. Jetzt ne Überblick geben, quasi
• 2:07
  gerade für Leute die sich vielleicht im deapops Bereich
• 2:10
  noch nicht auskennen, damit wir einfach mal so abstecken, was
• 2:14
  gibt es alles in der Dev Ops Welt.
• 2:17
  Wie findest du die Idee, dass wir einfach mal so auf
• 2:19
  Grundprinzipien eingehen, auf ja auch Methoden und Best practices
• 2:23
  und da man einen geilen Überblick geben.
• 2:26
  Genau, also einfach so eine Übersichtsfolge finde ich gut.
• 2:30
  Wir sollten oder wir können natürlich gucken, wenn man jetzt
• 2:32
  sagt, das ist jetzt nicht nur für Leute, die da im Kontext
• 2:36
  schon unterwegs sind, also für die Leute wäre es was, also für
• 2:40
  Leute, die zum Beispiel auch ein bisschen fortgeschrittener sind
• 2:42
  und sagen okay, ich kenn mich zwar schon ein bisschen mit aus
• 2:45
  und bin vielleicht auch schon in der Arbeitswelt unterwegs, aber
• 2:48
  man kann ja jetzt zum Beispiel diese Folge nehmen und gucken,
• 2:50
  so als Checkliste und sagen, wie sieht es denn aus, wenn, machen
• 2:54
  wir das auch so oder gibt irgendjemand vor, ja, wir machen
• 2:57
  hier voll deops aber eigentlich stimmt das gar nicht oder so.
• 3:00
  Also da kann man sich das einfach mal hernehmen und sagen,
• 3:03
  OK, was sind denn eigentlich so die Prinzipien, die auf jeden
• 3:06
  Fall irgendwie vorhanden sein sollen, um oder müssen sollten,
• 3:10
  um halt auch wirklich davon zu sprechen, dass es das wirklich
• 3:13
  dev ops praktiziert wird. Und genau so ist es natürlich
• 3:16
  auch für jeden oder jede. Staat, der startet und
• 3:22
  vielleicht noch nicht so weit ist, vielleicht auch gerade
• 3:23
  anfängt, eine Programmiersprache zu lernen und vielleicht sich
• 3:26
  denkt ja diese ganzen dev Sachen, das ist ja noch ein
• 3:29
  bisschen weiter entfernt, hilft aber trotzdem auch einfach
• 3:33
  schon. Ein Gefühl dafür zu kriegen.
• 3:36
  Also je früher man Sachen irgendwie weiß, desto früher
• 3:39
  kann man ja auch damit irgendwie mit der Übung anfangen und desto
• 3:41
  früher ist man auch einfach besser.
• 3:44
  Und also ich weiß nicht, ob du das kennst, Tino, aber ich habe
• 3:46
  manchmal so Momente, wo ich irgendwas höre und mir denke so,
• 3:49
  ja ja okay alles klar, ob ich das jetzt so mache oder nicht
• 3:52
  und trotzdem ist es im Hinterkopf und ich denke mir so,
• 3:55
  ich hab da mal gehört so und so und eigentlich.
• 3:57
  Genau, was ich dann mit dem Thema genauer beschäftigt.
• 4:00
  Ja, finde ich gut. Wie gesagt, die bezogen über
• 4:03
  zur. Wenn du schon fortgeschritten
• 4:04
  bist, dann betrachte das ruhig als Checkliste, falls da jetzt
• 4:07
  nicht sag ich mal so viele neue Punkte dabei sein sollten.
• 4:11
  Wir geben uns aber Mühe um nen guten Überblick zu geben, genau.
• 4:15
  Und ja, und selbst wenn man nicht mit DEV OPS zu tun hat,
• 4:19
  hilft es ja auch allein um mal zu verstehen, wie überhaupt so
• 4:22
  große bekannte Services, Services, Services.
• 4:26
  Klingt komisch. Verwendet, ja, sei es Netflix
• 4:30
  oder irgendwas, was quasi so im Alltag von vielen ja konsumiert
• 4:36
  wird, sage ich mal zu verstehen, wie überhaupt, wie kann es
• 4:39
  überhaupt sein, dass ich so schnell an die Updates komme?
• 4:41
  Warum ändert sich die Seite gefühlt täglich und alles solche
• 4:45
  Punkte wo die Antwort Death Ops auch ist am Ende?
• 4:49
  Können wir da den mit beleuchten?
• 4:50
  Das wäre doch ganz cool. Genau dann würde ich sagen,
• 4:54
  lasst uns doch mal direkt reinstarten was sind denn für
• 4:57
  dich so? Also wenn du sage ich mal hörst
• 5:00
  oder die Aufgabe bekommst Kategorisiere doch mal die Welt
• 5:04
  von Dev ops, was gibt es da so für Bereiche wo du sagst das ist
• 5:09
  auf jeden Fall ein großer Punkt, wenn es um das Thema Dev OPS
• 5:13
  geht. Ja, also da gibt es jetzt eine
• 5:16
  Menge und die wollen wir jetzt einfach mal alle durchgehen.
• 5:21
  Was mir als erstes in den Kopf kommt, ich glaube, damit fängt
• 5:23
  das auch an, ist im Endeffekt die Kultur und die
• 5:26
  Zusammenarbeit, die sich ja auch.
• 5:28
  Durch dev Ops, ich sag mal verändern soll ne ob es das dann
• 5:33
  immer wirklich tut ist da immer die andere Geschichte, aber das
• 5:36
  ist ja erstmal so die Theorie und die Praxis ist dann
• 5:38
  hinterher immer so noch so, dass das i Tüpfelchen.
• 5:41
  Aber Fakt ist ist, dass man ja. Sich gesagt hat, aus den
• 5:45
  Problemen der letzten Folge, die wir ja auch genannt haben, dass
• 5:48
  sich ja irgendwas verändern muss, und das sind ja nicht nur
• 5:50
  diese Techniken, die man verwendet.
• 5:53
  Also ich sag jetzt mal auch bestimmte.
• 5:57
  Tools, die dann. Diese Techniken ermöglichen, die
• 6:00
  auch durchzuziehen, sondern halt.
• 6:01
  Also das ist dann eher so diese wie sagt man die Hard Skills ne,
• 6:05
  also kann ich damit umgehen, praktiziere ich diese Technik
• 6:09
  auch richtig und aber auch die Softskills, also eben genau
• 6:13
  diese. Kultur, die dahinter steht, habe
• 6:15
  ich auch das Mindset, um wirklich das Ganze auch so
• 6:19
  durchzuziehen. Und da gibt es jetzt mal so ein
• 6:21
  paar Dinge, die mir direkt zum zu diesem, zu diesem, dieser
• 6:25
  Kultur beziehungsweise zu der Zusammenarbeit einfallen, die ja
• 6:30
  verbessert werden soll durch DEV ops, und zwar sollen ja
• 6:33
  bestimmte Punkte abgehandelt werden, wie zum Beispiel Abbau
• 6:37
  von Silos, es geht jetzt um wissenssilos können wir gleich
• 6:40
  näher darauf eingehen, dann eine gemeinsame Verantwortung im Team
• 6:43
  für das entsprechende Produkt. Entsprechende Anwendungen, die
• 6:46
  gebaut werden, soll dann auch kontinuierliches Lernen und eine
• 6:50
  Verbesserung, also lernen für sich selber und eine
• 6:52
  Verbesserung für sich selber und die Software zum Beispiel und
• 6:56
  auch eine Transparenz und eine Sichtbarkeit.
• 7:00
  Also dass man eben bestimmte Probleme, die in der Software
• 7:03
  sind halt auch nicht einfach nur so kapselt, sondern auch
• 7:06
  transparent nach außen zeigt, aber auch zum Beispiel selber
• 7:09
  mit Fehlern offen und transparent umgeht.
• 7:11
  Ne, also was ich jetzt hier sage ist nicht nur, dass es auf
• 7:13
  Software Ebene stattfindet, sondern auch auf menschlicher
• 7:15
  Ebene und man soll auch kundenorientiert sein.
• 7:18
  Also klar kann man sich jetzt hinstellen und sagen, gut man
• 7:20
  macht so User Research und fragt den Kunden, was könnte man denn,
• 7:23
  was möchtest du gerne alles haben.
• 7:25
  Hat meiner Meinung nach aber auch ein bisschen was damit zu
• 7:27
  tun, wie man zum Beispiel mit dem Kunden redet.
• 7:30
  Und das ist wieder. Softskill, und das sind so für
• 7:34
  mich, sage ich jetzt mal so 5 Punkte, die ich gerade genannt
• 7:36
  habe, die essenziell sind, bevor man überhaupt mit irgendwelchen
• 7:39
  Praktiken, Techniken auch so weiter anfängt, dass das auch
• 7:43
  irgendwie sitzen muss und dass ich das im Team verändern muss.
• 7:46
  Also quasi was du damit meinst ist, wenn ich jetzt zum Beispiel
• 7:49
  sage, ich möchte jetzt. Dev Ops Praktiken in meinem
• 7:54
  Unternehmen zum Beispiel etablieren oder implementieren,
• 7:58
  weil wir, weil das Halt einfach noch nicht der Fall ist.
• 8:01
  Dann fängt dieser Wandel eigentlich auch im Kopf an, wie
• 8:05
  man immer so Plakatativ. Sagt aber das ist ja eigentlich
• 8:07
  wirklich so. Genau.
• 8:09
  Das heißt, du kannst jetzt nicht anfangen, sämtliche Methoden,
• 8:12
  aber wir werden ja noch n Paar nennen, in dieser Folge
• 8:14
  anfangen, diese zu implementieren.
• 8:16
  Wenn du gar nicht sozusagen dahinter stehst oder vom Kopf
• 8:19
  her weißt, warum du das tust. Genau, genau das ist halt ein
• 8:23
  sehr, sehr wichtiger Knackpunkt, weil du kannst dich natürlich
• 8:26
  hinstellen und sagen, mach bitte dies, mach bitte das mit, Mach
• 8:28
  bitte das die Software soll so und so funktionieren und so
• 8:33
  automatisiert sein sage ich jetzt mal.
• 8:36
  Aber du weißt gar nicht, was ist denn der Benefit davon?
• 8:39
  Und ja, ich will aber zum Beispiel, ich bedenke
• 8:42
  eigentlich, dass ich wirklich ziemlich gut bin und ich denke
• 8:45
  auch, dass die Software, die ich geschrieben habe, wirklich gut
• 8:47
  ist. Also was soll ich daran
• 8:48
  verbessern? Also solche Sachen weißt du.
• 8:50
  Und wenn du mit diesem Mindset da nicht da rein gehst und auch
• 8:53
  sagst okay ich glaube ich kann irgendwie immer was verbessern
• 8:57
  und immer irgendwie mich oder die Software verändern und
• 9:00
  verbessern, dann wird. Es glaube ich schwierig, diesen
• 9:03
  ganzen Depotgedanken überhaupt wirklich von vorne bis hinten
• 9:06
  auch durch zu. Tragen.
• 9:08
  Ne, absolut ja. Ich fand auch gut, dass du
• 9:10
  direkt diesen Feedback Punkt noch mal genannt hast, weil das
• 9:14
  hatten wir ja schon in der 1. Folge, aber ich will es noch mal
• 9:16
  aufgreifen, weil es wirklich extrem wichtig ist.
• 9:19
  Ist halt auch diese Feedback schleifen zu haben im Verhältnis
• 9:23
  zur alten Welt, dass du sagst okay, wir brauchen dieses
• 9:26
  Feedback, wir wollen ja aktiv aus dem was geschehen ist,
• 9:30
  lernen sowohl von positiven. Meldungen als auch von negativen
• 9:35
  und halt diese Retrospektive zu leben sozusagen genau, genau.
• 9:42
  Auf menschlicher Ebene dann am Ende zum Beispiel auch.
• 9:47
  Also dass man, sagen wir mal, sich zusammensetzt und sagt
• 9:50
  okay, was, was ist geschehen und welche Learning zielen wir
• 9:54
  daraus, das ist, das ist ja auch wirklich ein essentieller Punkt.
• 9:59
  Als Grundprinzip würde ich das halt auch so sehen, absolut.
• 10:04
  Dann lasst uns aber mal ein bisschen technischer werden.
• 10:06
  Da sind ja glaube ich, auch die spannenden.
• 10:09
  Obwohl das auch wirklich wie gesagt sehr spannend und wichtig
• 10:11
  ist. Ein weiterer Punkt glaube ich,
• 10:14
  an dem man nicht vorbeikommt, sind auch so diese ganzen
• 10:18
  Überwachungsthemen, die können wir denn auch gerne
• 10:22
  tiefgründiger thematisieren, weil das da gibt es auch eine
• 10:24
  Menge zu, sag ich mal, zu erzählen.
• 10:27
  Also ich bin jetzt gedanklich beim Monitoring Logging quasi
• 10:32
  einfach die Art Überwachung, was passiert denn eigentlich in
• 10:36
  meinem Unternehmen sozusagen. Es noch mal allgemein halten und
• 10:40
  wie kann ich überhaupt erkennen, dass was schief läuft oder dass
• 10:43
  etwas geklappt hat? Werde ich darüber informiert,
• 10:46
  wenn etwas schief läuft, wie lange dauert das bis ich es
• 10:49
  erkannt habe, dass etwas schief läuft und das sind ja alles so
• 10:52
  Aspekte, die da eine entscheidende Rolle spielen am
• 10:54
  Ende und das auch ein sehr großer Punkt ist, also
• 10:57
  beispielsweise was ich meinte mit Netflix will jetzt ein
• 11:02
  Update ausrollen, die haben an ihrer Seite was geändert.
• 11:06
  Wann oder wie schnell würden Sie denn erfahren, wenn da was
• 11:09
  schiefgelaufen ist? Ist.
• 11:11
  Ja. Ne, und das sind das sind halt
• 11:15
  sehr, sehr spannende Themen und die vielleicht, wo manche sich
• 11:17
  denken, ja gut loggen Herr loggen nervt oder Monitoring,
• 11:21
  aber das ist nachher wertvolle Zeit die.
• 11:25
  Die man einsparen kann, um quasi Systemfehler zu erkennen und zu
• 11:29
  beheben. Genau durch diese Methoden.
• 11:32
  Deswegen ist es essentiell. Das ist auf jeden Fall n guter
• 11:35
  Punkt, weil Monitoring und Logging beziehungsweise auch
• 11:39
  Obsoletity was das genau am Ende ist, das wollen wir auch noch
• 11:43
  mal in der eigenen Folge ein bisschen aufschlüsseln und da
• 11:45
  genauer drüber reden. Aber Fakt, es ist ja, dass auch
• 11:48
  genau was du eben gerade noch mal am Ende von dem ersten Punkt
• 11:52
  sage ich jetzt mal meintest. Feedback, Das ist ja im
• 11:55
  Endeffekt jetzt nicht das Feedback auf menschlicher Ebene,
• 11:58
  sondern das ist ja wirklich auch Feedback auf Anwendungsebene.
• 12:01
  Das heißt, du hast irgendwo ein Problem wie du meintest.
• 12:04
  Netflix zum Beispiel bricht immer.
• 12:08
  Bei 60% des Streams bricht auf einmal deinen Film ab und wie
• 12:13
  schnell kriegt Netflix das mit? Und das ist ja genau dieses
• 12:17
  Feedback, was sozusagen dann an die entsprechenden Personen
• 12:21
  wieder zurückgeführt wird auf technischer Ebene am Ende.
• 12:25
  Absolut und also im Prinzip. Du willst ja wissen, wie stabil
• 12:28
  ist mein Gesamtsystem genau über alle Aspekte hinweg, ja.
• 12:32
  Also das finde ich halt, ist irgendwie das interessante, weil
• 12:35
  diese Kultur, die wir in Punkt 1 angesprochen haben, zieht sich.
• 12:39
  Sowohl menschlich als auch über die Anwendung drüber.
• 12:42
  Weil, und das finde ich jetzt noch mal, will ich noch mal
• 12:44
  unbedingt noch mal rausstellen, weil du kannst dich natürlich
• 12:46
  hinstellen und sagen, OK, meine Anwendung muss das und das
• 12:48
  können. Aber eigentlich muss nicht nur
• 12:52
  die Anwendung, sondern auch das Team, was mit dieser Anwendung
• 12:55
  sag ich jetzt mal arbeitet oder mit dem System nennt wie du
• 12:57
  möchtest, muss eigentlich genau auch diese.
• 13:02
  Sag ich mal diese Kultur erfüllen und oftmals bleibt man
• 13:05
  bei der Anwendung oder bei den Systemen hängen, guckt aber
• 13:09
  nicht auf die kulturelle Seite von vom Team, wie das Mindset im
• 13:15
  Team verbreitet ist. Das ist finde ich ist es so ein
• 13:17
  kleiner kleiner Unterschied. Ich hoffe ich konnte noch mal
• 13:19
  rausstellen, weil das ist ein wichtiger Punkt, weil ohne das
• 13:22
  eine funktioniert das andere am Ende nicht richtig.
• 13:25
  Korrekter. Und deswegen nochmal dieses
• 13:28
  Monit. Ing.
• 13:29
  Logging ist irgendwo, Feedback auch.
• 13:33
  Also wenn sich das natürlich am Ende keiner anguckt oder darauf
• 13:35
  reagiert, dann hast du ja auch nichts gewonnen.
• 13:39
  Genau. Das wäre noch ein wichtiger
• 13:42
  Punkt. Ich überlege gerade, was wir
• 13:44
  schon hatten. Ach so, Oh, warte, warte, warte
• 13:46
  das eigentlich mit. Das Wichtigste hatten wir noch
• 13:48
  nicht, das wäre jetzt echt witzig, wenn wir es vergessen
• 13:51
  hätten. Sind natürlich die ganzen
• 13:52
  Automatisierungsthemen dahinter. Also ich glaube, wenn man.
• 13:58
  Von Death Ops hört oder liest wird relativ schnell in den
• 14:03
  ersten Sätzen ja Begriffe wie Pipeline, CICD auftauchen.
• 14:08
  Und das sind ja im Prinzip alles Punkte, die in
• 14:11
  Automatisierungsmethoden. Beziehungsweise ja Mechaniken
• 14:17
  reinspielen und da würd ich gern noch mal mit dir drauf eingehen,
• 14:21
  weil das wirklich denk ich mal, das kann auch so mit der
• 14:23
  Hauptteil unserer heutigen Folge sein, weil ich glaub das wird n
• 14:25
  bisschen dauern jetzt darüber zu sprechen.
• 14:28
  Aber was kommt denn als erstes dir in den Sinn, wenn es heißt
• 14:34
  dev Ops Automatisierung? Warum überhaupt genau also?
• 14:39
  Für mich ist halt warum ist natürlich, das sind eigentlich
• 14:42
  genau diese Themen, die wir kurz vorher einmal so ein bisschen
• 14:44
  angesprochen haben, die auch in diese Kultur einpreisen, was mir
• 14:47
  aber als erstes in den Sinn kommt, wenn man jetzt von
• 14:50
  Automatisierung spricht, ist. Oder was so der erste
• 14:53
  Anlaufpunkt ist, eine CI, also dieses Continuous Integration.
• 14:58
  Also wenn man jetzt so von dieser technischen Kette guckt
• 15:02
  und da geht es ja darum, dass man irgendwie in der Lage ist zu
• 15:06
  sagen okay, du hast irgendwie Änderungen an deiner Software,
• 15:09
  das heißt, du musst irgendein neues Feature implementieren und
• 15:12
  dann musst du irgendwie sagen okay, ich möchte jetzt meinen
• 15:15
  neuen Code, den ich habe in meine.
• 15:19
  Codebasis integrieren und damit das auch automatisiert
• 15:22
  funktioniert. Also du könntest ja sagen, naja,
• 15:24
  pass auf ich. Push jetzt den Code und
• 15:28
  irgendwer reviewed das und sagt OK, das passt und integriert
• 15:30
  das. Aber das ist ja keine
• 15:32
  Automatisierung am Ende, sondern du hast ja den Punkt, dass
• 15:35
  jemand manuell noch drauf gucken muss.
• 15:37
  So mal blöd gesagt und dann wirklich sagen muss OK check
• 15:40
  passt. Klar kann man jetzt auch sagen,
• 15:42
  ist ja ein Code Review sollte man jetzt auch nicht unbedingt
• 15:45
  komplett lassen was ich meine ist es, dass du durch zum
• 15:48
  Beispiel automatisierte Tests in der Lage bist zu sagen.
• 15:52
  Funktioniert der Code so wie er soll und wenn ja, dann darf er
• 15:55
  integriert werden beispielsweise.
• 15:57
  Ja, so, dass er für mich jetzt erst Punkt genau, ich gehe mal
• 16:01
  ein Stück zurück. Wenn du jetzt von diesen
• 16:03
  Automatisierung sprichst, dann ist das in meinen Augen ja so,
• 16:08
  es ist ja etwas zu automatisieren, ist ja sehr
• 16:11
  effizienzsteigernd greife ich noch mal jetzt das Beispiel auf,
• 16:15
  wenn wir jetzt von. Continuous Integration sprechen,
• 16:19
  was du ja gerade meintest. Dann kann ich natürlich genauso
• 16:23
  hast du ja richtig gesagt, alles manuell machen.
• 16:25
  Ich kann meine Änderung einpflegen, ich kann manuell die
• 16:29
  Software testen, was mir so einfällt an Test Cases und kann
• 16:32
  am Ende sagen grüner Haken, das kann so bleiben das passt der
• 16:35
  Stand alle können weiter damit arbeiten.
• 16:37
  So, dann hab ich das alles manuell gemacht.
• 16:39
  Das ist natürlich alles andere als effizient.
• 16:43
  Zusätzlich ist die Wahrscheinlichkeit groß, dass
• 16:46
  der Mensch, der das Macht, auch Fehler macht, logisch ist
• 16:51
  einfach menschlich, ja, sagt man ja so schön und um das quasi zu
• 16:56
  verhindern, hat man ja auch angefangen Prozesse zu
• 16:59
  automatisieren, weil wenn ich ZB manuell immer die gleichen Tests
• 17:03
  mache. Ich Klick dahin in der
• 17:05
  Anwendung, dann da. Dann logge ich mich ein hier und
• 17:08
  probiere das beispielsweise, oder ich habe Funktionen und
• 17:13
  gebe immer die gleichen Werte rein und gucke, dass das
• 17:15
  Richtige rauskommt. Das sind ja so typische Sachen,
• 17:17
  die immer wieder getestet werden, und da kommen wir ja
• 17:20
  genau zu dem Punkt zu sagen, lasst uns doch Tests schreiben
• 17:24
  und die automatisiert laufen lassen, wenn Änderungen
• 17:27
  eingepflegt werden, weil das einfach wesentlich effizienter
• 17:30
  ist, es viel schneller geht, als wenn quasi jemand manuell das
• 17:34
  alles. Und wenn die Tests einmal da
• 17:37
  sind, hast du ja auch diese Komponente eines menschlichen
• 17:42
  Fehlers rausgenommen aus dem System.
• 17:44
  Und da, das finde ich, ist halt auch noch mal das noch mal, um
• 17:47
  das klarzustellen oder heraus zu kristallisieren, ist ja ein
• 17:50
  riesen Pluspunkt oder Argument Sachen zu automatisieren, weil
• 17:55
  ganz ehrlich, wer kennt es nicht, du du machst eine Aufgabe
• 17:59
  irgendwas am PC, du machst das fünfmal, du machst das zehnmal,
• 18:02
  das läuft, du bist eigentlich richtig routiniert und trotzdem
• 18:04
  kommt das eine mal wo du dich verklickst.
• 18:06
  Was falsch eingibst oder irgendeinen Fehler machst.
• 18:08
  Es passiert doch einfach und genau das kannst du damit ja
• 18:11
  auch, denn quasi verhindern sozusagen.
• 18:14
  Ja, also selbst wenn du in deiner Automatisierung dann auch
• 18:18
  diesen Klick vergisst, dann kannst du ja zumindest sagen,
• 18:21
  OK. Wenn ich den aber dann einmal
• 18:23
  wieder reinsetze, weil ich merke, das wurde vergessen, dann
• 18:26
  ist er aber dann auch immer wieder da.
• 18:28
  Genau so ne. Das ist also wenn das mein ich
• 18:30
  ja, wenn die Tests stimmen und einmal sitzen sozusagen und das,
• 18:34
  dann kriegst du ja immer die gleiche, also es ist immer der
• 18:37
  gleiche Test, dann halt ne genau.
• 18:39
  Richtig. Aber was ist denn das nächste?
• 18:41
  Also wir haben jetzt CI also CI gehabt, ne das ist ja das
• 18:44
  Continuous Integration, das heißt Integrierung von neuem
• 18:47
  Code in die Code Basis, mal grob zusammengefasst automatisiert.
• 18:52
  Na dann haben wir ja noch Continuous Delivery schrägstrich
• 18:56
  Deployment, also CD, um das Beispiel aufzugreifen.
• 19:02
  Mit der Änderung auf der Page von Netflix.
• 19:04
  Ich gehe jetzt einfach mal weiter auf das Beispiel ein.
• 19:06
  Ist es ja die eine Sache, kontinuierlich Änderung in die
• 19:10
  Codebasis zu integrieren. Der zweite Punkt ist, diesen
• 19:13
  aber auch auszurollen an die Kunden also quasi zu
• 19:16
  veröffentlichen genau und das Ganze.
• 19:20
  Kann genauso automatisiert werden.
• 19:23
  Also angenommen wir sind jetzt an dem Punkt und sagen, ja, wir
• 19:26
  haben jetzt Änderungen eingepflegt, unsere Tests sind
• 19:28
  alle grün, es ist quasi. Korrekt, die Änderung, sie
• 19:33
  funktioniert und ist eingepflegt, dann kommst du ja
• 19:36
  irgendwann an den Punkt wo du sagst ich möchte jetzt aber
• 19:39
  diese Änderung, die sich jetzt da angesammelt haben auch quasi
• 19:42
  also an die Kunden ausrollen, veröffentlichen.
• 19:46
  Und. Wenn du gerade bei Netflix bist,
• 19:48
  dann gibt wurde ja zum Beispiel wahrscheinlich, vielleicht kennt
• 19:51
  das kennen das einige, dieses diese Netflix Games, die waren
• 19:55
  ja vorher nicht da, es war was neues und es wurde dann im
• 19:58
  Endeffekt irgendwann ausgerollt an die User ne also diese
• 20:01
  Änderung wurde dann zur Verfügung gestellt.
• 20:04
  Da gibt es halt unterschiedliche Praktiken, verfahren das, das
• 20:10
  wird auf jeden Fall noch mal eine eigene Folge, weil das ein
• 20:11
  riesen Bereich ist. Aber um das kurz
• 20:14
  zusammenzufassen, dieser. Kann automatisiert werden und
• 20:18
  verhindert dann auch wiederum. Genauso wie bei CI, dass da
• 20:22
  Fehler bei passieren. Wenn ich das automatisiert habe
• 20:24
  und quasi mein System da beziehungsweise die Pipeline wie
• 20:28
  ich anfangs schon erwähnt hatte, man nennt das ja den Pipeline
• 20:32
  quasi wenn die funktioniert, dann wird sie das auch immer
• 20:35
  wieder tun, sozusagen. Genau, was ich interessant finde
• 20:38
  ist und ich weiß nicht, ob man das vielleicht gemacht hat, weil
• 20:40
  es kann ja durchaus sein, dass ich vielleicht einige Fragen
• 20:43
  okay. Moment mal.
• 20:45
  Also was ist denn jetzt der Unterschied?
• 20:46
  Also automatisch? Das ist doch eigentlich normal
• 20:49
  und ich hoffe, dass es, dass es einige gibt, die sagen, das ist
• 20:52
  doch ganz normal so, aber. Was ich interessant finde, ist
• 20:57
  ich würd mal gern wissen, wer hat das schon mal gehabt, zum
• 21:01
  Beispiel n Frontend Änderung an dem Frontend.
• 21:04
  Das einfachste ist, du machst. Integrierst sozusagen mit CI
• 21:09
  dein deine Software, also deine Änderungen im Repository.
• 21:13
  Es wird getestet, es wird automatisiert deployed und am
• 21:16
  Ende siehst du diese aktualisierte Website, was aber
• 21:19
  eigentlich dahinter steckt ist und das hab ich einmal gemacht,
• 21:23
  ist jetzt schon ein bisschen länger her, ich habe Änderungen.
• 21:27
  Musste ich immer wieder neu zusammenpacken, also bauen sage
• 21:31
  ich jetzt mal das Frontend musst ne neue bauen und dann dieses
• 21:34
  Artefakt was dann dabei rauskommt an einen bestimmten
• 21:38
  Punkt legen, damit von dort aus diese sozusagen diese live.
• 21:42
  Website angezogen wurde, also da, wo das herkam.
• 21:46
  Ne, also irgendwo hast du ja n Punkt, wo sag ich jetzt mal
• 21:48
  deine deine Website welche auch immer sagt OK von da bezieh ich
• 21:53
  meine mein Dasein und genau. Dieses dieses Dasein hab ich.
• 21:57
  Sozusagen immer manuell ausgetauscht, weil es eben
• 21:59
  dieses Deployment nicht gab. Dieses automatisierte, und das
• 22:03
  ist halt krass, weil dann. Ich kann nur jedem empfehlen das
• 22:07
  mal Spaß ist Cyber zu machen, weil jedes Mal wenn man
• 22:09
  irgendwie ne kleine Änderung macht, müsstest du ja eigentlich
• 22:11
  diesen ganzen manuellen Schritt wieder machen.
• 22:14
  Und das geht jetzt nicht um testen und die Integration, das
• 22:16
  müsstest du wahrscheinlich vorher auch noch machen, aber
• 22:18
  dann zusätzlich noch. Diesen ganzen Kram
• 22:21
  zusammenpacken, das ist jetzt nicht viel, aber wie du
• 22:23
  meintest, so du du machst vielleicht 45 Steps, aber die
• 22:27
  gehen ja schon irgendwann total auf den Keks, weil du irgendwie.
• 22:29
  Vielleicht das ganze ineffizienter.
• 22:31
  Genau. Du machst das vielleicht, du
• 22:33
  machst es einmal am Tag. OK, ist nicht so wild so, du
• 22:35
  machst es zehnmal am Tag, es geht dir total auf den Keks so,
• 22:38
  das ist halt das Ding und das wird einem halt irgendwann
• 22:41
  abgenommen, weil diese Zeit, die du da auch Reinsteckst am Ende
• 22:44
  gibt dir auch keiner wieder. Ja, man kann sich das ja auch
• 22:50
  ganz einfach veranschaulichen, indem man sagt, okay, ich habe
• 22:53
  jetzt ein kleines Programm geschrieben, so ein Stand alone
• 22:57
  Programm und ich möchte es einfach zum Beispiel auf dem
• 22:59
  Netzlaufwerk oder in der Dropbox oder was weiß ich irgendwo zur
• 23:02
  Verfügung stellen, dann würdest du ja die nötigen Dateien dahin
• 23:05
  kopieren, andere können darauf zugreifen und das verwenden.
• 23:08
  So. Jetzt hast du ein Update, wie du
• 23:10
  so schön meintest. Neue Version.
• 23:12
  Ach ja warte mal, die möchte ich jetzt zur Verfügung stellen,
• 23:14
  also kopiere ich jetzt alle Files wieder dahin und das ist
• 23:17
  ja genau dieser. Step was du meintest.
• 23:19
  Und jetzt kann ja jeder für sich glaub ich relativ schnell die
• 23:22
  Frage beantworten. Wenn jetzt sag ich mal minütlich
• 23:26
  ist jetzt mal übertrieben, aber selbst wenn schon stündlich
• 23:30
  Änderungen reinkommen und du willst sie jedes Mal ausrollen,
• 23:33
  du wirst ja nicht einmal die Stunde anfangen diese Fallzahlen
• 23:35
  zu kopieren und das ist halt genau der Punkt den du meintest
• 23:38
  und dann kommt man schnell quasi zu dem Schluss, oh man, das muss
• 23:42
  automatisiert werden und im Prinzip wäre das auch eine Form
• 23:45
  von Continuous Deployment. Wenn du sagst ich schreib mir
• 23:47
  ein Skript was die Files einfach.
• 23:49
  Kopiert genau genau. Also das ist ja witzig, weil du
• 23:51
  kommst ja relativ schnell auch eigentlich an diese Idee zu
• 23:54
  sagen, irgendwas muss sich am Tag öfter machen, warum mache
• 23:58
  ich das nicht über n Skript oder so und am Ende sind das ja, also
• 24:02
  du kannst ja bestimmte Services nutzen, die irgendwie da sind,
• 24:05
  also zum Beispiel wenn du dieses CI und CD beispielsweise mit
• 24:09
  Amazon Web Services machst, das sind ja auch Files und Skripte,
• 24:12
  die da laufen, das hat ja auch irgendjemand mal gebaut, weil
• 24:16
  ich finde es manchmal auch dann interessant, ich habe schon
• 24:18
  öfter mal. Gespräch geführt dass es darum
• 24:21
  ging. Na ja, bei uns kann das aber so
• 24:26
  nicht ganz funktionieren, weil wir können den Service nicht
• 24:28
  benutzen und wir haben die und die Möglichkeit nicht und ich
• 24:31
  find, das ist immer unglaublich essenziell und wichtig ist für
• 24:33
  dieses Ganze. Für diese ganze Kultur und
• 24:38
  dieses Mindset, dass man nicht sagt, es geht nicht, sondern wie
• 24:40
  kriege ich es hin. Und wenn du dir dann einfach
• 24:43
  selber bestimmte. Frameworks schaffst, dann hast
• 24:48
  du am Ende auch was gewonnen und das ist halt das Ding.
• 24:49
  Also es ist halt die Frage, was ist deine Vision und wie kommst
• 24:53
  du dahin und nicht ja das das geht so nicht, ne und das ist
• 24:56
  wichtig noch n kleiner Side Note Sorry kleiner Side Note weil das
• 24:59
  ist vielleicht noch nicht ganz durchgekommen.
• 25:02
  Es gibt also du meinst am Anfang also CD, Continuous Delivery
• 25:06
  Continuous Deployment sind 2 verschiedene Sachen.
• 25:10
  Das hat auch, da ist auch noch mal die Frage, so was ist zum
• 25:12
  Beispiel der Unterschied zwischen Continuous Delivery und
• 25:14
  einem Release, beispielsweise hat man vielleicht auch schon
• 25:17
  gehört, diese Wörter, das sind aber Sachen, da würde ich gerne
• 25:20
  in der expliziten Folge dann nochmal drauf eingehen.
• 25:23
  Okay gut, ich hoffe du schreibst wird, was wir denn da, damit wir
• 25:26
  die ganzen folgen dann machen können.
• 25:30
  Genau da kommen wir zum nächsten Punkt, nur ganz kurz, weil wir
• 25:33
  hatten da schon drüber gesprochen.
• 25:34
  Man muss natürlich an der Stelle auch Continuous Testing nennen,
• 25:38
  was ja quasi auch so Teil des CI s ist, weil man sollte nichts
• 25:42
  integrieren, ohne es vorher getestet zu haben, Leute ganz.
• 25:45
  Ganz wichtig also würd ich das mal so n bisschen
• 25:48
  zusammenfassen, aber im Prinzip das automatisierte Testen in so
• 25:52
  einer Pipeline ist auch n wesentlicher und sehr wichtiger
• 25:54
  Bestandteil über alle Stages hinweg.
• 25:57
  Also je nachdem was für Tests da laufen, dass man jetzt so
• 26:00
  zusammengefasst. Ja, hast du noch einen Punkt?
• 26:07
  Was mir noch einfällt ist nämlich Infrastructure Code.
• 26:10
  Das ist ja. Im Endeffekt.
• 26:15
  Wieder ne Sache. Es ist ja auch ne Sache von
• 26:17
  Automatisierung, weil du kannst dich zum Beispiel hinstellen und
• 26:20
  sagen, ey, ich brauche gerade jetzt zum Beispiel in Cloud
• 26:23
  Umgebungen, aber vielleicht auch auf einem eigenen Server.
• 26:27
  Wir können ja mal diese beiden Beispiele kurz gegenüberstellen.
• 26:29
  Wenn du sagst, ich hab jetzt irgendein Cloud Service, dann
• 26:32
  kannst du in einem Cloudservice sagen, ich brauche zum Beispiel
• 26:35
  ne Datenbank, ich brauche. N Frontend n Backend Service ne
• 26:41
  die heißen immer ein bisschen unterschiedlich was man da halt
• 26:43
  verwendet. Nur mal sowas.
• 26:44
  Also man braucht verschiedene Bestandteile, also auch
• 26:48
  irgendwas um zum Beispiel Domains auflösen zu können, dass
• 26:50
  man weiß wo geht denn zum Beispiel www.google.de hin oder
• 26:53
  sowas, das sind ja alles wichtige Komponenten und diese
• 26:56
  Komponenten kann man wenn man möchte selber immer manuell auf,
• 27:01
  also erstellen sich sozusagen zusammenklicken in den Web
• 27:04
  Service, genauso kannst du deinen Server der neu geliefert
• 27:08
  wird. Gehen kannst oder kannst du dich
• 27:11
  zu Draufschalten mit dem eigenen Rechner kannst weiß nicht
• 27:13
  Software 1 installieren, Software 2 installieren was auch
• 27:16
  immer das sind ja alles Sachen wo du sagst OK das kannst du
• 27:19
  zwar immer manuell machen, ist aber vielleicht keine ideale
• 27:22
  Lösung, also gibt es Infrastructure ascode was sind
• 27:24
  kurze zusammengefasst. Skripte sind oder sage ich jetzt
• 27:30
  mal, Beschreibungen in Form von Textdateien oder Code, die genau
• 27:34
  das machen, was du dann immer machen möchtest.
• 27:36
  Also du kriegst einen neuen Server zu Hause und sagst, hier
• 27:38
  muss ich konfigurieren, ich starte mal Script a und dann
• 27:42
  installiert er die Sachen und setzt den Server so auf wie er
• 27:44
  es machen muss. Das ist halt im Endeffekt auch
• 27:46
  wieder ein Punkt von manueller Arbeit zu automatisierter Arbeit
• 27:51
  über infrastructures Code. Also im Prinzip du Codest oder
• 27:56
  sagen wir mal Script ist deine Umgebung sozusagen, die du
• 28:00
  brauchst für deine Pipeline, um dann quasi immer wieder mit
• 28:04
  diesen Skripten die gleiche Umgebung aufbauen zu können.
• 28:08
  Genau und nur nochmal kurz zusammengefasst.
• 28:12
  Das hat natürlich auch einen großen Vorteil.
• 28:15
  Und zwar hatten wir auch schon mal über Versionierung
• 28:17
  gesprochen in unserem Podcast und das ist genau der Vorteil,
• 28:20
  der da auch greift in dem Moment, wenn ich quasi meine
• 28:24
  Infrastruktur codiert, Abbilde oder gescripterd, kann ich diese
• 28:29
  versionieren, weil. Wir haben ja vorhin über
• 28:33
  Stabilität des Systems gesprochen, angenommen, da
• 28:36
  treten Änderungen auf oder irgendwas bricht zusammen, kann
• 28:40
  ich halt auch meine ganze Infrastruktur auf einen Stand
• 28:43
  dann zurücksetzen, der funktioniert hat.
• 28:45
  Wenn jetzt zum Beispiel irgendwas korruptes reinkommt
• 28:48
  oder eine Änderung, die nicht gepasst hat, und das finde ich,
• 28:50
  ist auch ein wichtiger Punkt, dass ich quasi diese ganze
• 28:54
  Infrastruktur, also Infrastruktur, versioniert habe.
• 28:59
  Da habe ich auch schon ein bisschen was zu erlebt.
• 29:00
  Aber das ist auch wieder eine Sache, können wir sicherlich
• 29:03
  noch mal ein eigenes Thema drüber machen, ist auf jeden
• 29:05
  Fall glaube ich, auch relativ umfangreich das ganze, aber
• 29:08
  damit man sich auf jeden Fall vorstellen kann, was das
• 29:10
  überhaupt ist und was es so für Vorteile bietet, ist es ja
• 29:13
  erstmal schon mal ein ganz, ganz guter Überblick, also definitiv,
• 29:16
  das sind wirklich wertvolle Punkte dann auch am Ende also
• 29:20
  diese Automatisierung und diese Wiederherstellbarkeit auf jeden
• 29:23
  Fall. Genau.
• 29:24
  Und in dem Zusammenhang wird man ja auch oft mit Begriffen wie
• 29:29
  Docker, also Container. Konfrontiert, Orchestrierung,
• 29:34
  kybernetes was es da alles gibt, was würde ich denn da auch mit
• 29:38
  reinpacken? Definitiv, weil das auch
• 29:40
  wirklich coole Tools sind und auch sehr mächtige und viele
• 29:44
  Pluspunkte mit sich bringt, die wir dann mal beleuchten können.
• 29:48
  Liebe, zuhören, Liebe zuhören sei gespannt auf diese Folge.
• 29:52
  Genau das sind so grobe Punkte. Hast du noch was?
• 29:58
  Nee, ich muss sagen das das war es glaub ich.
• 30:00
  Also ich würd es vielleicht noch mal kurz zusammenfassen, weil es
• 30:02
  ist ja wenn man jetzt noch mal sagt OK der Überblick über dev
• 30:06
  ops ne also es ist devops umfasst ne Menge das sind jetzt
• 30:10
  erstmal sehr große und grobe Punkte, aber die sind auf jeden
• 30:14
  Fall sehr essentiell um überhaupt mit Dev Ops überhaupt
• 30:17
  davon reden zu können okay das ist jetzt aber auch def Ops was
• 30:21
  wir hier machen. Ist es wichtig, dass man auf
• 30:24
  jeden Fall, wie wir schon gesagt hatten, eine gewisse Messung,
• 30:28
  Überwachung, also nicht Überwachung im Sinne von
• 30:30
  Überwachung von Mitarbeitern, sondern Überwachung der
• 30:32
  Software? Dieses Logging Monitoring und.
• 30:39
  Das habe ich jetzt gesagt. Logging, Monitoring und
• 30:41
  Observability das ist ein wichtiger Punkt.
• 30:45
  Dann die kontinuierliche Verbesserung im Sinne von auch
• 30:47
  der Kulturansicht, die dahinter steht, also dass man zum
• 30:51
  Beispiel wissen nicht in Silos packen, das ist nicht ein
• 30:54
  Mitarbeiter und Mitarbeiterin gibt die wirklich sehr, sehr
• 30:56
  viel wissen hat, und wenn die in Urlaub geht, dann war es das so
• 30:59
  nach dem Motto. Da ne gemeinsame
• 31:01
  Verantwortlichkeit, dass nicht einer sagt, das ist aber nicht
• 31:04
  meins, also da ist irgendwas an der Infrastruktur kaputt, sorry
• 31:07
  das mache ich nicht. Das kontinuierliche Lernen und
• 31:10
  das Verbesserung, die Verbesserung, die ich meinte.
• 31:12
  Also man arbeitet an sich selber und versucht also ne sich selber
• 31:16
  zu verbessern aber auch zu gucken wie könnte ich die
• 31:18
  Anwendung verbessern, weil menschlich ist auch immer ein
• 31:21
  wichtiger Punkt daran zu arbeiten, Transparenz und
• 31:24
  Sichtbarkeit zu sagen okay den den Usern nach außen zu
• 31:28
  spiegeln, was zum Beispiel läuft denn gerade nicht rund oder sich
• 31:32
  auch selber einzugestehen. Ich habe zum Beispiel vielleicht
• 31:34
  gerade einen Fehler gemacht, das ist genauso transparent.
• 31:38
  Und halt diese Kundenorientierung zu sagen okay
• 31:39
  was, was soll diese Anwendung eigentlich wirklich machen oder
• 31:44
  arbeiten wir komplett daran vorbei?
• 31:45
  Das ist ja so diese Kultur und dazu halt noch mal die
• 31:50
  Automatisierung für CD, was wir genannt haben sehr sehr wichtig,
• 31:54
  sollte man unbedingt haben, Infrastrukture ist Code wenn es
• 31:57
  darum geht Infrastrukturen aufzubauen.
• 32:01
  Automatisiert im Falle von Ausfällen zum Beispiel sehr
• 32:04
  wichtig und eben auch die Testautomatisierung.
• 32:08
  Und dieses Continuous Testing was du meintest, was ja im
• 32:10
  Endeffekt so n bisschen vielleicht auch Teilmäßig in
• 32:14
  DCI. Geschichte reingehört.
• 32:18
  Genau und auch gerade bei infrastructures Code hat man
• 32:22
  auch sehr viel wahrscheinlich mit Orchestrierung zu tun.
• 32:26
  Das sind auf jeden Fall so die groben Punkte oder die großen
• 32:28
  Punkte, die auf jeden Fall irgendwie vorhanden sein
• 32:32
  sollten, wenn man irgendwie im Kontext von Deavops arbeitet.
• 32:37
  Ja, also man kann auch mal da n kleines Gedankenspiel machen, um
• 32:40
  sich das noch mal bildlich vorzustellen.
• 32:42
  Ja, ich liebe die Damenspiele. Oh ja, Gedankenspiele uh jetzt
• 32:45
  zum Abschluss der Folge noch n Gedankenspiel.
• 32:49
  Ein also stellen wir uns doch mal vor, du bist jetzt
• 32:51
  Mitarbeiter in einem Unternehmen.
• 32:53
  Wo? Sämtliche.
• 32:56
  Deathrops Methoden super integriert sind, also das läuft
• 32:58
  wirklich wie am Schnürchen, wie würde das denn aussehen Sonntag,
• 33:02
  man würde ja im Prinzip erstmal morgens aufstehen, sein
• 33:06
  Kaffeetrinken, Nein, also ohne Kaffee geht genau, ohne Kaffee
• 33:10
  geht in keinem Unternehmen was. Man hat eine Änderung, so, man
• 33:15
  hat quasi neues Feature entwickelt.
• 33:17
  Man hat lokal seine Tests laufen lassen, man hat seine Tests
• 33:21
  erweitert, so ganz normale Workflow sage ich mal wie wir so
• 33:25
  jetzt bei uns hätten, dann würde ich das Einchecken, die Pipeline
• 33:29
  läuft los, also wir sind jetzt im CI ct Bereich sage ich mal
• 33:33
  die Tests laufen, es funktioniert alles ist grün, das
• 33:36
  heißt die Änderung ist integriert, unsere Pipeline
• 33:39
  funktioniert dann so, dass sie sagt okay wir haben eine
• 33:41
  Änderung, wir werden die sofort an die Kunden ausspielen, weil
• 33:44
  so sicher sind, dass das gute Qualität hat.
• 33:47
  Unsere Pipeline ist sehr robust, unser Gesamtsystem und im
• 33:50
  Endeffekt. Ich mal wird es einfach direkt
• 33:54
  ausgerollt, dann sind wir beim Deployment Delivery Bereich so.
• 33:58
  Der Kunde hat das. Auf einmal läuft aber was
• 34:01
  schief, zum Beispiel auf der Netflix Seite ist jetzt ein
• 34:03
  Anzeigefehler und es gibt ne Rückmeldung.
• 34:06
  Ja das heißt wir kriegen ein Feedback relativ schnell und
• 34:10
  können quasi daran analysieren mit unseren Logs, mit unserem
• 34:15
  Monitoring was schiefgelaufen ist, finden den Fehler, können
• 34:20
  ihn beheben, so haben also eine sehr schnelle Reaktionszeit.
• 34:24
  Wer super Death Ops practice. Können sofort wieder die
• 34:28
  Änderung integrieren, den Fix ausrollen.
• 34:31
  Der Kunde ist zufrieden. Und jetzt noch, dass der
• 34:35
  Anfangspunkt, der nämlich wichtig dabei ist, diese
• 34:37
  Lernkultur, danach, sich hinsetzen und sagen okay, warum
• 34:41
  ist das passiert und wie können wir das nächstes Mal verhindern?
• 34:44
  Und da kann ja ein ganz klassischer Fall sein, es wurde
• 34:46
  irgendein Hase in den Test vergessen, das wurde nicht
• 34:48
  abgetestet und ist halt durchgerutscht, passiert aber
• 34:52
  dank unserer Dev Ops Strategien konnten wir super schnell darauf
• 34:55
  reagieren und es ist ein sehr geringer Schaden entstanden.
• 34:58
  Und was ich auch immer sehr wichtig finde, ist, dass man an
• 35:01
  der Stelle bei diesem Feedback. Bei diesem gucken, OK, was ist
• 35:03
  denn da gerade eigentlich passiert?
• 35:05
  Dieses Post mortem, sage ich, nenne ich das jetzt mal zu
• 35:08
  sagen, OK. Du kommst jetzt nicht an den
• 35:11
  Punkt, dass du sagst, wer war das und du bist jetzt dran,
• 35:14
  sondern zu sagen. Wie konnte das passieren?
• 35:18
  Gut, dass wir draus gelernt haben und am besten, wenn das
• 35:21
  nicht noch mal auftritt, weil erstens ist es menschlich
• 35:24
  tausendmal besser, weil du dann halt eben nicht jemanden völlig
• 35:28
  wie sagt man und. Unterbutterst würde ich schon
• 35:31
  sagen, aber ich und Sprichwörter, also jemandem
• 35:34
  deine Stärke auf, wir machen halt so, Schnecke macht ne, das
• 35:37
  bringt gar nichts, weil diese Person ist irgendwann nur noch
• 35:39
  eingeschüchtert vielleicht und sagt OK, dann mach ich halt gar
• 35:42
  nichts mehr das das bringt gar nichts, sondern zu gucken, OK,
• 35:44
  wie gehen wir auch gesund im Team mit der Sache um, weil Shit
• 35:48
  happens, was willst du dann machen Zeit zurückgehen
• 35:50
  funktioniert nicht, das ist auch noch mal wichtig, genau aber in
• 35:54
  dem Sinne danke Tino für diese kurze Zusammenfassung.
• 35:57
  Des optimalen Death of Tages noch mal am Ende.
• 36:00
  Kurz und knackig, das war super. Hat mir sehr viel Spaß gemacht,
• 36:04
  diesmal vielleicht noch eine bisschen kürzere Folge als
• 36:06
  sonst. Und dann gehen wir in den
• 36:08
  nächsten Folgen natürlich in die tieferen Themen oder einzelne
• 36:11
  Themen tiefer rein, so rum und in diesem Sinne würde ich die
• 36:14
  Folge schließen. Danke Tino, Es hat Spaß gemacht.
• 36:16
  Ja, auch danke an dich. Fabi hat Spaß gemacht.
• 36:18
  Und genau dann hoffe ich auch, dass dir Liebe zuhören, lieber
• 36:22
  zuhören, diese Folge gefallen hat.
• 36:23
  Gib uns gerne Feedback. Also schreib uns auf der Podcast
• 36:28
  Mail. Wenn du auch Fragen hast.
• 36:29
  Du kannst auch gerne gerne gerne den Podcast bewerten.
• 36:33
  Und wenn dir der Podcast gefällt, dann hast du die
• 36:37
  Möglichkeit, uns auch zu unterstützen und zu sagen, das
• 36:39
  ist der Knaller. Den Podcast hör ich gerne, da
• 36:42
  lass ich doch ne kleine Spende da oder?
• 36:44
  Ansonsten empfehl den Podcast einfach 223 deiner Freunden oder
• 36:48
  Freundinnen weiter, würde uns super freuen.
• 36:50
  Ansonsten links zu den Plattformen und unserer Mail von
• 36:54
  uns findest du auch in den Shownotes und ich würde sagen,
• 36:56
  wir hören uns in der nächsten Folge wieder.
• 36:58
  Deine Coding Buddies gemeinsam. Besser.