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.