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.