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