Aber nicht, weil ich faul bin. Ich sag's mal provokativ, sondern um quasi meinen Entwicklungsprozess vor mir selbst zu schützen. Coding Buddies, Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen. Halli Hallo und herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast. Ich würde sagen, es ist Zeit für eine neue Folge, und zwar mit mir und mit Tino, den ich hier herzlich begrüßen kann. Tino, Was geht ab, wie geht's dir alles gut bei dir?
Moin Moin Fabi, mir geht's gut, mir geht's sehr gut, was geht ab? Ich finde es eigentlich nicht gut, dass du meine Frage am Anfang klaust, um das Mal kurz vorweg zu nehmen, was geht, das kannst du nicht patentieren, Alter magst du nicht. Also ich finde so unter uns beiden so ein Podcast kann ich das schon.
OK, es ist meine Frage. OK gut, wir machen aus, aber um deine Frage zu beantworten was geht ab eigentlich gar nicht so viel ich find momentan plätschern die Wochen so n bisschen vor sich hin aber nicht im negativen Sinn, sondern es ist immer was los so weißt du am Wochenende ach das ist geplant und dir und so. Aber irgendwie rennt die Zeit
schon wieder dadurch. Das ist so, weißt du, das ist so n typischer Spruch, den wo ich früher immer dachte, Oh, das sagen wir so, die alten Leute, ne ich weiß nicht ob ihr jetzt mittlerweile selbst als alt zählt, aber es ist so dieses Ach das Jahr rennt aber auch schon wieder Fabi, das rennt schon wieder. Solange man nicht sagt, die Jahrzehnte rennen. Ich weiß nicht, wie es dir da so geht, aber ich hab immer das Gefühl so WOW ist schon wieder n
Monat rum. Ja ich weiß aber auch ehrlich gesagt nicht wann das angefangen hat weil es gab ne Zeit da war es für mich so. Boah ey irgendwie geht es gar nicht voran und ich will endlich jetzt zum Beispiel so weißt du so in der Schule so ich will endlich wieder Sommerferien haben oder wenn man noch n bisschen weiter zurückgeht so oh mein Gott, bis mein nächster Geburtstag ist und ich wieder Geschenke kriege, dann dauert das alles so so 1000 Jahre weißt
du so ungefähr. Und das hat man gefühlt jeden zweiten Tag Geburtstag so, ja, das ist schon krass, das ist schon krass, sollten wir vielleicht auch mal eine Folge drüber machen. Ja, nee, aber ich kenne das. Ich kenne das, es geht über ratzfatz, ich meine, das sieht man ja auch an den Podcast folgen, ich meine, wir haben einfach schon, weiß ich nicht, die wir sind schon jenseits der 120 folgen, also das ist schon ein.
Ist schon krass ne und ich habe das Gefühl Tino Wir haben erst gestern mit dem Podcast angefangen oder sagen wir mal zumindest vorvorgestern, das ist schon krass, geht echt. Schnell. Aber ich würd sagen, lass uns mal so n bisschen reinkommen. Wir haben nämlich heute n ganz interessantes Thema mal wieder und bevor wir das Thema jetzt anteasern, wollt ich noch mal ganz kurz anmerken, liebe zuhören liebe Zuhörerinnen, vergiss nicht.
Die Glocke anzumachen und den Podcast abonnieren, weil dann verpasst du keine Folge mehr, weil wir sind ja auch schon wie gesagt schon n bisschen fortgeschritten. Ne, also schon in über 120 in den 100 Zwanzigern. Den 100 Zwanzigern ja genau, ja, wichtiger Punkt. Wir haben ja das Glöckchen erst selbst für uns entdeckt.
Übrigens mach ich das bei Podcast die ich höre auch jetzt sehr gut, also ich mach das auch, ich hab das auch schon vorher gemacht, aber ich hab irgendwie einfach nicht realisiert, dass man das ja auch sagen kann für den eigenen Podcast. Aber ist ja.
Na, bei mir war es wirklich so, dass ich halt immer geguckt hab, oh, gibt es ne neue Folge, gerade wenn welche nicht so regelmäßig, also so so Gescadued hochladen ne so jede wie wir jetzt zum Beispiel jeden Donnerstag 18:00 Uhr, dann musste ich halt immer gucken, Oh gibt es schon was neues und dann denk ich mir so oh mein Gott diese Glocke ist n gamechanger so ne ja krass ach ja das schöne Glöckchen wie gesagt nicht vergessen genau. Aber Tino Pass auf.
Es geht ja heute los, ne und zwar es geht los, große Finale heute und zwar von der Def Ops Reihe. Also ich sag jetzt mal wir werden uns jetzt nicht so weit aus dem Fenster lehnen, dass wir sagen wir machen nie wieder mal n def Ops Thema, aber. Jetzt so ne, dafür leben wir das Thema zu viel. Aber, so die Reihe wollen wir jetzt erstmal abschließen, die wir jetzt so ins Leben gerufen haben. Wir haben ja schon einige Topics behandelt und wir haben eigentlich.
Verschiedene Themen wirklich intensiv behandelt und falls du Liebe zu Liebe zu dir denkst, so ey, Mensch hier, da habe ich jetzt irgendwie Bock, noch mal reinzuhören, was. Da gibt es verschiedene, wusste ich noch gar nicht, hör da auf jeden Fall rein oder wenn dich ein spezifisches Thema interessiert, falls das jetzt die 1.
Folge ist von dieser Reihe die du hörst, dann kannst du auf jeden Fall immer wieder noch mal zurückskippen und noch mal gucken und dir ein einzelnes Thema rauspicken, ne, aber vom Fahrplan her Tino. Was sagst du dazu, wenn wir heute sagen, OK, wir schließen die Reihe mal so ab, dass wir mal die ganze, ich nenne es jetzt mal def Ops Kette durchspielen und sagen, wie kommt beispielsweise der Code eigentlich vom Commit bis zu, ich nenne es mal in die
Produktivumgebung, also ne, dass die live läuft. Zum Kunden sozusagen, ja. Genau, genau, genau. Und warum das eigentlich wichtig ist, dass man diese ganzen Def ops Praktiken eben halt auch im Verbund. Verwendet ne nicht nur einzeln, sondern im Verbund.
Und wir hatten ja zum Beispiel schon über CICD, Staging Monitoring, Observability, Infrastructures Code, Containerization und Occustration gesprochen und jetzt möchte ich dir mal das Gedankenexperiment zuspielen Tino und sagen OK, pass auf, stell dir mal vor, du hast jetzt n neues Feature fertig, ne du hast jetzt programmiert, du hast jetzt n Feature bekommen, hast es programmiert soweit so gut OK geil so. Richtig geiles Feature.
Was anderes kenn ich von dir nicht und jetzt hast du deine Change. Was lachst du danach? Also ich weiß nicht immer wenn ich wenn ich so das hat nichts Böses zu tun, das war. Wirklich nicht böse gemeint. Ich hab mich einfach nur darüber gefreut, dass ich dir ein Kompliment gemacht hab. Schön, danke und jetzt hast du deinen Changes, du checkst die ein ne also beziehungsweise du committest das ganze und pushst es in dein Remo rein. Und jetzt geht es los. Was ist jetzt die Frage, was
passiert jetzt? Wie geht die ganze Nummer los?
Wir, wir sind jetzt in dieser in unserer, Ich nenne sie wie gesagt Def Ops Kette ja und der Push ist gemacht ins Repo, der neue Code ist irgendwie da genau also wir haben ja in unserer Reihe quasi so Grund die Grundlagen besprochen wie eine grundlegende CICD Kette also Pipeline aussieht ja und davon gehen wir jetzt mal wieder aus, also keine kein Schnickschnack ja so die Basics. Und dann geht es halt logischerweise, so haben wir es ja auch in der Reihe gemacht,
als erstes mit der Continuous Integration los, also mit dem CI teil und man muss sagen, ab jetzt, liebe zuhören, liebe Zuhörer, reden wir davon, dass Sachen automatisiert passieren, denn das ist ja der große Benefit. Unserer Pipeline, die uns sehr, sehr, sehr viel Arbeit der sonst manuell echt nervig wäre, abnimmt. Ja und dadurch ja auch ne gewisse Qualität gewährleistet wird, weil es automatisiert ist das noch mal als kleiner
Reminder ab jetzt. Kleiner Einwurf, weil wenn man sich das mal vorstellt, bevor man CICD Pipelines alles den ganzen Kram. Ich sag mal erfunden hat ne hat man das eigentlich wirklich manuell gemacht? Ne so ja wahrscheinlich in einer geringeren Frequenz Frequenz aber es ne. Genau also wie du ja schon gesagt hast. Ich hab jetzt n Feature entwickelt. Ich hab das committed und gepusht so in unserer agilen Welt, wie wir sie leben.
Also wir jetzt wir beide vor allem ja sind ja so ne Features, nicht sehr groß sondern kleingeschnitten, das heißt diese Frequenz die du gerade angesprochen hast ist ja erhöht. Ja. Ja, und nicht wir machen einmal im Jahr nen Update, weil es halt so aufwendig ist ein Update an den Kunden auszuspielen. Das ist ja schon der erste wichtige Punkt, warum diese Automatisierung so so unglaublich effizienzsteigernd auch ist.
Am Ende ja und genau und deswegen ich hab das jetzt committed gepusht und ich möchte, dass der Kunde das jetzt erfahren kann. Ne, das ist n geiles Feature wie du meintest und das soll jetzt ausgerollt werden. Und damit geht es dann halt wie gesagt mit dem CI teil los. Das heißt unsere Pipeline kommt jetzt so richtig ins Rollen, dafür muss sie aber natürlich erstmal erkennen, dass es eine Änderung gibt auf dem Branch zum Beispiel, auf dem ich das
gepusht hab. Ja, also das ist ja jetzt die Grundvoraussetzung, dass die Pipeline das auch erkennen kann. Oh, es gibt n neuen Commit der gepusht wurde, es gibt sozusagen Changes und das überprüf ich jetzt mal, bevor das hier richtig integriert wird oder als integriert gilt in unserer Codebasis. Müssen jetzt erstmal Checks laufen und Tests, damit man sagen kann, es ist erfolgreich integriert und das ist ja im Prinzip die Kernaufgabe des CI.
Teils genau das heißt, man lässt die Tests laufen, die ja hoffentlich da sein sollten, Leute die müssen da sein, die sind da erstmal so, Tests müssen da sein, das heißt die Tests laufen. Man kann auch ne statische Codeanalyse laufen lassen. Also da sind jetzt sag ich mal, da gibt es keine Grenzen was man testen möchte, ne je mehr desto besser mal so als kleiner Grundsatz solange es einen Sinn
dahinter gibt. Ja, also sinnlose Tests bringen natürlich nichts und man kann natürlich auch sagen, oder das ist wichtig dabei zu achten, es gibt 2. Wie soll ich sagen, Prämissen oder Eigenschaften, die dieser CI teilhaben sollte? Noch mal so als Reminder und Zusammenfassung erstens bei all den Tests, die ich laufen lasse, ist es wichtig, dass die Pipeline in diesem CI teil schnell abbricht und Meldung macht, was schief gelaufen ist.
Es bringt mir nichts, ich habe jetzt tausende Tests und der 10. Failed. Da muss ich die anderen nicht laufen lassen, weil dann ist ja dann stimmt schon irgendwas nicht, weil wir gehen ja davon aus, dass der Test seine Daseinsberechtigung hat und selbst wenn er es nicht hat oder es sogar richtig ist, dass der falsch ist, weil der das Feature sich geändert hat, ne, dass da Sachen überprüft werden, die gar
nicht mehr drin sind. Es ist ja trotzdem wichtig die Meldung zu bekommen und zu sehen, dass da was nicht stimmt und den Hinweis zu bekommen, weil dann heißt es ich hab irgendwas übersehen oder nicht angepasst. Das heißt ich will ja schnell drauf reagieren können, wieder als Entwickler. Und mit schnell, das ist der zweite Punkt, der wichtig ist. Es darf halt auch insgesamt nicht lange dauern, weil auch ein positives Feedback möchte
ich schnell haben. Ja, also nicht nur, ach, es läuft nichts schief, na dann mach dein Ding CI teil, wir sehen uns morgen. Das ist natürlich auch nicht der Sinn, sondern so mal als Richtwert 10 bis 30 Minuten. Das ist so für ne Pipeline schon wünschenswert, ne. Also dass ich sage OK ich hau jetzt mein Feature rein in die codebasis und ich möchte ja auch schnell sehen, war das
erfolgreich. Ja, also wir haben ja, wir sind ja jetzt an dem, also man muss auch dazu sagen, wenn man jetzt so für sich selber ne Pipeline entwickelt, ist sie wahrscheinlich eh. Also du hast so ne kleine Anwendung, willst hier die Ployn, da ist sie wahrscheinlich eh relativ schnell, weil du gar nicht so viel hast, ne?
Aber selbst wenn sie ein bisschen länger wäre, würde es dich alleine wahrscheinlich gar nicht stören und deswegen würde man sich wahrscheinlich denken, ja gut, passt schon, wenn die jetzt mal eine Stunde läuft, ist mir egal wann.
Wann ändere ich mal was. Angenommen, du hast jetzt vielleicht du arbeitest alleine, hast so privat, hast jetzt vielleicht jeden Tag mal einen Push aufs Repo, weißt du wenn du jetzt aber davon ausgehst und wenn wir das jetzt mal gedanklich ein bisschen durchspielen, sagst du hast ein Team von 6 Leuten, die regelmäßig codeänderungen pushen. Und jedes Mal läuft die Pipeline
los. Dann hast du eventuell das Problem, dass die sich irgendwann richtig cune, bis das irgendwann durchläuft und dann hast du vielleicht so 6 commits sag ich jetzt mal oder 6 ne neue Änderung auf deinem Repo und der Erste läuft durch, der zweite läuft durch, der Dritte läuft durch und dann der Vierte den du eigentlich haben willst, der
failed so aber bis. Dass du das gemerkt hast, brauchst du ja im Worst case vielleicht einige Pipeline Durchgänge und wenn du dann aber eine Pipeline hast, die 2 Stunden läuft, ich übertreibe jetzt ne, aber es gibt es
wirklich. Also ich habe auch schon mal ein Projekt gearbeitet, wo eine Pipeline, ich würde sagen eineinhalb Stunden gedauert hat und das ist ein Killer wirklich, das ist ein Killer das das funktioniert dann irgendwann nicht mehr, gerade wenn du häufig committest, was an sich eigentlich eine ganz gute Practice ist. So ne ja, aber du hast natürlich im Kopf, das dauert echt lange, vielleicht mache ich das und das vorher noch.
Also das macht natürlich was mit dem Mindset des Entwicklers oder der Entwicklerin. Wenn du weißt, das dauert lange oder du blockst lange, dann die Pipeline. Ja, deswegen ist so n so n Richtwert schon gut. Klar kann man ihn nicht halten, je nachdem wie das Projekt skaliert wie du gerade meintest, aber so n Richtwert ist immer gut zu sagen Ah lass mal schon gucken, dass wir da drin bleiben so ne. Ja, genau, ja.
Und abschließend kann man dazu sagen, das ist im Prinzip der CI, teil ist so der erste sogenannte Gatekeeper, ne der Halt wirklich sagt Pass mal auf ja du codeänderung ja OK du kannst rein, du bist sauber, du nee, das muss noch mal geprüft werden ne also du hast halt da schon so deine erste, deine erste Überwachung sozusagen, dass alles in Ordnung ist. Ja, richtig, genau. Und ansonsten wird es halt geblockt und wenn dann halt alles wirklich grün ist.
Ne Test Checks und so weiter dann gilt ja der Code als
integriert. Offiziell ne was ich noch ganz interessant fand, weil du vorhin meintest es muss auch einen Sinn ergeben bei diesen Checks, weil wir jetzt, weil ich gerade noch mal Checks gesagt habe, ich hatte auch zum Beispiel schon mal gesehen, dass irgendwo ein Test drin war, es hieß OK, es sollte irgendwie, es sollten Tests für Files da sein und dann gab es tatsächlich ein Test. Zu einem Pfeil wo drin stand accept true to be trucy, so als Beispiel ne und das ist halt
also das war halt schon wirklich sehr dreist so nach dem Motto Wir haben Tests, es laufen Tests aber die Tests waren halt sowas von unaussagekräftig weil sie halt einfach gar nichts getestet haben und das war schon n bisschen bisschen heftig so viel zum Thema, wenn es denn auch sinnvoll ist. Ne genau. Aber Tino, wenn wir, ich möchte mal ganz kurz ne Sache spoilern, ne und zwar. Wir OK. Wollen ja gerne das, was wir
jetzt hier besprechen. Diese ganze def Ops Kette ne wollen wir auch gerne mal vom From scratch selber machen ne also wirklich mal aufbauen und das so als ich sag mal Videoreihe ne dass man wirklich sagt OK wir machen so ne Art ja. Ich will es jetzt nicht wirklich Tutorial nennen, aber so n so ne Art OK, wir machen ne Videoreihe und man kann sich das halt angucken um halt was draus zu lernen und dann vielleicht. Praktisch zu sehen. Mal genau.
Genau, genau. Und das sind ja auch einige Sachen, die da mit Reinspielen und dafür würde ich gerne dir mal ganz kurz ne kleine Werbung machen.
Weil wir wollen dafür ja einen v Server von Strato nehmen und da gibt es ja auch immer mal wieder günstige Angebote, ne und wir wollen ja zum Beispiel den VC 624 nehmen, das heißt der hat 6 Kurs 360 Gigabyte Speicher, 24 Gigabyte RAM und das halt eben für einen Euro pro Monat ne. Der ist ein Nobranner, ne, also 3 Monate lang kann man das testen, das ist natürlich mega
genial. Der hat halt auch schon ordentlich Leistung, ne, also da ist halt dann auch einiges möglich mit ich bin richtig gespannt, ich freue mich drauf auf. Auf die Videoreihe und ich find es halt auch mega cool, dass wir das auf diesem V Server machen
können. Ja, auf jeden Fall. Aber wenn man jetzt zum Beispiel sagt, Ey, ich find jetzt zum Beispiel den entsprechenden V Server, der ist mir eigentlich schon zu viel oder zu wenig, also es gibt auch noch viele andere und die Angebote ändern sich auch, also das ist auf jeden Fall alles möglich, wenn du, liebe zürer lieber Zürer sagst, ey, das ist cool, ich brauch auch gerade so NV Server oder also nicht ich brauch irgendwie n Server worauf ich
irgendwas laufen lassen kann. Dann guck auf jeden Fall mal in die Shownotes, weil da haben wir n Link, das ist n Link wo du uns auch zusätzlich noch unterstützen kannst und guck da auf jeden Fall mal rein, check das aus und wenn du sagst ich brauch so n Ding, dann let s go. Ja, genau. Werbung, Werbung Ende, wie man es so schön sagt, dann lass uns
mal über den CD teil reden. Du meintest ja gerade so, wir haben Gatekeeper, ne unsere Tests Checks sind alle durchgelaufen, jetzt ist es grün, wie geht es weiter? Weil prinzipiell ist der Code ja noch nicht deployed, wir können das ja noch nicht verwenden. Dein neues geiles Feature was du entwickelt hast. Kino das heißt?
Wir müssen ja jetzt noch gucken, dass wir das Ganze, dass das Ganze weitergeht, und zwar, dass man halt auch wirklich die Änderung, die man jetzt gemacht hat, dass man die auch wirklich live schaltet, und da hatten wir ja auch schon mal so ein bisschen einen Unterschied gehabt zwischen Deployment und Delivery, das hatten wir schon mal ein bisschen besprochen, möchte das noch mal ganz kurz vielleicht zusammenfassen, was das ist, damit man das noch mal auf einen Blick zusammen hat.
Und. Ja, also unter CD verstänken sich halt genau diese beiden Begriffe, oder man kann halt so beide damit verwenden sag ich mal ne, aber so ganz grob die Unterscheidung delivery ist halt, dass man sagt, OK, ich bereite alles soweit vor, dass es an zum Beispiel dieses neue Feature, was wir jetzt committed haben an den Kunden ausgerollt werden kann, aber ist am Ende immer noch eine.
Sag ich mal. Manuelle Freigabe benötigt ja, also man kann sich das wirklich so vorstellen, alles ist Grün, das Ding ist bereit integriert zu werden, also beziehungsweise nicht integriert, sondern dem Kunden zur Verfügung gestellt zu werden und ich drück jetzt nur noch n Knopf und sag so Leute ihr könnt es verwenden, jetzt ist es für euch da. Update so nach dem Motto Ja. Und Deployment ist dann eigentlich so vom Grundprinzip her, dass es komplett
automatisiert ist. Ja, also in dem Moment, wo ich mich als Entwickler entschieden habe zu sagen. Ich Committee mein neues Feature, Das ist fertig. Von meiner Seite aus. Ich übergebe es quasi meiner Pipeline, alles läuft durch, wir hatten ja gerade den CI TEIL CI sagt ja alles super und der CD teil sagt alles super OK dann werde ich jetzt nen nen Deployment eine Auslieferung vorbereiten und Vollautomatisiert an den Kunden gehen. Genau das heißt.
Das heißt, mit meinem Commit mit dem Push nach einer gewissen Zeit hat der Kunde es dann auch im Prinzip zur Verfügung. Genau, und das ist das Ziel. Ja, im Endeffekt baut man, so sag ich jetzt mal im CD Teil, baut man die Software, hat ja irgendwie n Artefakt ne also ich sag mal was man sich gut vorstellen kann so also das ist es jetzt nicht mal, also n Artefakt ist ja zum Beispiel auch sowas wie ne exe ne, also irgendwas was man laufen lassen kann, so nach dem Motto ne.
So n Ergebnis dann halt. Und das wird dann halt irgendwo halt eben auch laufen gelassen. So ne in einer bestimmten Umgebung und. Delivery zum Beispiel finde ich, wenn man das noch mal sagt, so oder noch mal aufgreift, finde ich ganz gut, wenn man sagt, OK, man hat es vielleicht so n feature Set wo man sagt OK ich möchte nur einen Deployment machen, wenn das gesamte Feature Set was gerade entwickelt wird
auch fertig ist. Ne weil das kannst du jetzt ohne weiteres ne und ich sag extra ohne weiteres bei Deployment halt nicht unbedingt gewährleisten weil da wird ja erstmal stand jetzt so wie wir es gerade besprochen haben immer gesagt OK. Neue Änderungen du wirst die ploy, du wirst die ploy, du wirst die Ployd also angenommen.
CI ist Grün, der Code wurde integriert, dann wird es auch Deployd das heißt wenn du 3 Teil Features sozusagen oder ne was vielleicht zu einem Featureset zusammengehört wird es halt einfach deployd und dann ist halt n Teil davon da und Teil nicht ne da kann man natürlich auch sich wieder hinstellen und sagen ja gut OK dann mach halt zum Beispiel so sogenannte Feature flags. Und setzt die erst auf.
Dieses Feature ist da, wenn das gesamte Set, zum Beispiel das ist eine Möglichkeit, auch das so zu machen, weil wie gesagt, Def OPS ist ja auch, man versucht ja möglichst viel zu automatisieren und demzufolge ist auch, sagen wir mal Strebsam im Def Ops Bereich zu sagen, Wir wollen Deployment und nicht nur ein Delivery, aber es ist bringt natürlich auch noch ein bisschen mehr mit sich, also gerade bei Deployment. Ja, also. Im Prinzip alles, was sich mit
Deployment beschäftigt. Da kommt man schnell an den Punkt, dass man sagt, OK, wir brauchen ja auch eine gewisse Strategie, um zu Deployen in einer ganz einfachen Pipeline, wie wir es jetzt bis jetzt stand jetzt haben, ist es halt im Prinzip direkt deployed, wie du auch meintest, so ne, dann ist es halt schwierig ganze Features Sets mit einmal auszuliefern oder quasi noch sozusagen zurückzuhalten. Aber du hast natürlich auch das Thema, wie kommt das überhaupt
an das Feature? Ne, also du hast jetzt zum Beispiel gesagt Mensch Tino Klasse feature was du gemacht hast, aber vielleicht sieht der Kunde das nicht so oder nur n Teil der Kunden finden das gut und da haben sich halt so verschiedene Deployment Strategien herauskristallisiert, Liebe, zuhören, Liebe zuhören falls sich das Thema genau interessiert, hör gern noch mal in die spezielle Folge der Reihe rein. Ich werd es jetzt nur noch mal
nennen. Wir haben ja so über Blue Green Deployment gesprochen, Canary Deployment und das sind im Prinzip Strategien um nicht zu 100% an alle direkt auszurollen das neue Feature, sondern das sind Strategien um. Sag ich mal noch mal zu testen, wie es denn ankommt, ob es wirklich fehlerfrei läuft. Ja, also Blue Green ist halt, dass ich im Prinzip wirklich sage, ich schalte um, kann aber
auch wieder zurückschalten. Ja, also ich habe jetzt wirklich so ne Art Spiegelung mit dem neuen Feature und ja so n toggle wirklich und man sagt Ah nee warte mal, warte mal da da ist stimmt irgendwas nicht zack zurück ja. Und Canary, um das noch mal kurz zusammenzufassen, ist ja im Prinzip, dass ich prozentual ausrolle.
Das ist auch ne echt coole Strategie zu sagen, ich geb es erstmal nur n gewissen Anteil meiner Kunden, es kann auch zufällig sein und wenn da keine Rückmeldung kommen, dann kriegen es halt noch mehr so und dann oh jetzt kommen die positiven Feedbacks rein und mehr mehr mehr bis ich es irgendwann zu 100% verbreitet hab und das sind halt Strategien die man da im Hinterkopf haben sollte und die halt auch wirklich absolut Sinn machen, ja. Ja, richtig, und das ist halt
auch wieder ein Ding. Also dass gerade weil du ja sagst, so okay, wenn was schief läuft, wenn das vielleicht beim Kunden nicht so gut ankommt, ist natürlich die Frage okay aber. Wie? Woher weißt du das? Das, das kann man ja nicht jetzt ohne weiteres einfach so wissen, sondern und da ist natürlich wieder ein Punkt, den besprechen wir auch noch bisschen später im Monitoring, weil Monitoring ist unglaublich wichtig, um halt eben auch zu.
Sozusagen die geeignete Automatisierung dann zu finden, zu sagen, OK, ist das jetzt n einmaliger Fehler ist das jetzt n Fehler der vom letzten Deployment kam und so weiter und sofort, aber das ist essentiell dafür um überhaupt sowas machen zu können. Ne was bedeutet aber auch gleichzeitig, dass Continuous Deployment ja auch wirklich, also wirklich NN höheren Aufwand einfach mit sich bringt am Ende.
Einen initialen Aufwand, wo man dann noch immer gucken muss okay lohnt sich das fürs Projekt oder nicht? Es ist natürlich immer sehr spezifisch, aber das muss man halt einfach dann selbst abwägen.
Prinzipiell ist es natürlich eine gute Practice, das so dann zu machen, genau und gerade auch weil du oder weil wir jetzt davon geredet haben, ja, wenn sich ein Fehler einschleicht, da kann man sich jetzt auch denken, ja, ci, wir haben noch gesagt, alle Tests sind grün, Checks sind grün, es muss doch alles passen, ja, das ist natürlich die.
Absicherung auf dem im ersten Level du kannst aber nie hundertprozentig sicher sein, dass vielleicht doch irgendwas schief läuft, was du eigentlich sogar nicht haben wolltest. Also man ist dem halt irgendwie nie gewahrt. Also ein Fehler kann trotzdem irgendwie mal, sagen wir mal auftreten, irgendwas kann vielleicht nicht schmecken, dem User beispielsweise oder es treten irgendwelche Side Effects auf mit dem man halt wirklich nicht gerechnet hat, kann halt
einfach passieren. Es kann natürlich auch genauso sein, wenn ich jetzt quasi die Artefakte baue, ne, also meine Auslieferung zusammenbaue kann natürlich auch was schiefgehen.
Ja, also gerade wenn ich zum Beispiel externe Abhängigkeiten hab, irgendwas hat sich geändert in meiner Software, dann ist vielleicht meine Software an sich grün im CI teil aber im CD teil lässt sich halt die Auslieferung nicht mehr zusammenbauen, das kann auch sein, also hier gilt natürlich auch wieder dieses schnelle Feedback am Ende ja definitiv. Genau. Aber ein Punkt, der sehr wichtig
ist. Und das ist auch ne coole Überleitung, weil du meintest, so was ist Delivery Deployment der Unterschied und wenn ich featuresets in im gesamten Ausrollen möchte, ne, deswegen haben wir ja auch in unserem Grundlagen in unserer Grundlagenreihe das Staging besprochen, weil es halt auch n enorm wichtiger Punkt ist. Und genau damit kann ich ja jetzt sowas dann ermöglichen, weil in unserer einfachen Kette, wie wir sie jetzt haben von meinem Commit, den ich vorhin gemacht hab bis jetzt.
Ist alles sehr geradlinig. Ja, also so ne Einbahnstraße sag ich mal. Klar, ich krieg mein Feedback, aber es gibt nur eine Richtung und Staging ist ja jetzt genau das, dass ich sagen kann, ich kann mehrere, wir hatten ja damals in der Folge so diese Analogie von Spielen früher genommen, ne, dass ich so verschiedene Stages hab wie ich immer weiter komme sozusagen und ich find das ist halt auch sinnbildlich sehr sehr treffend. Ich kann jetzt mehrere Etappen
sozusagen einbauen und. Wie weit möchte ich jetzt etwas deployen? Zum Beispiel Wohin? Auf welche Stage soll das landen? Und da gibt es halt so am Ende immer diese sogenannte Prot Stage, also die wirklich produktiv ist. Da wo quasi sag ich mal der Kunde drauf sitzt was er verwendet, am Ende zum Beispiel die Website, die wirklich live ist. Ne die du dann über deine Domain aufrufen kannst. Genau, aber jetzt kann ich ja. Variabel davor mehrere Stages einbauen.
Ich kann zum Beispiel sagen, es gibt ne Develop stage, ja da sammel ich jetzt meine Features, die Entwickler können drauf zugreifen, alle kriegen quasi diesen Stand. Wenn ich jetzt mein Feature entwickelt hab kann ich sagen ey ich hab es deployed auf unsere. Develop Stage beispielsweise und die anderen Entwickler können das Ausprobieren.
Also die können dann einfach darauf arbeiten, sie entwickeln ja auch mit dem Stand weiter und wir sammeln so unsere Features da, bis wir irgendwann sagen, so, dieser Stand geht jetzt auf unsere produktiv Stage und jetzt viel Spaßkunde das wird richtig geil, was wir gebaut haben, so ne genau eine Möglichkeit, was siehst du denn noch so für Stages um das noch mal kurz zusammenzufassen ja es gibt zum Beispiel, also was halt beliebt ist ist auch sowas wie ne QR Stage also so.
Ich nenne es mal auf Deutsch Qualitätsmanagement Stage. Also es gibt ja auch Anwendungen, wo es auch externe Tester gibt, die dann noch mal wo die Software noch mal extra von externen Testern getestet wird oder getestet werden muss,
auch manchmal. Das heißt, es gibt dann zum Beispiel eine Stage, wo sich dann die Leute zum Beispiel austoben können und halt eben nicht in der Produktivumgebung testen sollen, weil du willst ja vielleicht zum Beispiel nicht bei Instagram oder so 1000 user QR 123, User QR 555 oder weil. Weißt du sowas, wenn du dir so denkst, was ist das hier alles gerade nur mal so als Beispiel? Also du haust ja auch Daten in die Datenbank rein, die du aber am Ende in der Produktivumgebung
nicht haben möchtest. Demzufolge kannst du halt den QA also oder den Tester ne, die kannst du halt dann expliziten Zugang zu einer Stage geben, die aber genauso funktioniert wie Pod oder oder sehr sehr ähnlich ist.
Sag ich jetzt mal. Und da kannst du aber auch andere Sachen testen, wie zum Beispiel, ob deine Datenbankmigration funktioniert, weil es gibt, ich sag jetzt mal n bisschen salopp gesagt, nichts schlimmeres, als wenn du ne Datenbank migrierst und es failed und am Ende hast du riesen Datensalat in deiner Datenbank.
Das ist halt nicht so geil und man kann sich das halt ungefähr so vorstellen, dass ne, wenn du jetzt zum Beispiel sagst, meine Website de beispielsweise ne, weil du Website gesagt hast.
Gibt es, kannst ja auch auf Apps, Münzen oder so, aber du hast am Ende ne eigene Domain, ne, das ist dann zum Beispiel sowas wie dev Punkt, meine website de oder QR Punkt, meine website de und vielleicht hast du andere login Mechanismen, dass du halt eben nicht in der Lage bist als produktiv User die QR Stage zu verwenden und so weiter dass es halt gekapselt ist. Ne, dass du vielleicht ein bisschen, deswegen meine ich auch nicht ganz hundertprozentig
gleich. Dass du vielleicht noch eine andere Anmeldemöglichkeit hast oder so, dass du eventuell sagst, OK, wir schließen aber auch wirklich aktiv bestimmte Usergruppen aus, ne, damit es halt eben wirklich isoliert ist. Irgendwo ne für den entsprechenden Zweck, das ist halt wichtig, ja, aber ich würde tatsächlich so weit gehen, dass
ich sagen würde, wenn wir etwas. Von der ganzen Sache, die wir besprechen, so noch annähernd als optional hinstellen können, dann ist es das Staging im Sinne von ne Protz Stage gibt es immer, die ist auf jeden Fall wichtig, wenn du alles. Richtig muss es hingehen. Aber wenn du alles richtig machst, ist das irgendwie in Ordnung. Weißt du, dann passt das so, aber deswegen, du kannst ja zum Beispiel sagen, OK, ich bau noch ne Test stage ein, du musst aber
keine QR Stage haben, du kannst. Du hast Stage einbauen, musst aber kein Test Stage haben. Du kannst aber auch 5 Stages vor Port noch machen, deswegen das meine ich so ein bisschen mit in Anführungsstrichen optional ne. Genau.
Also das ist ein sehr wichtiger Punkt, der halt relevant wird, wenn es um skalieren geht, ne und wenn du mehrere Entwickler rein kriegst, wenn es halt ein Riesenprojekt wird, dann wird Staging irgendwann nicht mehr vermeidbar sein und dann ist es auch richtig, es nicht mehr zu vermeiden. Aber ich sag mal, du hattest ja auch gesagt, wenn man jetzt so ein kleines Einzelprojekt hat, dann ist es vielleicht noch nicht notwendig, wie du gerade meintest.
Also so in so einer ganz Lean Basic Pipeline muss es dann nicht Teil davon sein, dann brauchst du zum Beispiel keine Test Stage oder auch keine, weil ich meinte Death Stage wo Halt so Features gesammelt werden, die aber auch sauber ist. Also noch mal kurz zur Differenzierung, eine Test Stage ist für mich halt etwas, da kann ich machen was ich will ja also da. Länger yolo mäßig.
Ich kann da alles löschen. Ich kann Edge Cases ausprobieren, ich kann richtig wilde Sau spielen da ja und ne Death Stage ist für mich, aber wenn ich jetzt ganz viele Entwickler hab ne dass die da alle auch ne ne saubere Grundlage haben wo denn die Features wirklich integriert sind. Und als korrekt geltend sozusagen. Und das brauche ich nicht, wenn ich alleine bin, wozu soll ich das machen, hast du natürlich
absolut. Recht, du meintest ja vorhin auch schon bei den Checks, was man wirklich braucht und genau hier gilt eben auch was, also bauen eine Stage auf für das was du halt auch wirklich brauchst. Und weil ich ja auch meinte Okay eine Stage muss vielleicht leicht anders konfiguriert sein, also sie sollte sich gleich verhalten, kann aber anders konfiguriert sein im Endeffekt und.
Und da ist eigentlich n ganz interessanter Punkt, weil wie kann man zum Beispiel das ganze gut konfigurieren und damit du halt zum Beispiel sagst, OK, du hast vielleicht ne Umgebung, die immer gleich ist, ne auf der einen Seite, aber du.
Du hast auf der anderen Seite zum Beispiel kannst du diese Umgebung halt eben auch irgendwie von außen noch konfigurieren, ne, was ja schon mal dazu führt, dass du jetzt sagst, OK, ich hab zwar meine Stages, die ich irgendwie aufbaue, wo ich irgendwie meine entsprechende Anwendung in der entsprechenden Stage hin deploye ne, aber du willst es ja nicht plain einfach auf den Server ballern und sagen, OK, du hast jetzt vielleicht hier Abhängigkeiten, also installiere
ich die alle auf dem Server und Let's go. Ne, sondern da machen wir auch eine bestimmte Practice sozusagen, die ich am Anfang angesprochen hab. Ja, also man merkt schon, wenn es mehrere Stages gibt und das ganze skalieren soll, dann kommt halt ein Punkt ins Spiel, der unfassbar wichtig ist. Und ich finde es ist Best Practice ihn von Anfang an einzusetzen. Ja, und zwar reden wir jetzt von Infrastructure is Code und es
geht halt im Prinzip darum. Seine Konfiguration codiert abzubilden, ja, also ich habe keine manuellen Schritte zu sagen, ja, ich mache das hier, was welche Stage, ja du willst eine Test Stage ja warte, da muss ich das so und so Umkonfigurieren, sondern ich habe es in Code gegossen. Ja es ist auch Versioniert zum Beispiel wichtiger Punkt ja also ich habe Stände von meiner Konfiguration die ich auch wiederherstellen kann und im Prinzip habe ich dann
unterschiedliche. Konfiguration um diese einzelnen Stages dementsprechend aufzubauen und ich kann sie immer wieder so aufbauen und dadurch nehme ich quasi die Komplexität und den Zeitaufwand raus, den eine manuelle Abarbeitung einfach hätte. Das heißt nicht, dass es nicht komplex ist, diese diese das zu coden ja auf keinen Fall, das kann auch sehr komplex und und nervenraubend werden, ja da will ich, das will ich nicht schönreden.
Aber Fakt ist, wenn es läuft und nachweislich läuft, ja, also man kann sowas natürlich auch überprüfen und testen, dann hab ich das, dann hab ich diesen Stand und der wird funktionieren und der wird immer gleich funktionieren am Ende und das ist es ja worum es geht am Ende. Ja, also du hast ja gerade jetzt so bei den ganzen Anwendungen, die man eben hat.
Du hast ja nicht nur ein Frontend und ein Backend, also nicht nur irgendwie, sagen wir mal, ein Artefakt von deinem Frontend Code und ein Artefakt von deinem Backend Code, sondern du hast ja dazu noch irgendwie du brauchst ein Server wo das drauf läuft, du brauchst eine Datenbank, du brauchst vielleicht noch ein Load Balancer, weil deine Anwendung so groß ist, dass irgendwie der die ganze Last ne von den ganzen Usern die kommt irgendwie aufgeteilt wird auf.
Zum Beispiel mehrere Instanzen deiner deiner Anwendung, beispielsweise ne. Du hast vielleicht irgendwie noch ein Storage, weil du irgendwie Bilder und Videos irgendwie anzapfen willst. Du brauchst einen credentials Manager, weil irgendwie die Datenbank verschlüsselt ist und so weiter und sofort und um das alles aufzubauen, ne, es ist halt anstrengend so ne und das kannst du manuell machen, das kannst du manuell machen und dann hast du es einmal gemacht,
dann hast du weil. Wenn ich jetzt aus eigener Erfahrung spreche, so wenn du so infrastructures Code baust, das ist immer so OK. Ich mach erstmal ich mach erstmal das ich leg erstmal das an und jetzt sozusagen versuch ich die Infrastruktur hochzufahren ah OK gibt n Fehler warte mal da fehlt Parameter ah der ist required OK da muss ich noch mal gucken in die Doku alles klar ach ja genau die Datenbank muss verschlüsselt sein so als Beispiel ne so ne
und dann. Du hast richtig viele, also meiner Erfahrung nach einige Iterationen um halt eben deine Infrastruktur auch wirklich so aufzubauen. Über infrastructures Code wie du es haben möchtest. Das heißt es wie du meintest, es dauert. Es dauert natürlich aber und das ist das Schöne, wenn du es einmal hast ne dann funktioniert es halt und dann funktioniert es deterministisch, das ist halt das schöne und nicht irgendwie.
Klar, wenn du noch mal n bisschen was ändern willst, dann du änderst Kleinigkeiten auch alles in Ordnung, ne, wenn vielleicht noch was schief geht und du sagst oh Gott ich hab jetzt mich komplett in der Einbahnstraße manövriert ne bei dieser infrastructures Code. Und du sagst, ey ich, ich krieg meine Umgebung, die die ist kaputt irgendwie.
Ich hab richtig Mist gebaut OK nimm wie du meintest, du kannst gucken in deiner Versionierung, das war der letzte Change, der hat alles kaputt gemacht, das heißt ich geh von meinem, von meinem, von meiner Git Versionierung beispielsweise einen Schritt zurück, lösche meine komplette Umgebung, phasi komplett wieder hoch und ich hab wieder n stand der wieder läuft mach das mal manuell, das ist halt.
Ne krass. Gerade wenn du noch mehrere Stages aufbaust und sagst, OK ich bau jetzt die def Stage auf, ich bau jetzt zum Beispiel meine QR Stage auf, ich baue meine Prod Stage auf, du musst das dreimal machen so und dann denkst du dir vielleicht so ja OK, ich hab jetzt zum Beispiel meine prod Stage und meine def Stage, aber ich brauch jetzt noch ne QR Stage und dann warte mal was hab ich jetzt noch mal?
Was brauch ich jetzt wie hab in welcher Reihenfolge hab ich das gemacht ich weiß es gar nicht mehr so hab ich jetzt zum Beispiel das so konfiguriert oder so ich guck noch mal nach und das ist funktioniert nicht, skaliert nicht und das ist halt das wichtige um halt eben Infrastruktur infrastructures Code zu haben, das heißt du hast würde ich jetzt einmal kurz durchspielen Commit cicd und deine Stages, aber das Ganze das kannst du. Du kannst es alles manuell
irgendwie aufbauen, aber infrastructures Code wir sind hier wieder bei Automatisierung wird ja groß geschrieben bei def Ops die braucht man um das gesamte zugrunde liegende System auf also auf der die Pipeline läuft halt eben einfach. Ich sag mal modern aufzubauen, Wartbar und Automatisierbar zu machen. Ne, also auch das aufbauen der Struktur selber sozusagen ne und auch einfach nachweisbar.
Ne, du kannst ja denn genau sehen, wie sieht meine CI aus, wie sieht meine CD aus, welche Stages hab ich, das ist ja nachlesbar so wenn das jemand manuell gemacht hast, dann musst du die denjenigen Fragen sagen, was passiert da eigentlich, ja ist ja ganz einfach hier, ich hab es vergessen. Und so hast du es natürlich nachweislich in einer Version da und kannst es quasi nachlesen, wenn du ja den Code verstehst.
Dahinter ne, ja richtig, und das ist einfach der Riesenvorteil und was du meinst die Versionierung. Ich kann Stände wiederherstellen, ne und auch hier muss natürlich der Fokus sein, es schnell zu erkennen falls was schief läuft um schnell reagieren zu können.
Ne also wie bei allen. Bestandteilen gilt das natürlich hier auch genau, aber und damit man das auch machen kann, wie ich meinte, irgendwas ist vielleicht kaputt an der Umgebung, dafür brauchst du halt infrastructures Code ne oder halb wen mit der Versionierung und und und.
Wichtig ist noch kleine Anmerkung, Es ist natürlich und das muss man wissen, einfach von vom Feelinger, von der Anwendung es es muss natürlich lesbar sein für die Umgebung, für die Cloud, in der man das Halt zum Beispiel eben eben macht, ne, also beispielsweise Azure ist nicht gleich ABS ne und die Reden auch anders. Das ist wie ne Programmiersprache. Du hast halt einfach unterschiedliche Parameter, die du irgendwo einsetzen musst.
Die Sachen heißen anders und so weiter ne, aber ich denke das. Ist klar. Also da muss man sich dann halt in das Scripting quasi so n bisschen reindenken und Reinlesen. Aber ich sag mal Konzepte sind oft ähnlich, das hilft dann dabei ne und man sammelt so seine Erfahrungen damit. Lass uns mal zu dem nächsten Punkt kommen, der jetzt quasi entscheidend ist wenn wir sagen. Wir sind jetzt, wir haben unsere Pipeline mit Infrastructure Code
aufgebaut. CI läuft durch, die Stages laufen durch und wir entscheiden uns jetzt zu deployen, beispielsweise ne, dann haben wir ja über einen Punkt gesprochen, der auch super essentiell ist und zwar containerisierung. Ja also wir haben über Container und Orchestration gesprochen. Denn die Frage ist jetzt, wie liefer ich denn das Ganze aus, was liefer ich aus?
Du hast ja jetzt beispielhaft gesagt, er stell dir einfach ne exe vor oder so in modernen Lösungen, dabei sieht das ja ganze n bisschen anders aus, ne, dann redet man ja oft von Container, Docker fällt sofort als Wort, da haben wir auch ne Folge drüber gemacht, die ich persönlich auch sehr sehr geil fand, weil es einfach so ein cooles Thema ist. Aber das würde ich gern mit dir auch noch mal so n bisschen
zusammenfassen. Ja. Stellen wir uns vor, es reden sehr viel, immer von Microservices. Ne, du hast halt ja kybernetes Feld dann ne und das ganz ganz viele Container die da laufen in deiner Umgebung und jeder hat so seine Aufgabe und jetzt stellt man sich natürlich die Frage, gerade vielleicht als Einsteigerin oder Einsteiger, warte mal was Microservices, Hunderte Container, was geht da ab, ich hab eine Software so weißt du. Und genau darum geht es ja im
Prinzip, dass man seine Anwendung zum Beispiel in Microservices aufteilt. Ne, dass du gewisse Teile, Aspekte, Aufgaben, auslagerst oder als eigenen Service betrachtest und dann im Endeffekt eine Servicelandschaft hast, die deine gesamte Funktionalität abbildet und das läuft alles so in einzelnen Bestandteilen und da haben wir über Container gesprochen. Und Container haben ja im Prinzip die Aufgabe, ein Problem zu lösen, und zwar das IT Works
of my Machine Problem sozusagen. Nur weil du sagst, ich hab bei mir auf meinem PC alles eingerichtet und wenn ich jetzt meine Software laufen lasse, dann läuft das ja, das heißt ja aber nicht in der Integration, wenn ich jetzt davon ausgehe, ich habe ganz viele Bestandteile und ich lass das jetzt auf irgendeinem Server laufen. Dass das da auch läuft, dann,
das ist ja nicht gewährleistet. Dann fehlt halt ein Package oder n Klassiker ist es ne falsche Node JS version da installiert und der Support ist nicht mehr gegeben und du kriegst auf einmal da n Fehler hier keine Ahnung was du hier vorhast, das läuft so nicht ne so geht. Und das sind, das sind halt Klassiker, und die werden auf dich zukommen, wenn du dich
darum nicht kümmerst. Und dafür gibt es halt im Prinzip auch Container, die denn dafür sorgen, dass du halt diese Abhängigkeiten darin bündelst und sagst, OK, dieser Container mit dieser Software, die ich deployen möchte mit diesem Stand, bringt alles mit, um laufen zu können. Ja, um das noch mal kurz zusammenzufassen, und das ist halt n sehr essentieller Punkt und vor allem wichtig für deine Pipeline um sauber deployen zu können und vor allem mit dem Ziel, dass es am Ende auch läuft.
Ja, selbst wenn du auch nicht sagst, OK, ich mach alles in Microservices, aber weil ich ja vorhin meinte, du brauchst vielleicht n Load Balancer, weil du die Last verteilen willst, weil zum Beispiel eine Anwendung, also eine Instanz der Anwendung, nicht mehr ausreicht, dann brauchst du halt noch mal genau die gleiche Anwendung woanders.
Und da kannst du einfach sagen, OK, ich fahr noch n neuen Container hoch, der aber im gleichen in der sozusagen, der aber auch mitorchestriert wird, beispielsweise ne, damit du halt ja auch eben sagen kannst, OK, wo leite ich das denn hin, die müssen ja auch irgendwie die gleiche Datenbasis auf die gleiche Datenbasis zugreifen, damit es irgendwie funktioniert und so weiter ne und weil ich zum Beispiel vorhin auch meinte, angenommen du hast ne QR Stage und ne protzstage und.
Irgendwelche Tester wollen zum Beispiel auf die QR Stage gehen, aber prod. User sollen da zum Beispiel
nicht drauf gehen. Könntest du beispielsweise den wenn du jetzt einen Microservice hast und Authentication Service könntest du zum Beispiel einfach die URL der URL eine andere geben als zum Beispiel, also dem der Container, also sozusagen der Container. Frisierten Anwendung ne andere URL von außen reingeben wo du sagst, OK das ist Deine QA Anmeldung und das ist deine prot Anmeldung ne, also dass du einfach die URL änderst beispielsweise die du von außen
reingeben kannst, weil das ist zum Beispiel auch sehr wichtig und ne Best practice, dass eine Umgebung selber nie weiß, dass sie zum Beispiel def ist oder prot ist. Das heißt im Code gegossen. Ne, du kannst halt sagen, OK, du bist jetzt def von außen oder du bist prot.
Du kannst es dem von außen mitgeben, aber von innen würdest du niemals sagen, OK ich bin jetzt def beispielsweise oder ich bin prott genau ne ja. Das und das ist halt n wichtiger Punkt um das Staging dann vernünftig auch umsetzen zu
können. Ne, dass du halt zum Beispiel deinen Container hast für Test. Du gehst halt auf deine Testdatenbank und den Prot gehst du auf deine echte Datenbank beispielsweise und das wird halt in den Container mit Reingegeben und wie du meintest, er weiß es nicht, es ist für ihn einfach die Anwendung die läuft und das ist ja auch gut so. Ja hast du ja gerade erklärt, aber das sind das greift, da sieht man mal wieder, dass so ne Pipeline, dass all diese Aspekte
halt ineinander greifen. Und sich gegenseitig unterstützen. Sagen wir mal, wenn du davon was weglässt, fällt es dir halt schwer, es denn im gesamten auch
so umsetzen zu können. Genau, aber pass auf die nur das Wichtigste ist finde ich und das ist auch wirklich ein sehr sehr essentieller Punkt, noch mal ganz am Ende, weil es kann ja überall irgendwo was auftreten, also in allen Sachen, wo wir gerade irgendwas beschrieben haben, kann ja irgendwas auftreten, wir haben ja auch zum Beispiel gesagt, Ey, wenn die Tests failen, du musst ja irgendwie darüber benachrichtigt werden, ne, also du kannst ja nicht sagen, ey, weiß ich nicht.
Meine Pipeline läuft normalerweise 20 Minuten. Ich guck mal nach 5 Minuten schon mal prophylaktisch rein, um einfach mal zu gucken okay ist es denn gefällt oder nicht, das heißt du willst informiert werden darüber ob irgendwie die CI gefällt ist, ob irgendwie das Deployment nicht funktioniert, ob deine Infrastruktur irgendwie nicht richtig hochfahren kann oder da vielleicht ein Problem ist, ob vielleicht irgendein Problem innerhalb deines Containers oder deiner
Containerumgebung auftritt. Du willst quasi darüber benachrichtigt werden, ob vielleicht irgendwelche Probleme in deiner Anwendung fliegen, damit du irgendwie wieder deine Deployment Strategie. Hier anwenden kannst zu sagen, ich Rolle es wieder zurück und so weiter und sofort und gerade im Zuge des neuen Features. Ja, was wir jetzt gerade versuchen zu integrieren und zu deployen.
Genau. Und wenn du darüber nicht Bescheid weißt, dann hast du eigentlich schon wieder n großes Problem. Das heißt n sehr sehr wirklich essentieller Punkt. Meiner Meinung nach ist halt eben Monitoring und Observability ne, also was jetzt beides genau ist. Wie gesagt haben wir ne Folge drüber gemacht. Aber es ist definitiv wichtig, um da um einfach irgendwie zu erkennen.
Okay, du hast Anomalien irgendwo in deiner Umgebung, irgendwo, egal wo in in dem Ganzen, was wir gerade besprochen haben. Und wichtig ist halt zu sagen okay, du hast eine Anomalie, du kannst sie sehr schnell irgendwie erkennen und sagen okay Pass auf, hier ist eine Anomalie und dann musst du auch noch schnell dazu in der Lage sein zu sagen okay weiß ich nicht, diese Anomalie ist ein Bug und der ist da, der Ursprung ist darunter, das ist halt wichtig, dass man das schnell
machen kann und das. Dafür ist es halt einfach notwendig, auch schnell benachrichtigt zu werden. Also du kannst halt jetzt irgendein Tool nehmen und sagen, ey hier ne, also du du sagst es fliegt zum Beispiel super oft ein Fehler in deiner Anwendung, also kriegst du eine Benachrichtigung auf irgendein Messenger beispielsweise der dir sofort sagt EY Hallo hier Fehler.
Ne, und dann gehst du rein, guckst OK, da hab ich n Fehler warum ah OK Zeile so und so in meinem Code oder hast du nicht gesehen ne aber das ist halt unglaublich wichtig, genauso wie wenn deine CICD Pipeline failed, dass du dann sofort ne Mitteilung bekommst die dir sagt Ey das hat nicht funktioniert, damit du sofort wieder reagieren kannst, ne. Genau. Und ja, also im Prinzip haben wir jetzt mit all diesen Punkten ja auch wirklich ne vollwertige
Pipeline geschaffen. Ja, also auch gerade mit dem Monitoring, was du jetzt am Ende noch erwähnt hast, was im Prinzip flächendeckend ist, das kann man sich wirklich so vorstellen. Das sitzt über jede, über jeden einzelnen Bestandteil, weil wir haben ja jedes Mal gesagt, ich möchte schnell wissen, dass etwas nicht klappt, ich möchte schnell wissen, ob es also auch geklappt hat. Ja, also beide Fälle und deswegen ist das halt n unfassbar essentieller Punkt, den du gerade angesprochen hast,
aber nicht aber und. Ich möchte noch zuletzt auf einen weiteren Punkt eingehen, denn das ganze def Ops. Ja, wir haben jetzt wirklich alles, gerade in den einzelnen Folgen detailliert besprochen, um wirklich die Grundlagen abzubilden. Aber wir haben ja ganz am Anfang dieser Reihe um ein Thema, auch sag ich mal, uns Zeit genommen für ein Thema, und zwar für das Mindset dahinter. Denn so oft, wie wir jetzt gerade schon gesagt haben, ich möchte Feedback. Ich möchte wissen, ob es
geklappt hat. Ich möchte vor allem schnell wissen, wenn es nicht klappt, ja, also ich will einfach Qualität gewährleisten, ich möchte sehen, dass etwas funktioniert am Ende und wenn es nicht funktioniert, bitte sag es mir so schnell wie möglich, damit ich es fixen kann. Ja, das zeigt ja, dass man ein gewisses Mindset braucht und das finde ich ist unfassbar essentiell, wenn es um das Thema Dev ops geht und vor allem wenn man in dem Bereich.
Tätig sein möchte oder halt auch mal so eine Pipeline umsetzt, dass man dieses Mindset mitbringt, weil man verwendet viele Tools. Ja, es gibt unfassbar viele Tools im Def Ops Bereich, allein um eine richtig coole cicd Pipeline aufzusetzen, so in dem Basic in der Basic Form wie wir sie jetzt besprochen haben, wirst du ja schon viele Tools einsetzen, keine Frage. Also das Tooling ist gigantisch, aber am Ende ist es unfassbar wichtig halt ein.
Ein richtiges Mindset in sich selbst zu verankern, ja, also nicht so. Ja OK, ich nehme jetzt das Tool da da, das haben die jetzt gesagt das das muss ich nehmen, was war es ja hier Docker jut Docker hier komm wie funktioniert das jut alles klar ja hier Tutorial AB fertig funktioniert und das mach ich jetzt bei allem und dann hab ich jetzt irgendwie so ne Pipeline die läuft irgendwie und fertig also man muss halt auch n gewisses Mindset da einfach.
Mitbringen, weil, so wird es am Ende nicht laufen, ja, sondern man muss sich fragen, wie kann ich etwas automatisieren und warum automatisiere ich das vor allem auch ne das Ziel muss sein mir so viel manuelle Schritte wie möglich abzunehmen, aber nicht weil ich faul bin, ich sag es mal provokativ. Sondern um quasi meinen Entwicklungsprozess vor mir
selbst zu schützen. Ich finde, das kann man eigentlich so sagen, weil manuelle Schritte bedeutet fehleranfällig und deswegen das Mindset zu haben, kann man da was automatisieren, kann ich gewährleisten, dass es immer gleich abläuft, das ist halt wichtig, ne und dann dieses erkenne ich schnell, dass etwas schiefläuft, ich möchte bitte sofort wissen, wenn etwas nicht läuft. Ja. Na, ich finde es halt.
Ich habe halt oft gehört, so was wie es geht nicht, aber die Frage ist halt finde ich eher so okay wie geht es, wie kann ich das ermöglichen und das ist halt ein essentieller Teil und am Ende geht es ja auch darum, dass man bei Def Ops eben nicht einfach nur sagt okay ich muss jetzt hier irgendwie ne wie du schon meintest, so eine Toolpalette anwenden, sondern es geht darum Silos aufzubrechen, also gerade wissens Silos die du irgendwo verankert hast, vielleicht unter Umständen oder
vielleicht verankern würdest in deinem Team und. Und halt eben auch zu sagen, ich teile die Verantwortung über die entsprechende, über den gesamten, über die gesamte Anwendung sag ich jetzt mal. Und alles, was damit zu tun hat durch halt eben Automatisierung und ja, es geht halt auch irgendwo darum, Transparenz zu schaffen, ne, also dass du sagst, OK ich hab ne Transparenz, Transparenz schafft Vertrauen und. Und das ist halt am Ende das Wichtigste. Das muss im Kopf sein.
Ansonsten funktioniert es auch nicht so richtig, Depp Ops anwenden zu wollen, weil man es muss, sondern man möchte, man muss es wollen, sozusagen nicht, weil man es muss, man muss es wollen. Und deswegen auch noch mal abschließend noch mal gesagt, Wir haben es schon oft gesagt, diese Feedback und Fehlerkultur ist halt das Maß aller Dinge und das muss gelebt werden. Ja, man muss zu Fehlern auch
stehen. Das Ziel ist, wie können wir sie nächstes Mal vermeiden, was können wir jetzt verbessern, damit diese Fehler nicht mehr auftreten. Und das sind halt essentielle Fragen, die du dann stellen musst. Am Ende ne nicht so wer war es, ich war es nicht hier RR da drüben, da stehst du aber 5 hinten rechts in der Ecke was genau unser klassischer Business Server nein es geht darum OK sprichwörtlich, das Kind ist im Brunnen gefallen, es ist passiert.
Wie machen wir es besser nächstes Mal und ich finde diese Fehlerkultur ist halt auch sehr essentiell im Def Ops teil. Auch hier noch mal die Anmerkung, Wir hatten es damals schon gesagt, dass Def Ops Handbook fantastisches Buch, wo auch alle Punkte, gerade das Mindset finde ich sehr sehr gut enthalten ist. Was sind es für Schritte, was muss in meinem Kopf passieren, wie muss ich an so ne Sache
rangehen? Da auch noch mal die Empfehlung, wir können auch gerne den Link noch mal in die Shownotes packen, ist n wirklich sehr gutes Buch, richtig? Ganz kurz bevor wir jetzt vielleicht die Folge abschließen, will ich noch mal ganz kurz n kleinen Ausblick geben und zwar es gibt ja def Ops, vielleicht hat der ein oder
andere. Auch schon mal sowas wie def sec ob es gehört ne. Im Endeffekt ist das so ich vielleicht so die logische Erweiterung, dass man halt sagt, OK nicht es ist nicht nur Development and Operations sondern Security kommt mit rein, weil oftmals ist es so, dass in Anwendung Security irgendwie nachgelagert wird, so nach dem Motto Wir bauen erstmal die Anwendung und dann gucken wir mal. Was kann man denn Security technisch noch vielleicht verbessern?
Hier ist es so, dass Security da nicht nachgelagert wird, sondern eher so bei Design mit in den Entwicklungsprozess von Anfang an integriert wird. Ne und dann wird halt eben aus Def Ops def sec ops. Ja also ich sag mal so es ist auf jeden Fall im groben soll es halt die Haltung da also.
Mitgeben dass Security ist eine Verantwortung von jedem für jeden, der Halt Software entwickelt oder Infrastruktur aufsetzt oder was auch immer, ist ein essenzieller Teil und wenn es irgendwie mal ein Interesse gibt zu sagen, okay können wir vielleicht defs Hack Ops noch mal ein bisschen vertiefen. Im Podcast können wir gerne auch noch mal machen, noch mal eine Folge drüber machen, also Liebe zuhören, lieber Zurer sagt auf jeden Fall Bescheid.
Ja, und warum das so extrem wichtig ist, haben wir in der. Einer der letzten Big Fails folgen gezeigt der solarwinds Fall war ein perfektes Beispiel, warum auch dieses Bestreben oder das Denken Richtung Defsac Ops gegangen ist. Ja, weil das war halt ein Riesending mit extrem hohen Schäden. Und deswegen hatte man dann auch gesagt, so vielleicht sollte man im deffops Bereich auch so ein
Security by Design betreiben. Also gute Anmerkungen und Liebe zuhören, Liebe zuhören, falls du da Bock drauf hast, schreib uns, wir können uns gerne mit dem Thema auseinandersetzen, ist auch wirklich ein sehr coole, sehr cooler Punkt ansonsten fabi es ist leider soweit, ich muss es jetzt leider sagen, damit haben wir unsere geliebte Deffops Reihe erstmal als Grundlagenreihe abgeschlossen. Es war mega cool. Vielen Dank noch mal an dich dafür.
Ich liebe es über dev Ops mit dir zu sprechen, liebe Zuhörer, liebe Zuhörerin, ich hoffe, dir hat die Reihe auch gefallen, falls es vielleicht die 1. Folge war und du jetzt sozusagen dieses Chi Chi bekommen hast. Ne mit diesem gesamten Überblick, hör auch gerne noch mal in die anderen Folgen rein, da haben wir alles detaillierter besprochen. Wenn du dir jede Folge angehört hast, schwören wir dir, dann hast du das Def Ops wissen in den Grundlagen, dann weißt du
wie es läuft. Kannst du mitreden, du bist def Ops dann und ansonsten würde ich sagen Liebe zu Liebe zu und falls dir der Podcast grundlegend gefällt oder halt auch speziell diese Folge empfiehlt ihn gerne weiter, lass ne Bewertung da, das würde uns mega freuen, dass du unterstützt uns ungemein. Das Glöckchen was Fabi schon erwähnt hat, wichtig, wichtig, ich wusste es nicht.
Ich hoffe du weißt es jetzt und hast drauf geklickt falls du Fragen hast zu def aufschreibt uns die Podcast Mail wie immer in den Show Notes Anmerkungen immer gerne her damit. Ja wir tauschen uns super super gerne damit aus auch auf dem Discord, schau gerne vorbei, da gibt es jeden Tag Diskussion zu Themen ist richtig cool wir lieben unsere Truppe, da ist es einfach mega cool mit den Leuten und und ansonsten würde ich sagen, hören wir uns alle beim nächsten Mal wieder.
Bis dahin ne gute Zeit euch allen ciao ciao deine Codening Bodys gemeinsam besser.