Was ist denn das für ne Scheiße? Wieso geht das nicht?
Ich rufe jetzt mal den Support an, weißt du als Entwickler
Entwicklerin schon? Bereits ja.
Ey, da ist ein Problem, daran arbeite ich mal.
Bodies Dein Podcast rund um Softwareentwicklung und
aktueller Tech News. Herzlich Willkommen.
Einen wunderschönen guten Tag hier zum Coding Bodies Podcast
mal wieder. Ich bin dabei der Fabi und Tino
natürlich auch, ist doch klar. Yeah, Hallo Tino, Na was geht
ab? Endlich wieder Podcast.
Es geht mal wieder los. Langes her.
Lang ist her also für unsere Zuhörerinnen und Zuhörer, nicht
aber für uns schon. Du warst ja im Urlaub, wir haben
ja quasi vorgearbeitet, die Podcast folgen aufgenommen und
letzter Sekunde. Immer wieder Rhythmus letzter
Sekunde. Ja, wie war dein Urlaub, geht es
dir gut? Ja, voll tiefenentspannt würde
ich mal so ein bisschen so redet, dann ist das echt voll
entspannt. Nee, war geil.
Ich war surfen, ich hab mal surfen ausprobiert, also so
richtig so in den Wellen und so. O Yeah, erzähl war geil.
Geht es war geil sogar. Freundlich.
Tatsächlich schon ganz geil. Also es war ja am Atlantik.
Also du hast geile Wellen und so, das geht schon ordentlich
ab, wenn ich mal kurz erzählen soll und so einen Kurs gemacht,
weißt du ja. Also also richtig mit dem Surf
Lehrer so. Ja genau.
Surf Camp, also 5 Tage so einen Kurs und auch selber mal Board
ausgeliehen und dann. Surfen und die Wellen am
Atlantik sind ja meistens ziemlich geil.
Ist ja nicht so Mittelmeer oder so und teilweise ganz am Ende
wurden gefühlt über die Zeit wo ich da war einfach immer größer.
Also am Ende waren es einfach riesen Brecher, da fühlt sich
irgendwann auch so, es war auf jeden Fall ganz geil, weil der
Surf Kurs war cool, hat Spaß gemacht, ich konnte auch
hinterher stehen, ich hab auch richtig ne Welle geritten und
das war schon geil, hat schon Bock gemacht aber faraway vom so
richtig geil sein also wenn ihr da manchmal Surfer gesehen hast
du surferin. Ey, alter Schwede, so geil.
Sieht richtig cool. Aus ne.
Ja, aber wie gesagt, also ein paar große Wellen bin ich auch
gefahren oder geritten oder gesurft wie bei der Sommer nennt
und. Also ist auf jeden Fall geil.
Das Schwierigste ist, finde ich, gar nicht mal aufstehen, sondern
das Timing war ne Welle nimmst hab ich herausgefunden.
Wenn du zu spät oder zu früh ne Welle nimmst, dann kommst du
wieder nicht drauf. Oder willst du einfach nur über
gemäht von diesem, weil da sind so ein paar Feinheiten dabei,
aber ganz ich hab ein so ein Ding genommen und keine Ahnung,
ich war super schnell 200 KMH mindestens mindestens es ging so
ab aber. Ist schon in der Ostsee
angekommen sind. Ja, wir waren.
Reicht ja auch aufs Meer raus. Weißt du nicht so?
Genau herrlich. Aber ich hab, ich hab mal
gehört, dass eigentlich das auch am Anfang super anstrengend sein
soll wegen diesem Ganzen raus paddeln, das also auf dem Brett
liegen und raus paddeln super anstrengend sein soll.
Ich hab ja selbst noch nie gemacht, aber hast du das auch
so wahrgenommen oder? Ja, also am Anfang nimmst du
halt dein Board neben dir und gehst halt so im flachen
Gewässer. Und wenn du aber dann später so
ein bisschen nach dem, was ich so am Ende der.
In der Zeit habe ich dann auch bin ich auch sehr viel
gepaddelt, wie du gerade meintest und ist anstrengend,
also für die Schultern und was ich auf jeden Fall gemerkt habe,
ich voll krass fand war mein Regenbogen hat unglaublich viel
getan weil du liegst die ganze Zeit auf dem Board mit dem Bauch
und guckst du nach oben so weißt du vorne bist du oben und dann
paddelst du oder chillst du so. Und wenn du wartest, halt voll
oft darauf zu wählen, da so gut weißt du, der verpasste eine und
denkst dir so scheiße. Schon wieder verpasst?
Auf jeden Fall tut der Rippen bogen Menschen w muss ich sagen.
So also das ist ne Sache wo ich mir dachte was geht eigentlich
ab aber ja es ist auf jeden Fall anstrengend, auch wenn du im
Wasser bist. Ja, ich glaube, dass das auch
bisschen lernen durch Schmerz ist.
Am Anfang wahrscheinlich ne. Also ich stelle mir jetzt, wir
hatten ja gleich in der allerersten Folge n bisschen
übers Snowboarden geredet, ich würde sagen, da gibt es schon
parallelen oder dass das also. Quasi die Lernkurve.
Schwierig ist also, dass man wirklich eine Weile braucht, bis
man sagen kann, OK, jetzt o jetzt konnte ich mal aufstehen
oder jetzt hab ich wirklich mal geschafft, auf einer Welle zu
reiten, das geht ja wahrscheinlich nicht innerhalb
von einer halben Stunde würde ich mir das jetzt vorstellen,
halt ne du. Brauchst für ein paar Tage so,
aber am Ende kannst du also es ging schneller als ich dachte,
aber am Ende ist es trotzdem halt sag ich mal die
Schwierigkeit welche Wellen da sind, also kleinere Wellen und
so weiter also das ist ein bisschen eine Sache für sich,
aber ich hätte gedacht, dass es schwieriger zu lernen.
Und um deine Frage doch mal so wisst ihr das Statement zu
beantworten? Also Snowboarden lernen tut auf
jeden Fall trotzdem noch mehr w. Ja, Gott sei Dank.
Gott sei Dank ist es nicht noch schlimmer, weil dann, weil ich
eigentlich auch mal das auszuprobieren, zu surfen habe.
Also ich kanns als Snowboard bitte nicht, nee, also.
Zusammenzufassen, das macht Mega Bock, kann ich nur jedem
empfehlen, der irgendwie auch so Board affin ist und Bock drauf
hat. Also das macht Spaß, ist cool.
Ist geil, ja. Coole Sache.
Wenn du Bock hast, die Nase durchzuspülen.
Ja, was passiert wahrscheinlich? Sehr, sehr viel, ja.
Ja, schön, dass du auf jeden Fall wieder da bist, dass du gut
erholt bist, gesund bist, dass du dich nicht verletzt, ist ja
auch wichtig, ja. Mein neues Lieblingsgetränk ist
Salzwasser auf jeden Fall das. Muss Wasser ja schön schön Glas
Salzwasser. Ist auch super eklig, aber
scheiß drauf also. Auf jeden Fall auf.
Jeden Fall eine Menge Salzwasser in meinem meinem Mund Magen
überall. Ich glaub ich wollte halt.
Ja, ich liebe Salz. Jetzt ja, es ist einfach dein
Ding. Sehr gut.
Ja gut, ja, worüber? Wollen wir denn eigentlich heute
sprechen? Ich mein, wir können jetzt die
Folge beenden und das nennen, Fabi lernt surfen, das ist.
Auch nicht schlecht, auf jeden Fall.
Ja, ja, gut eigentlich. Wichtigen Thema raus.
Genau, eigentlich. Wollen wir mal ein bisschen YK,
also was so devops ist, hört man ja öfter mal so in letzter Zeit
beziehungsweise ist ja auch ein sehr etabliertes Modell.
Mittlerweile, und das wollen wir beleuchten, weil wir ja auch in
der PS Team arbeiten, ne genau da.
Können wir ja natürlich dann auch perfekt Bezug zu unserer
eigenen Arbeitswelt nehmen, sag ich mal.
Und auch daran, dass so ein bisschen erläutern, erklären,
was die Vorteile sind und warum man überhaupt nach diesem Modell
arbeitet. Ne, genau.
Ja, ja, also der ist ja im Endeffekt so was.
Woraus setzt sich das zusammen, wir raus, was ist denn, was ist
denn der Ops? Dev Ops ja, im Prinzip ist es
ein zusammengesetztes Wort, also death ist im Prinzip das
Development Team, also die Entwickler der Software.
An sich sage ich mal und ob es steht für Operation wenn ich
mich jetzt nicht. Irre Operation?
Genau. Operations und ist im Endeffekt
ja der IT Anteil ne und es geht halt darum, dass quasi die IT
Leute und die Entwickler an sich.
Mehr zusammenrücken und näher zusammenarbeiten, um einfach
eine bessere Infrastruktur auch bereitzustellen oder
beziehungsweise eine bessere Bereitstellung der Software.
Weil du kannst es ja theoretisch sogar noch soweit, sag ich mal
treiben, dass du sagst, OK, die Leute machen beides
gleichzeitig, also sozusagen Entwicklung der Anwendung und
gleichzeitig den Betrieb, also die Operations diese Anwendung
machen, also das sozusagen nicht mal 2 Teams groß, also sozusagen
nicht mal 2 Rollen das übernehmen, sondern dass eine
Person beide Rollen übernimmt, weißt du?
Kannst du ja auch soweit gehen. Also ja genau, also es geht ja
wirklich darum, dass näher zusammenzuführen.
Wie nah ist natürlich dann einfach wieder projektabhängig
jetzt sowohl Entwickler bist als auch quasi die IT Infrastruktur
bereitstellt. Genau genau weil wir meinten wir
nehmen Bezug zu unserer Arbeitswelt kann man ja sagen,
dass wir wirklich beides sind, vielleicht kommst du, bist du
deswegen jetzt auf diesen Punkt gekommen, also wir entwickeln ja
sowohl Software als auch die Infrastruktur dahinter Software
bereitstellen zu können, also das ist quasi die.
Nächste Form von devops? Genau.
Also das habe ich jetzt zum Beispiel auch vorher gemacht und
schön, dass wir jetzt auch weitermachen können, weil es
halt auch, glaube ich ist ne ganz, ganz coole Sache, so vor
und Nachteile können wir auch noch mal eingehen, aber auch mal
so ein bisschen grob abzureißen, so was umfasst denn also
Development ist irgendwie klar, würde ich jetzt einmal sagen, OK
was Entwicklung wie Entwicklung und so haben wir auch ne Menge
darüber gesprochen, wenn wir uns jetzt mal ein bisschen
Operations Teil konzentrieren, so ne was halt so.
Sag ich mal. Wichtige Bereiche von der
Operation sind, das wäre ja mal interessant zu zu beleuchten.
Ja, also. Prinzip finde ich, sind so die
Kernpunkte. Sind zum einen die
Automatisierung dahinter und worauf wir auf jeden Fall
eingehen sollten, weil es einfach echt überall
mittlerweile zu lesen ist. Ist so dieses typische Stichwort
CICD. Genau, ja, das gehört ja quasi
so ein bisschen. Zusammen genau da mit rein, das
ist irgendwie Automatisierung ne was mir zum Beispiel auch sehr
wichtig ist, zum Beispiel so als als zweiten großen Punkt würde
ich mal sagen, Monitoring und Feedback, dass man halt also
angenommen, weil wir haben ja zum Beispiel auch mal darüber
gesprochen, dass man, dass wir Test driven development machen,
also noch TD arbeiten und man kann jetzt sagen, ja OK, geht ja
nichts mehr schief, machst ja TD ne, aber das ist ja nun leider
Gottes auch nicht hundertprozentig so, also es
schleichen sich immer irgendwie Fehler, es können immer
unerwartete Punkte, oder? Verhalten der Software auftreten
und wichtig an der Stelle ist es halt an dieser Stelle halt ein
gutes Monitoring der Anwendung zu haben und eine gute Feedback
Schleife zu haben, die im Endeffekt relativ schnell, also
egal wie das aussehen mag, ne, aber sagen wir mal.
Ein Fehler wird erkannt und wird innerhalb von kürzester Zeit,
also sagen wir Minuten an das Entwicklerteam oder an das Team
hat wieder. Zurückgeführt?
Ja, da sind wir natürlich wieder beim Stichwort agiles Umfeld,
ne, wir haben ja auch schon mal über agile Arbeitsweisen
gesprochen, ja, und da war ja auch der Punkt, dass man
schnelle Feedback Zyklen haben sollte, um schnell quasi zu
sehen, ob das jetzt alles läuft oder nicht, hat gesagt ne und
das spielt natürlich jetzt auch rein, also finde ich.
Sollten wir auf jeden Fall zweiten Punkt nehmen.
Also das heißt einmal die ganze automatisierungs Geschichte.
Was ist eigentlich CICD? Ja, und danach können wir ja
dann nochmal über Feedback und ja Monitoring reden, das sind
doch 2 ganz coole Punkte um das ganze Thema mal lockeren
Einstieg da drin zu haben, oder? Ja, wollen wir noch vielleicht
noch einen Kurzen, das müssen wir nicht lange beleuchten, aber
vielleicht noch ganz kurz den dritten Punkt, am Ende dann
nochmal mit reinnehmen, weil zum Beispiel wenn du jetzt, wenn wir
also du hattest auch Infrastruktur geredet und
Infrastruktur. Ist an der Stelle interessant
und wichtig zu sagen, dass man das Halt als also IAC
Infrastructure as Code hat. Was genau das ist, können wir
einmal kurz, dann auch nochmal. Besprechen.
Aber das ist halt. Ja, ja, ja.
Klar können wir noch kurz anreißen, glaube ich, dass die
Richtung Skalierbarkeit ja hat vielleicht.
Auch ein bisschen ist ja auch, geht auch irgendwie Hand in Hand
mit Automatisierung, irgendwie, aber wie gesagt.
Können wir nochmal drüber quatschen?
Ja, machen wir mal fahren, dann weiß ich Bescheid, worum es, was
wir jetzt tun. OK, ja gut, dann lass uns doch
einfach mal anfangen mit Automatisierung CICD erklär doch
mal bitte für unsere Zuhörerinnen oder Zuhörer, was
wofür steht denn CICD und was hat das mit Automatisierung zu
tun? Genau, also CICD steht auf jeden
Fall also für Continuous Integration.
Also das CI ne, also. Beziehungsweise wenn es jetzt
auf Deutsch übersetzt, kontinuierliche Integration, das
heißt, es geht darum, dass du sozusagen dein Code, den du
schreibst, kontinuierlich in deine Code Basis integrierst,
also zum Beispiel, es gibt ja Repositories, ne, wenn du zum
Beispiel mit oder SVN verschiedene Arten kannst du
nehmen gibt, ist ja ein sehr weit verbreitetes Repository und
um sozusagen arbeitenden Code machst du sagen Änderung.
Und willst kontinuierlich regelmäßig deinen Code, den du
geschrieben hast, der Neues in die gesamte Code Basis, wo er
verschiedene Entwickler innen arbeiten integrieren?
Ne, ja, das ist jetzt muss ich kurz einhaken.
Was heißt denn für dich kontinuierlich regelmäßig, also
über welche Intervalle reden wir denn dabei?
Das ist ein guter Punkt, also den finde ich richtig geil.
Gerade, dass du ihn ansprichst, weil das ist, glaube ich, auch
ein sehr wichtiger Punkt. Also ich würde bei einer
kontinuierlichen Integration ja eigentlich schon.
Erst an täglich oder mehrmals täglich, die den Code in die
Code Basis und integrieren reden einfach damit man quasi kleine
Steps verändert und sozusagen wenn man dann irgendwann wieder
bei Monitoring ist relativ schnell auch ne sag ich jetzt
mal sieht OK können wir gleich nochmal drüber reden, aber dass
du relativ schnell weißt OK vielleicht geht irgendwas
schief, ne, dass du aber relativ schnell weißt OK um welchen Code
geht's denn hier wenn du ein halbes Jahr lang irgendwas
entwickelst und das dann alles rums Riesending schmeiß rein in
die Code Basis machst dann. Dann weißt du ja vielleicht gar
nicht mehr. Also wenn wir jetzt gerade bei
großen Releases sind, was ja viele auch, was man oft hört.
Dann weiß. Vielleicht gar nicht mehr.
Welcher Part eigentlich deiner Änderung quasi jetzt den Fehler
verursacht, das ist ja auch genauso das Thema.
Wenn du jetzt verschiedene Features implementierst, macht
es natürlich keinen Sinn mehrere Features zu implementieren und
dann zu integrieren, sondern wie du schon meintest täglich, also
in Best Case, sollte so ein Feature was man sich zieht ja
auch nicht. Wochenlang dauern, dass du
implementieren, weil dann ist einfach zu groß und müssen fein
granularer beschrieben werden. Aber sagen wir mal ein 2 Tage,
dann kann man natürlich sagen, OK ich entwickele das Feature
fertig schreiben n Test zum Beispiel dafür, für mich läuft
das Ding jetzt nicht integriert das und guck mal was für ein
Feedback ich dadurch bekomme von der gesamt Software sozusagen ne
also von meinem von meiner Infrastruktur noch besser ist
natürlich das Feature in Teilbereiche unterteilen und die
Einzelnen zu integrieren um zu gucken.
Läuft es denn bis zu dem Punkt, zu dem ich entwickelt habe?
Da bin ich auf jeden Fall ganz bei dir.
Es gibt leider auch viele Entwickler, die das nicht so
sehen, haben wahrscheinlich vielleicht auch Argumente, warum
man das nicht so machen sollte, aber ich versteh s halt einfach
nicht, warum ich wochenlang entwickeln sollte um dann
vielleicht zu erkennen, dass irgendwas falsch läuft.
Genau also das Hauptproblem, wenn man es mal so beleuchtet,
finde ich es ja, dass du dann dich hinstellst und sagst, OK,
es gibt ein riesen Release und man hört ja so davon o nein, es
ist Release und hoffentlich geht alles gut.
Und so. Aber wenn du quasi jeden Tag ne
Art von Release hast, ne, also sozusagen eine Release Probe
jeden Tag, dann ist ein normaler Release so.
Keine Ahnung. War gerade ein Release, ich weiß
es nicht, keine Ahnung Daily Business so ne und da muss
eigentlich sag ich jetzt mal meiner Meinung nach aber deiner
Meinung ja auch hingehen ne aber du hast noch.
Ja genau, weil wenn du einfach mal den worst case anguckst, ne
worst case im Prinzip nach unserer Methode.
Dass ein Tag Arbeit diesen Fehler verursacht hat.
Also es muss innerhalb der letzten Änderung ja drin sein,
weil vorher war ja alles in Ordnung, richtig jetzt 2 Wochen
lang entwickeln, also wirklich 2 Wochen an dem Code arbeite,
woher soll ich jetzt noch so schnell sehen, welcher Teil
meiner Änderungen jetzt den. Fehler verursacht genau also das
ist aber auch n interessanter Punkt, weil jetzt müssen wir
noch ein bisschen trennen, weil und das CI, also die Continuous
Integration zählt ja das integrieren.
Also deines Codes in die Code Basis und zusätzlich soll
natürlich auch der Code nur integriert werden, wenn alle
Tests grün sind. Ne, das heißt du hast auf deiner
CICD Pipeline im CI teil hast du den Bereich, dass quasi alle
Tests laufen und wenn alle Tests grün gelaufen sind sag ich jetzt
mal dann können wir einen Schritt weitergehen, es wird
quasi der Code wird integriert, der Code wird getestet und dann
können wir weiter zum CD Teil gehen, das Ding ist dieser C
teil sozusagen das Fehler wirklich auftreten können weil
ja sozusagen also. Komme gleich auf CD, also
Deployment bedeutet ja sozusagen die Bereitstellung, dass deine
Änderungen halt eben auch wirklich an Mann und Frau
kommen, sozusagen ne also an den Anwender, an den User, weil die
Userin und dann ist es ja so, dass wir gesagt haben, es kann
ja durchaus sein, also sagen wir mal den Test laufen rot, OK,
dann wird es nicht bereitgestellt, dann wird es
nicht deployed, fährt ja gut, also ich war.
Jetzt gedanklich auch nicht beim Deployen.
Aber mal angenommen, ich stelle meine Änderungen halt erst nach
2 Wochen bereit, dann sind das halt extrem viele Änderungen.
Und dann laufen hat verschiedene Tests rot und dann denkst du so
hm. Ja, genau, aber genau.
Und deswegen wollte ich mal diese 2 diese Trennung machen,
wenn deine Tests rot laufen, dann hast du natürlich zumindest
schon mal einen Anhaltspunkt zu sagen, ey OK, der Test und der
und der läuft rot, es kommt nicht mal an den User, was ja
schon mal gut ist, dass fehlerhafter Code nicht an oder
kommt, das heißt du kannst erstmal ganz entspannt deine
Sachen irgendwie regeln dauert natürlich gebe ich dir total
recht, aber du hast natürlich den Punkt, dass du sagst, OK,
ich weiß aber trotzdem schon, ich hab Anhaltspunkt, aber wenn
wir jetzt an den Punkt kommen, dass wir sagen OK.
Alle Tests laufen grün, weil wir am Anfang auch gesagt hatten,
OK, es kann ja durchaus sein, du hast Tests, alles cool, du
arbeitest programming nach TD, warum?
Es kommt trotzdem irgendwie ein Fehler rein ne deine Tests
laufen grün. Irgendwas wurde übersehen, kann
passieren, wird definitiv passieren.
Da brauchen wir gar nicht genau, brauchen wir gar nicht irgendwie
drüber streiten, aber dann wird es deployed und jetzt sind wir
erstmal CD ne, hatten wir schon gesagt so die also das was quasi
dieser dieser Stand der gerade ne gebaut wurde wird sozusagen
dem User zur Verfügung gestellt ne und da ist jetzt ein Fehler
drin so. Und das wurde nicht erkannt.
Das ist ja sozusagen jetzt noch ein ganz anderer Punkt, und da
könnte man jetzt von ausgehen, dass man sagt Okay machen
Release ne riesen Änderungen, läuft alles grün vielleicht mal
werden natürlich noch besser. Was denkbar ist.
Das stimmt so. Und dann sind wir an dem Punkt,
dass wir dann diesen Fehler, der erstmal muss erkannt werden,
weil wir wissen ja nicht, dass er da ist, normalerweise, sonst
würde man ihn nicht raushauen. Das heißt, er muss erstmal
erkannt werden und wenn er dann erkannt wurde, musst du noch
wissen, OK, wo kommt das jetzt her.
Ne hast keine Tests dafür alle Tests laufen grün, hast keinen
Anhaltspunkt und dann hast du ein Problem, ne?
Aber das ist ja auch wieder, das spielt ja in die gleiche
Richtung, ne, also klar, wenn wir jetzt vom Deployment
ausgehen, macht es ja Sinn kleine Änderungen auch
regelmäßig zu deployen um zu sehen ob das im Feld, also im
Feld quasi beim Kunden sag ich mal also ob, ob da jetzt
irgendwelche Bugs reinkommen oder nicht, macht ja auch
kleinere Änderungen schnell zu deployen und dementsprechend
müssen diese kleineren. Änderungen auch schnell
integriert werden, weil wenn ich jetzt keine Ahnung, ich sag OK
es gibt ein neues Release und das ist n Major Release, das
heißt es sind komplette Änderungen drin, das ist nicht
mehr kompatibel, meinetwegen zur alten Version, also was alles
passieren kann ne und du hast du raus und kriegst halt wirst halt
überflutet mit irgendwelchen Fehlermeldungen also berichten
Fehler berichten ja Kunden sagen hier läuft nichts mehr eine
Stern also ein stern Bewertung so weißt du du denkst hä weißt
du wie was ist passiert so ne und das ist halt immer die
Gefahr und deswegen. Macht es Sinn?
Und dafür steht ja auch, dass kontinuierlich in kleinen Zyklen
zu integrieren und auch zu auszuliefern, also Deployment
Delivery, wie man es übersetzen möchte, ne.
Manche nennen das, Glaube ich, sogar Baby Steps.
Klingt immer ein bisschen bescheuert.
Ja, aber das ist also bin ich auch Verfechter davon.
Klar, du musst jetzt nicht, keine Ahnung, du machst jetzt in
der Oberfläche ändern der Farbe von Text oder so, das musst du
jetzt vielleicht nicht sofort raushauen, kannst vielleicht
warten noch andere drin, ist aber an sich, wenn der neue
Funktionalität reinkommt. Ein Haus.
Ja, aber wenn kannst ja mal zusammenfassen.
Punkt Automatisierungs ICD. Also wenn ich jetzt zum Beispiel
als Entwickler ne Fabian möchte, jetzt danach arbeiten, was
passiert dann? Also ich hab jetzt n kleines
Feature fertig, hab meinen Tag beendet was passiert dann kannst
du ja vielleicht zusammenfassen wie das in der also bei uns ist
beziehungsweise wie genau also bei uns ist es ja so aber auch
quasi im Endeffekt so diese Automatisierung CD wie das so
was jetzt genau passiert. Kannst ja mal kurz nochmal
zusammenfassen, damit man das nochmal so als.
Also im Endeffekt läuft es ja so, dass du dir quasi den
aktuellen Stand der Software ziehst, jeden morgen ne weiß
keiner sein, dass Änderungen gekommen sind.
Das heißt du willst ja immer von vom neuesten Stand anfangen zu
entwickeln, sonst kaufst du dir einfach Probleme ein, dass du
halt schon veraltet bist, was unnötig wäre zu dem Zeitpunkt wo
du anfängst zu entwickeln. Möglicherweise wird Konflikte,
warum man. Zum Beispiel kann man ja auch
mal ne andere Folge darauf eingehen.
Auch kann auch sehr problematisch.
Wenn sowas. Genau dann fängst du an,
Features zu implementieren. Und da wir ja davon ausgehen,
alles läuft super, ist der Umfang natürlich an dem Tag
schaffbar. So am Ende hast du deine Tests
geschrieben, das Feature läuft lokal bei dir auf deinem eigenen
PC Check und alles super, alles grün so und dann sagst du OK
jetzt möchte ich meine Änderungen einchecken, das heißt
zur Verfügung stellen für andere Entwickler oder beziehungsweise
in die Software einfließen lassen, dann machst du wir
arbeiten mit Geld dann comites. Dass das heißt, du stellst das
bereit. So, und dann laufen quasi in
unserer sogenannten Pipeline Services los.
Dies quasi erkennen. OK, es gibt eine Änderung an der
Software, das schau ich mir mal an auf gut Deutsch, das heißt es
wird angefangen, diese Software wird gebaut, also ausgecheckt
wird gebaut, die Tests laufen, alles grün OK es ist alles grün
hier super ne ja vielleicht auch noch ein größerer Test Umfang
als die lokalen Tests, das ist dann halt immer n bisschen
Pipeline abhängig ne man lässt. Je nachdem, wie lange es dauert.
Vielleicht nicht alle Tests lokal laufen, sondern lagert das
dann halt auf dem Server aus, sozusagen ne genau genau und
wenn alles grün ist, ist quasi die Integration abgeschlossen.
Genau also CICDCI sorry, CI ist ja quasi dann im Endeffekt
integrieren in ins Repo und die Tests laufen so.
Genau. Also man kann sagen, das war
erfolgreich. Es ist in das Repository
integriert, die Änderung ist jetzt auf dem Server sozusagen
ne, also auf der Code Basis für alle.
Und dann würde ja der CD teil starten.
Das heißt, du möchtest jetzt diese neue Software Version, die
dadurch entstanden ist Fasi ausliefern?
Genau. Dem User zur Verfügung stellen.
Genau das heißt, du baust dann die Software, je nachdem in
welchen Bereich man sich entwickeln B befindet, stellt
Installer bereit, keine Ahnung, automatische Updates You Name
It, wie auch immer. Website wird aktualisiert.
Genau, oder? Die Website wird aktualisiert,
wenn es jetzt wirklich n Frontend ist, also da.
Jetzt 1000 Bereiche jedenfalls. Das Ziel ist, dass am Ende, wenn
der CD teil durchgelaufen ist, diese neue Version der Software
ausgeliefert ist. Das heißt der Kunde.
Geht auf die Website. Sieht die Änderungen.
Der Kunde startet meinetwegen die Software und kriegt eine
Benachrichtigung, dass neue Version da ist.
Ob er updaten möchte, wie es dann halt auch immer aussieht,
aber das ist ja das Ziel schnell danach quasi diese Änderungen
auch ausliefern zu können. Genau also.
Ist es ja bei uns quasi. In unserer Arbeitswelt mit
unserer Software ist es ja so, wenn wir das Ganze quasi
delivered, kriegt der der Anwender eine Benachrichtigung
beim Start der Software oder halt auch zyklisch.
Hey, es gibt gerade eine neue Version reingekommen, möchtest
du updaten? Genau, also im Endeffekt kann
man sich das ja, wenn man das jetzt mal ganz zusammen stampfen
will. Tino schreibt n Feature zum
Beispiel eine neue Page für die Anwendung Page X gibt es schon.
Es gibt jetzt ne Page y und dann nachdem sozusagen CICD alles
fertig ist, kann ich als Anwender beispielsweise mich
hinsetzen und diese Page y aufrufen.
Genau, genau, ja geil das halt relativ zeitnah nach der
Entwicklung dieses dieser Page. Genau, also man sagt ja so ne
CICD Pipeline sollte im schönsten Fall vielleicht sagen
wir mal nicht länger als eine halbe Stunde laufen.
Das heißt, wenn du etwas raus haust in einer halben Stunde hat
der User das und das ist natürlich genau das ist
natürlich geil und jetzt hattest du ja auch schon mal ein
bisschen darüber gesprochen, dass du sagst, ja, OK, Moment,
wäre ja blöd, wenn du jetzt irgendwie Anwendung hast und die
Anwendungen hat dann irgendwie n.
Problem Fehler fliegen. Kriegst einen Stern irgendwo in
der Bewertung und denkst oh scheiße so das wäre natürlich
blöd ne das heißt hier würde ich jetzt sagen können wir ja mal
das Monitoring und Feedback mit Reinschmeißen weil angenommen
wie wir vorhin meinten OK es wurde was übersehen Tests sind
grün es wird deployed obwohl n Fehler da ist, dann ist es
durchaus natürlich sinnvoll zu sagen es kommt vor es kann
vorkommen und es wird vorkommen dass du aber.
Als Entwickler Team super schnell darauf reagieren kannst.
Das heißt zum Beispiel irgend ne Anfrage von deiner App
beispielsweise wird irgendwie bearbeitet und s fehlerhaftes
heißt irgendwie fliegt ein Fehler an deinem Backend
beispielsweise ne, dann wäre es im Optimalfall schön, dass
sozusagen du irgendwie als Entwickler da sitzt, ganz
entspannt arbeitest und auf einmal kriegst du in irgendeinem
Nachrichten Channel, sei mal hingestellt, was für einen
Nachrichten Channel das ist. Kriegst du eine Nachricht?
Besteht Moment, hier ist gerade ein Fehler geflogen in der
Anwendung und dann denkst du dir so OK, das heißt bevor der User
sich noch sagt, was ist denn das für ne Scheiße, wieso geht das
nicht? Ich rufe jetzt mal den Support
an, weißt du als Entwickler Entwicklerin schon bereits ey da
ist ein Problem, daran arbeite ich mal ne also das ist
sozusagen sofort also und hier geht es wirklich darum, dass um
sofort geht es um Minuten ne also im Optimalfall fliegt
irgendwo ein Fehler in der Anwendung und da muss hingehen
ne also nicht dass du sagst ja aber das wäre ja optimal.
Sondern das ist eigentlich die Anforderung, dass du sagst,
irgendwo fliegt ein Fehler in der Anwendung und als obs im
Obst teil kümmerst du dich darum, dass du sagst, OK, meine
Anforderung ist, dass ich Minuten nach diesem Fehler, der
aufgetreten ist, als Entwickler Team weiß, da ist dieser Fehler.
Ne, das ist sozusagen dieses diese Art von Monitoring, die
man im Endeffekt für seine Anwendungen bereitstellen
sollte. Ne, also wenn man sagt ja OK,
vielleicht geht das nicht, bei mir geht das nicht, die Frage
ist eher, wie schafft man es, dass es genau so schnell geht,
weißt du? Ja, da geht es ja natürlich dann
auch um Verfügbarkeit, ne und ich sag mal so, wenn dein
Service ausfällt, den du vielleicht bereitstellt oder wo
Kunden darauf angewiesen sind, ist es natürlich auch ganz
schnell eine Frage von Geld. Ja, also im Sinne von jede
Minute, die du offline bist, kostet dem Unternehmen.
Geld? Na, das ist ja.
Oftmals dann der Fall und deswegen ist dieses Feedback und
das Monitoring so enorm wichtig, weil klar, wir haben die
Pipeline aufgebaut, das heißt, wir könnten schnell den Fehler
finden, richtig, also ihnen fixen es integrieren und
deployen. Genau das heißt, wenn du es
wirklich schnell findest, den Fehler kriegst, vielleicht nicht
unbedingt mit, dann war halt die Software 30 Minuten lang
fehlerhaft und dann ist die neue Version schon draußen.
Ja, oder die Down Time deiner Anwendung ist halt vielleicht ne
Stunde, aber nicht eine Woche lang.
Genau so. Aber das setzt halt genau dieses
Monitoring und Feedback voraus, dass das richtig funktioniert.
Genau, also es ist ja im besten Fall, darf ja gar nicht so weit
kommen, wie du ja schon meintest, dass der Kunde dich
darauf aufmerksam macht, weil dann sagt man ja, so schön ist
das Kind schon im Mund gefallen, weil dann hast du, dann ist der
Bock drin so ne, aber wenn du quasi über deinen eigenen System
quasi schon benachrichtigt wirst, ey.
Keine Ahnung, sowas abgeflogen oder hat n Critical Error
geworfen oder was auch immer. Ne dann ist das halt ja sehr
förderlich, wenn man das schnell.
Mitbekommt. Aber es ist auf jeden Fall eine
schöne Beschreibung, dass du es schneller mitkriegst, dass ein
Fehler in der Anwendung gibt, als der Kunde es kann natürlich
auch sein, dass zum Beispiel der Kunde oder die Kundin, der User,
die Userin, was auch immer beispielsweise irgendwie ne n
Service benutzt und dieser Service hängt von anderen
Services beispielsweise ab. Und jetzt?
Willst du irgendwas machen, zum Beispiel Feature X?
Möchtest du benutzen und es geht nicht und dann könnte man ja zum
Beispiel auch sagen, ne, bevor der Kunde jetzt sagt, Ah
Scheiße, ich muss mich jetzt, ich ruf da jetzt mal beim
Support an und beschwere mich, gibt es auch die Möglichkeit von
sogenannten Status Pages man in seiner Anwendung integrieren
kann. Das macht Github zum Beispiel
super gut, dass Du sagen kannst, OK weiß ich nicht, ich kann
jetzt zum Beispiel keinen repo Auschecken, als Beispiel ne
woran liegt denn das? Und dann kannst du also
irgendwie funktioniert das nicht und dann?
Hast du ja die Möglichkeit, wenn du sagst es gibt eine Status
Patch. Ich guck erstmal auf die Status
Patch und sehe o keine Ahnung. Service XY ist rot, das geht
nicht und der ist dafür zuständig, dass man zum Beispiel
K checken und dann hast du im Normalfall diesen Effekt, dass
der User sich denkt, also totale Transparenz dem User gegenüber
gibt, dass man sich denkt AOK gut, jetzt weiß ich warum das
das wirklich nicht gerade nicht geht, die haben ein Problem, ich
muss mich jetzt bitte ich muss mich jetzt erstmal nicht, ich
muss mich darum kümmern muss niemanden anrufen ich.
Wie du meintest, ich versuchs später genau und das ist zum
Beispiel auch eine Möglichkeit, die natürlich.
Gut ist ja guter Punkt. Um halb magst du ganz kurz
erklären, was github ist. Für Leute die das vielleicht
noch nicht verwendet haben, hier einen Raum geworfen hast.
Ja, also github ist ja im Endeffekt eine Plattform, die
Repositories verwaltet. Ne, also du hast ne Art von
Service, das heißt du kannst einfach sagen, OK, ich möchte
meine Code Basis irgendwo ablegen, Remote und diese Code
Basis ist ein Repository und. Dieses Repository kannst du.
Es geht auch. Kannst du gehostet, kannst du.
Genau, ja, cool. Genau.
Ich glaube, das haben wir jetzt eigentlich ganz cool beleuchtet.
Also mir ist auch selbst nochmal bewusst geworden, wie enorm
wichtig das ganze Thema ist. Und ich finde es auch cool, dass
wir da echt wirklich viel Ambition reinstecken, dass das
alles so läuft bei uns auch. Ja, aber wie?
Aber eine Sache noch ne, warum läuft es so gut?
Es läuft so gut, weil zum Beispiel wir haben eine
Pipeline, also ne unsere Pipeline ist aufgebaut, aber wie
ist denn die Pipeline zum Beispiel aufgebaut, ne?
Also Ah, jetzt wird es auf den Dritten.
Punkt kommen ganz normal kurz, GHG nochmal kurz darauf eingehen
weißt du. Ist richtig.
Aber das ist ja dieser infrastructures Code und man
kann sich ja zum Beispiel hinstellen.
Ich hatte der mal gesagt, dass ich mit ABS ne Menge zu tun
hatte und bei ABS halt unglaublich krass, wie viele
Sachen du du brauchst den Service, du brauchst den
Service, du brauchst XYZ und was auch immer ne.
Und wenn du dich jetzt aber hinstellst und sagst, OK keine
Ahnung, dir fliegt deine Pipeline weg, es kann ja
irgendein Fehler kommen, keine Ahnung.
O zerschießt dir selber deine Pipeline, weil du irgendeinen
Mist konfigurierst, weiß aber nicht mehr was du gemacht hast.
Ja musst du vielleicht die ganze Pipeline wieder aufsetzen, deine
ganze Infrastruktur, keine Ahnung den und den Service wo
dein Backend drauf läuft, was auch immer und damit du das aber
nicht alles manuell machen musst, weil du das vielleicht
vor einem Jahr mal gemacht hast und jetzt überhaupt nicht mehr
weiß wie mach ich denn das weißt du.
Ja, ganz kurz manuell meinst du, dass du ja meistens bei diesen
Services ja auch ne Web Oberfläche, also Frontend hast,
wo du es quasi konfigurieren kannst?
Richtig wie deine Pipeline aussehen soll, richtig und was
du mit s Code meinst ist, dass man diese Konfiguration ja
wirklich programmieren kann. Genau ne Art Gerd, du hast ne ne
Art. Skript nennen wir Skripten.
Ja genau, also zum Beispiel n weitverbreitete Filart.
Für Jamel feiern ne. Ja, zum Beispiel genau, also
halt ne spezielle Syntax und kannst damit quasi dann die
Konfigurations Skripten. Genau.
Also das ist ja zum Beispiel, also machen wir ja auch so ne,
also wir benutzen ja Files für unsere Pipeline und den der
Vorteil, der liegt ja eigentlich auf der Stelle, und zwar wenn
irgendwas kaputt geht oder irgendwas oder du musst
vielleicht deine Pipeline woanders nochmal aufsetzen 1 zu
1, dann nimmst du einfach nur dein Skript oder den Pfeil oder
wie man das nennen mag. Und Jagst, das durch diesen,
durch diesen Service sag ich mal und dann wird alles aufgebaut
für dich, zum Beispiel bei AW. Es war Sommer, ne.
Genau. Also du hast natürlich in einem
also eine wesentlich bessere Skalierbarkeit, also angenommen,
du willst jetzt auf mehreren Services aufsetzen.
Oder halt auf mehreren Servern kannst du halt mit dem Jamel
Film mit einem Skript, das überall sofort konfigurieren.
Bei der anderen Variante musst du manuell überall alles
durchklicken und dann machst du auf jeden Fall Fehler und ein
wichtiger Punkt dabei ist, wenn wir schon bei Repositories sind,
der große Vorteil dabei ist ja die Versionierung, ne, also
jeder einzelne Stand ist Versioniert und
Wiederherstellbar, das heißt angenommen du würdest einen
Fehler in deine Konfiguration einbauen, kannst du einfach
einen vorherigen Stand wiederherstellen der
funktioniert hat. Und dir die Änderung angucken.
Ja, super geiler Punkt auf jeden Fall, weil damit ist es ja auch
dokumentiert, was du gemacht. Genau hast du kannst auf jeden
Fall die Änderungen zurücksetzen und dann die überlegen o warum
funktioniert das nicht? Warum ist meine Pipeline
zerstört? Sozusagen durch diese Änderung,
wenn du manuell rum klickst? Du weißt du noch 10 Minuten
nicht mehr worauf du geklickt hast?
Richtig? Ja ne.
Also das ist auf jeden Fall genau.
Das ist auf jeden Fall wichtig, weil es geht da bei der
natürlich auch zusätzlich um die.
Sag ich mal. Um möglichst eliminieren von
manuellen Schritten ne. Das ist so.
Sag ich mal. Die Faustregel bei Dev Ops, da
kannst du dir so ganz oben auf auf die Fahne schreiben, so nach
dem Motto, also für jeden Zuhörer und Zuhörerinnen macht.
Wichtig. Automatisiert.
Möglichst automatisiert. Ja, genau.
Ja, also ich würde sagen, es gibt auch viel mehr Punkte, die
man da jetzt ansprechen könnte, aber ich denke so die groben und
wichtigsten Punkte haben wir genannt, deswegen würde ich
jetzt die Folge auch beenden. Definitiv aber ist noch mal
dazu, liebe Kolleginnen, liebe Zuhörer, falls du mehr dazu
wissen möchtest, schreib uns gerne auf unseren Plattformen,
melde dich bei uns, wir können auch gerne noch eine weitere
ergänzende Folge dazu aufnehmen im Podcast vor und Nachteile
genau einfach auf weitere Punkte eingehen.
Ansonsten würde ich sagen, abonniert doch gerne den
Podcast, wenn es dir gefallen hat, die Links für unsere
anderen Plattformen findest du Show Notes.
Meld dich auch gerne da und folge uns da.
Ansonsten wünschen wir noch einen schönen Tag und bis zum
nächsten Mal. Eure Coding war das gemeinsam
besser.