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.