Secrets Not Included: Automatisierte Deployments sind kein Luxus mehr

Willkommen zu einer weiteren wunderbaren Folge Secrets Not Included, nachdem ich letztes Mal Daniel abrupt in seinen Diplomates unterbrochen habe. Wieder zurück mit Daniel und Ole und ich glaube, wir steigen einfach nahtlos ein in das Ende der letzten Woche.

Ja, wir lösen endlich den Cliffhanger auf. So, nach der letzten Folge geht es jetzt nicht weiter, mitten im Plot.

und reden einfach mal so ein bisschen über Deployment und Standardisierung, auch was Entwicklungsumgebung angeht. Sehr gut. Ich glaube, wir waren dabei stehen geblieben, dass wir gesagt haben, automatisierte Deployments sind heute das Bare Minimum und kein Princess Treatment mehr. nicht nur für Entwickler, sondern für die gesamte Company. Und Und ja, aber was müssen wir denn eigentlich machen, außer diese Pipelines und dass das alles mal so fluffig daherkommt und tatsächlich funktioniert?

Ja, also wir reden ja immer viel von Secrets und wie Sachen zu funktionieren haben. Und es fängt, also Pipeline, das war das Fazit vom letzten Mal ja so ein bisschen, je schneller wir deployen können, umso schneller können wir auf Änderungen, Patches, Inzidenz und sowas reagieren. Aber... Das fängt ja nicht nur beim Deployment an, sondern eigentlich viel früher. Und zwar ist es, es fängt mit der Entwicklerumgebung an. Also wie ich auf dem lokalen Rechner entwickle, Habe ich die gleichen Abhängigkeiten installiert? Gibt es Testdaten? Wie sind Sachen aufgebaut? Und wie komme ich theoretisch von? Oder ich sage mal, theoretisches Beispiel ist, Chef ruft an, oh mein Gott, im Shop ist irgendwas kaputt.

Mhm.

Ein Icon, ein Bild ist verrutscht, ein Button ist rot und nicht grün. Irgendwie solche Sachen gibt es ja immer so. Man ist gerade schön in seinem Thema und dann wird man so komplett rausgerissen. Erste Frage ist, okay, auf welchem Stand ist denn das Produktivsystem gerade? Weil ich bin ja gerade aktiv am Entwickeln, ein anderer Kollege ist was am Machen. Es gibt schon zwei Features, die sind fertig, die sollen ausgerollt werden, die habe ich auch mitgetestet. Und schon hast du so erstmal, was ist gerade die Produktivversion? Vielleicht hast du auch irgendeinen komischen Fall, den du lokal hast, das Feature gebaut. So ein üblicher Fall mit Works on my Machine.

Mhm.

Das ist bis auf Produktiv gekommen und da knallt das. wo du sagst, komisch, es hat doch mit meinen Testdaten funktioniert, wie kriege ich jetzt eine Umgebung hergestellt, die exakt wie Prod ist, mit Testdaten, wo ich sagen kann, vielleicht gibt es da irgendein Produkt, was ich, oder irgendeine Kombination an Flags, die ein Produkt haben kann, zum Beispiel im Online-Shop, die dann mir einfach durchgegangen sind und dann ein Problem verursachen oder sowas, ne.

Ach Daniel, du machst das alles viel zu kompliziert, weißt du, ne? Wir haben früher direkt auf dem Produktivsystem noch mit FTP deployed, warum sollten wir nicht einfach drauf gehen? Aufs Produktivsystem, dann entwickeln wir kurz da mit Cloud Code oder Open Code oder whatever welcher KI und das löst doch alle Probleme.

Ja, war das... Ich darf jetzt öffentlich keine Gewalt androhen.

Ich weiß gar nicht, was du da jetzt... Gut, dass uns ein paar Kilometer trennen.

Nein, also jeder hat das schon mal gemacht, ich natürlich auch. Es führt einfach dazu, wenn ich alleine als Entwickler arbeite, dann kann sowas fast noch funktionieren. Also ich bin zu schlampig dafür, ich schaffe das selbst alleine nicht, aber es gibt ordentliche Leute, die schaffen das. spätestens ab zwei oder drei Entwicklern ist das so, irgendjemand macht was, lädt was hoch, vergisst die Datei. Und schon hast du auf jedem Rechner, also jeder Entwickler hat eine andere Version. Der eine hat seine Version hochgeladen, Entwickler B lädt seine, also eine Version von einer anderen Datei hochgeladen.

Nein, nein. Also ich sage nicht, wir gehen zurück zu FTP-Uploads, sondern ich sage, lass uns doch die Cloud-Session von einer KI einfach auf dem Produktivsystem laufen und die KI da arbeiten.

Du möchtest dich bald trennen sehen.

Also ich kenne jemand, der tut das.

Ja, ich versuche gerade,

Also es bin nicht mal ich selber. Bevor mir das jemand unterstellt, die Person schreibt das auch gerne selber öffentlich im Internet, dass sie es genauso macht und das komplette Produkt eine große Index-PHP-Datei ist. Jetzt habe ich dich kurz geschockt. Ich trinke kurz einen Tee zwischendrin. Ohne Rum.

Ich versuche gerade den nächsten Shitstorm zu vermeiden, indem ich mich zu sehr dazu äußere und... Wie kann ich denn da... Hm.

Nein, aber wir sind uns ja einig, wenn man, also zugegebenerweise ist es ein einzelner Entwickler. Ich finde das ein crazy Ansatz. Mir ist der zu verrückt. Ähm. Da gibt es auch keine Pipelines, ne?

Nee. Ja, hm.

Übrigens fällt mir dabei so auf. Brauchst du ja nicht, wenn du auf dem Produktivsystem arbeitest. Aber jeder hat ja halt ein Testsystem, ne? Um mal den Bogen zu bekommen. Wenn das Produktivsystem natürlich nicht das Testsystem ist, gewinnt man schon viel.

Ja, ja.

Und, ähm, hey, ja, natürlich entwickelt man auch mit KI gar nichts dagegen, aber vielleicht auch nicht auf dem Produktivsystem. Wir haben mal festgestellt, ähm, die KI-produktive Infrastruktur managen zu lassen, selbstständig ohne Review ist auch keine gute Idee. Aber erst. Also, nicht, dass mir das nicht letztens selber passiert ist.

Ihr räumt gerne auf, so Produktivdatenbanken habe ich gehört. Hat mir ein Freund erzählt.

Es war aber nur das Testsystem, also nicht so schlimm.

Ja. Genau.

Auf dem Produktivsystem der KI Zugriff geben, dafür bin ich nicht mutig genug. Aber auf dem Testsystem hat sich tatsächlich einfach mal die Datenbank weggeschmissen. Sehr gut. Aber heißt ja, das, was, glaube ich, wir beide bevorzugen, sind starke Entwicklungsumgebungen, die im Prinzip das Produktivsystem vollständig nachbilden. oder zumindest in dem Teil vollständig nachbilden, in dem wir arbeiten. Also es gibt ja sehr große Systeme, wo CMS, Shop und diverse andere Services rumfliegen, in einem Kubernetes-Cluster oder in mehreren Clustern, in mehreren Namespaces und so weiter und so fort, geografisch natürlich hervorragend verteilt, damit es auch spannender wird. Ähm... Und dann müssen wir ja darüber nachdenken, was machen wir denn damit, die Entwickler auch irgendwie parat kommen. Miteinander, aber auch mit der Umgebung an sich. Das heißt, wir brauchen ja auch eine Standardisierung dieser Entwicklungsumgebung. Das war ja die Richtung, in die du gerade gehen wolltest, bevor ich gesagt habe, hey, ein Index-PAP-File auf dem Produktivsystem mit der KI.

Da werde ich heute Nacht von träumen, danke.

Bitte, den Psychiater musst du aber bitte selber bezahlen.

Ja, ja, mache ich. Ja, also die Entwicklungsumgebung ist einfach so, ich möchte ja erst mal etwas ausprobieren können. Also wenn ich ein Feature baue oder ein Bug fixe, ich möchte etwas ausprobieren können.

Ja, also nur wenn du in Deutschland Zug fährst.

Wie weit kann ich das denn lokal? Und dann ist zum Beispiel die Frage, gerade wenn man remote arbeitet, nicht immer ist eine gute Internetverbindung da. Also es könnte Leute geben, die arbeiten aus dem Zug. Zum Beispiel, da kannst du gar nicht per SSH irgendwie auf den Server und da andauernd tun und machen. Ja, das ist jetzt meine Annahme. In anderen Ländern vielleicht nicht, aber

Also ich kann dir sagen, sobald der Eurostar über die Gänze ist, funktioniert Internet tadellos im Zug. Selbst unterm Ärmelkanal, alles kein Thema.

Schalten wir es dann an? Ja, also...

Da kannst du auch deinen Videolivestream machen, das ist kein Thema. Also nehmen wir an, du bist irgendwo in Deutschland unterwegs und hast eine schlechte Internetverbindung, was ja ein realistisches Szenario ist, da wird jeder, der hier unterwegs ist, zustimmen. Oder halt nicht so viel Datenvolumen, um mal eben mal wieder Container-Dependencies oder sonst irgendwas runterzuladen.

Andersrum ist es ja auch so, externe Dienste sind auch nicht zuverlässig. Also es kann ja immer wieder mal sein, also nicht nur das Internet weg ist, sondern es gibt genug Gründe, dass irgendwelche Verbindungen mal nicht da sind, dass es entweder keine Testumgebungen gibt, da kannst du dann auch schlecht irgendwie Produkte testen, wenn es nur das Produktivsystem gibt. Also erstmal die Abhängigkeiten nach außen hin möchte man natürlich nicht haben.

Mhm.

Man möchte aber auch möglichst nah, also ich sage möglichst nah, 100%ig geht eigentlich selten, aber möglichst nah am Produktivsystem sein. Ich möchte zum Beispiel sagen können, was passiert, wenn die Datenbank nicht da ist? Wie verhält sich meine Applikation? Das kann ich zum Beispiel, wenn ich lokal alles nachgebaut habe, einfach mal die Datenbank abschießen und die Seite aufrufen und gucken, was passiert. Im Produktivsystem testen wäre jetzt nicht so cool und in anderen Setups ist das auch schwer dann zu testen zum Beispiel. Oder wie ich vorhin gesagt habe, Fixture-Daten finde ich zum Beispiel für mich super hilfreich, weil ich einfach immer wieder mich durch Sachen durchklicken muss.

Ja.

Und wenn es darum geht, irgendwas zu löschen in der Datenbank und ich baue gerade das Feature, was zum Löschen da ist. wenn ich da tausendmal klicken muss und das wieder von Hand anlegen muss, da werde ich verrückt dabei. Und so ist es so, wenn du Fixstandaten zum Beispiel hast und kannst sagen, das Schönste, was dir als Entwickler passieren kann, ist, du gehst morgens hin und sagst, start, web-server startet, eine Datenbank startet, vielleicht hast du ein Redis mit im System, irgendwie, 3 Local Storage oder so ist noch mit eingebunden, also irgendwelche Sachen und die ploppen alle auf, es läuft

Ne?

du hast einen Quelltext, kannst im Browser Local Host eingeben oder vielleicht sogar mit PSSH auf irgendeine lokale Domain zugreifen und kannst dann entwickeln. Machst irgendwas kaputt, gerade die Jüngeren oder die Neueren müssen ja auch keine Angst haben, was kaputt zu machen. Ja, das war am Anfang für mich ein großes Problem. Wir haben zum Beispiel in einer Agentur, war früher so üblich, zentral auf einem Server gearbeitet, in einem Verzeichnis mit vier Entwicklern. Ich habe irgendwas ausprobiert, war halt ein altes Drupal und das hat direkt dazu geführt, dass die Entity nicht zur Datenbank passt. Bumm, fünf Leute arbeitslos. Also nicht in der Lage zu arbeiten, weil ich sie blockiert habe. Und das hat dazu geführt, dass ich immer mehr Angst hatte.

Ich dachte, das war die Datenbank mit den Arbeitsverträgen. Alle entlassen. Nein, aber, ja.

Ja, okay, nicht ganz, also arbeitslos im Sinne von die Band. Die haben sich gefreut über meine Hilfe, ne?

Ja, genau. Da kommt Freude auf. Ich habe auch so Dinge erlebt zu SVN-Zeiten noch, Subversion-Zeiten, wo halt alle Projekte in einem Ding drin lagen.

Hm.

Und dann hat da jemand mit Certification einen Fehler gemacht und schon konnten x Leute nicht arbeiten. Das ist so. Da sind wir ja, wir beide. Andere möchte ich da jetzt nicht inkludieren. Zum Glück sehr weit weg von. Und ich kenne auch viele andere Leute, die da sehr weit weg von sind. Ich möchte aber nicht ausschließen, dass so etwas noch irgendwo überlebt hat die letzten Jahrzehnte. Und ich finde... Deswegen muss man auch so sehr über Standardisierung nachdenken, nicht nur in der Softwareentwicklung, sondern auch in der Entwicklungsumgebung. Wir machen das zum Beispiel so, ich bin ja extrem faul, was sowas angeht, wir haben standardisiert im Makefiles, die dann, und jetzt kommt's, aber Teile der Compose-Datei auslesen, der Composer-JSON, Composer-JSON, und anhand dessen hingehen,

Dito? Dito?

mir meine Compose ja mal aus der OCI Hürge Street ziehen. Also zum Beispiel wissen, dieses Projekt benutzt Laravel und Postgres oder Typo3 und Postgres und MariaDB und so.

Mhm.

Und dann... halt die Entwicklungsumgebung mit den richtigen Compose-Files quasi aufbauen und starten. Und dann aber auch abhängig davon die richtigen Make-Files noch einbinden, damit ich natürlich in Typo-3-Projekts die Typo-3-Klamotten habe und nicht die Laravel-Sachen und umgekehrt. Und ganz ehrlich, es ist einfach ein extremer, entspannter Luxus, morgens hinzugehen und zu sagen, Make, Start.

Make Restart ist noch geiler, wenn nichts mehr läuft. Ja. Hm.

Genau, und halt importier mir eine Datenbank, exportier mir die Datenbank, mach mal die ganzen Tests, prüf mal dieses, mach mal jenes. Ich liebe es einfach, mit diesen Make-Files zu arbeiten und damit auch komplett unsere eigenen Container zu benutzen. Das sind am Tagesende mehr oder weniger die Container, die wir auch deployen und ausrollen. Das heißt, ich habe die gleichen Probleme wie auf Prod habe ich lokal. Natürlich habe ich gar keine Probleme, weil das natürlich alles total immer auf Anhieb funktioniert und ich niemals hingehen muss und sagen muss, importiere mir die Datenbank nochmal neu.

Niemals.

Ich habe das jetzt

ein schönes Beispiel wäre zum Beispiel, du brauchst irgendeine PHP-Extension, SQL-E, weiß ich nicht, Intel oder was auch immer, packst du mit deinem Setup sozusagen einmal in die Docker-File und sobald du das durchdeployst, werden ja auch die Container neu gebaut in der Pipeline später und das purzelt automatisch bis in Pod durch, ohne dass du jetzt irgendwie noch ein Pull-Request-Infos machen musst mit auf Pod, muss noch das vorher installiert werden, du musst nicht einer anderen Abteilung Bescheid sagen, das ist so, das ist alles in einem Code und Rutscht bis auf Prott, wenn ich das richtig verstanden habe, ne? Mhm.

Ja, genau. Das ist sehr unabhängig davon, ob du jetzt irgendwie ein standardisiertes lokales Setup fährst oder ob du ernsthaft Container machst. Wenn du ernsthaft Containerisierung machst und die Container überall einsetzt, dafür brauchst du ja noch keine standardisierte Entwicklungsumgebung mit den Makefiles und hast du nicht gesehen, dann kommst du, ich schaute das auf dem Sofa runter, egal, dann hast du ja auch diese Vorteile, das sind ja einfach Vorteile von Containern und die Makefiles machen dir halt das Leben so schön einfach, indem du deine Standardaufgaben ähm

Ich kann mir sowas nicht merken.

automatisiert hast. Du musst nicht mehr darüber nachdenken, wie funktioniert denn jetzt, dass ich den Datenbankdump einspiele? Oder wie komme ich denn in diesen Container rein? Ja, Make, Shell oder SSH oder whatever. Mache Pizza.

Ich nutze Make gerne dafür, um einfach mehrere Befehle zu verketten, die ich immer wieder eingeben muss und die ich mir entweder nicht merken kann oder halt um so ein bisschen Magie mit einzubauen, entweder Find oder sowas, wo man sagt, man sucht nach gewissen Dateien und führt auf diesen dann was aus, was einfach so in der Shell so ein gepipter Befehl wäre, den packe ich einfach bei Make rein und ich kann mir einfach dann Make, weiß ich nicht, Clean oder sowas zum Beispiel viel einfacher merken.

Das habe ich auch zum Beispiel.

Oder andere Befehle, ne?

Ja, ich kombiniere auch im Make tatsächlich unterschiedliche Make-Befehle.

Mhm. Mhm.

Ich sage jetzt mal Make Start hat auch zum Beispiel Make Frontend Build drin. Und so Sachen, damit so Sachen dann halt auch mitlaufen. Was interessiert mich, wie dieser Frontend Build funktioniert? Da liegt ein Bash-Script, das das aufruft und macht und tut, dass dann irgendwie die... Packages oder so. Das ist jetzt wieder der Part, wo ich nicht Frontend-Entwicklung, aber aufruft und da die Bildbefehle ausführt. So, I don't care am Tagesende, weil das ist nicht mein Spielbereich, wo ich mich gut auskenne.

Ja. Ja.

Das ist standardisiert, das liegt da drin, das funktioniert in jedem Projekt. Und dann ist auf einmal das Leben so entspannt, ja, du hampelst da nicht mehr rum. Genauso wie halt Composer Update, Composer Install und NPM und der ganze Kram wird halt im Container ausgeführt. Der Container bringt die passende NPM-Version mit. Das war früher, fand ich, das Schlimmste wirklich irgendwie für mich zum Entwickeln war, Frontend-Build-Stack und dann wollte ich irgendwas einbauen und testen, ob mein Backend-Zeugsets funktioniert und dann hat aber das Frontend nicht gebaut und dann sah alles aus wie Kraut und Rüben Und dann findest du das Formular nicht oder so. Also als Backendentwickler ist mir relativ egal. Aber dann kannst du es ja auch niemandem zeigen mit, hey, schau mal, das funktioniert jetzt. Ist das so, wie wir das besprochen haben? Sondern es sieht direkt alles scheiße aus. Wenn du das im PM zeigst, dann zumindest in meinen Agenturzeiten früher, dann nee, so können wir aber nicht. Ja, aber das ist doch gar nicht meine Arbeit.

Ja. Ja, das macht vieles einfacher.

Das ist der Frontend-Bild. Keine Ahnung, da gab es irgendein Update. Was weiß ich denn, wie das funktioniert? Diese Themen hast du halt alle nicht mehr. Du hast nicht mehr dieses, ja, aber bei mir hat das funktioniert, weil es halt immer in dem Container war und der Container wird halt genommen, verschickt und kommt halt da an und fertig. Was machst du denn noch? Fancy Stuff mit deinen Makefights.

Also ich habe, bei mir ist über die Jahre etwas gewachsen, sage ich mal, wie ich glaube, jeder hat so sein eigenes Bildsystem und ich habe mir meins mittlerweile so aufgebaut, dass ich gesagt habe, ich möchte möglichst wenig Technik haben.

Jetzt alle Geheimnisse auf den Tisch hier heute.

Also es soll fast nichts auf dem Host ausgeführt werden. Bei mir ist es, glaube ich, aktuell einmal Make. Ich habe einmal YQ, also um Jason so ein bisschen zu manipulieren für die ganzen Composer-Yamels. Und eigentlich

Ja, und halt auch, um auszulesen halt vor allem, ne?

Was meinst du mit auslesen? Also, ja, da mache ich möglichst wenig mit.

Ja, die JSON- und HTML-Files auszulesen, um halt darauf zu reagieren, was das ist.

Also ich habe wirklich ein Make-File, was über einen Unterordner, der auch Docker heißt, einfach drüber iteriert. Für mich war dieser Modul-Gedanke da, dass es da so ein Paket, also ein Ordner PHP gibt, ein Postgres, ein Node.js. Da liegen immer so die passenden Dateien drin, also Config für einen Apache, wenn im Projekt einer gebraucht wird oder weiß ich nicht, Franken-PAP, Caddy-Config. Irgendwelche Sachen liegen dann immer in dem passenden Ordner. Make macht per Find einfach einen Docker-Compose, sucht alle Compose-Jammels, die da drin liegen und macht einen Docker-Compose ab. Dann verteile ich noch Umgebungsvariablen, die benötigt werden fürs Dev-Setup, also damit zum Beispiel die Database-URL im Container gesetzt ist für die lokale Entwicklung, damit PHP auf, ne?

Ja.

Und der Rest, also da versuche ich möglichst wenig Logik. Also ich habe ein bisschen Bash-Skripte und ein bisschen Farbe noch mit reingemacht, damit es hübsch aussieht. Und viel mehr versuche ich da aktuell nicht.

Ja, dann machen wir tatsächlich mal ein bisschen unterschiedlich. Ich mache ja in der Composer-JSON steht die PHP-Version. Sorry.

Mmh. Mmh.

Das löst aus, welchen Container ich benutze vom PHP. Ja, das war gerber. Aber ich habe halt zum Beispiel auch keine Compose-Files bei mir im Repository liegen. sondern die sind so verallgemeinert, dass ich jetzt, ich sag jetzt mal, ein Basisding habe und dann Ergänzungs-Compose-Files. Und je nachdem, was dann halt in der Composer-JSON an Sachen drinstehen, die ich auslese über Make, ändert sich halt mein Compose ab quasi, welche Dateien, also welche...

Ja. Ja.

wie heißen sie gleich, Compose, jemals aus der OCI Registry geladen werden, die werden auch gar nicht lokal abgelegt dabei, um das ganze Ding zu starten. Also wirklich so weit standardisieren und abstrahieren, dass man halt wirklich sagen kann, mein Projekt ist im Prinzip, wird definiert aus drei Dateien. Das Basis Make-File,

Mhm. Mhm.

eine NVMRC heißt sie glaube ich, da steht die MPM-Version drin, die für das Projekt gilt und dann die Composer JSON, wo auch die PHP-Version drin steht. Und damit zieht er sich dann aus der Registry die passenden Container, beziehungsweise baut die passenden Container, für die Entwicklungsumgebung, ne? Die Entwicklungsumgebung zieht sich den Port-Container quasi und geht dann hin und updatet den Container mit meinen Dev-Dependencies, die ich brauche.

Ja. Ja.

Und ich muss sagen, ich liebe es, weil das halt bedeutet, wir haben die gleichen Befehle in allen Projekten, Wir haben im Prinzip die gleichen Container, also bis auf minimale Abweichungen für da brauchst du mal ein anderes Paket als hier noch zusätzlich. Oder das ist ein Multi-Domain-Projekt und das ist ein Single-Domain-Projekt. Ja, da gibt es dann kleine Abweichungen, aber so vernachlässigbar im Großen und Ganzen.

Mhm.

Und damit ist halt alles so überschaubar und gleich geworden. Und zum Beispiel die eigenen Pakete liegen dann halt natürlich auch nicht in Vendor drin, sondern werden gesimmelinkt in eine andere Verzeichnisstruktur und werden auch mit Git-Repository gezogen, damit ich drin arbeiten kann. Was dann natürlich wieder Composer macht, nicht Make. Und ich sage jetzt mal, die einzige Arbeit, die wir zum Beispiel haben, um ein neues Projekt aufzusetzen, ist, wir ziehen uns unser basis make file legen dort ent datei an mit sowas wie okay das ist der fahrt in git lab und so sachen sachen und hier die composer die für das minimum composer quasi mit okay hier ist das drin oder hier ist das drin und dann sagen wir

Ja.

make in it it und die ganze Magie passiert, dass du dann halt, ich sag jetzt mal 20 Minuten später, dein fertiges, also fertiges Entwicklungsumgebungsprojekt da stehen hast und anfangen kannst zu entwickeln mit allen Containern, mit allen Abhängigkeiten, mit allem, was du brauchst und wenn du updaten willst, ja, ich sag jetzt mal PHP von 8.4 auf 8.5, dann änderst du das an einer Stelle Dann wird das ganze Graffel neu gebaut, wenn du dann natürlich sagst, hey, ich brauch's jetzt einmal neu, ne?

Ja, klar. Ja.

Nicht so magisch, die Datei hat sich geändert und jetzt mach ich was. Und ja, natürlich, wenn du die Abhängigkeiten in der falschen Reihenfolge updatest, dann bekommst du Probleme. Kein Wunder, aber wenn du das in der richtigen Reihenfolge machst, dann steht das System halt mit der neuen PHP-Version da. Mit den neuen Dependencies, die für die neue PHP-Version sind. Die Versionen sind da und alles ist fein. So, und okay, dieses Dependency-Update dauert halt, weil, hatten wir mal besprochen, läuft über die Pipeline bei uns.

Ja.

Aber du baust, dann gibt es halt den neuen Container und dann wird das halt gebaut, gezogen, dann dauert das halt eine Zeit. Das ist eher etwas, was man abends starten sollte, damit es über Nacht dann quasi fertig läuft. Und am nächsten Morgen hast du das da stehen und kannst weitermachen. Oder hast ganz viele rote Pipelines, die sagen, nee, Junge, jetzt hast du aber hier Mist gemacht. Ja, so.

Dann machst du einen Laptop, den du da zugehörst und nimmst frei. Aber ich glaube, also ich finde interessant, dein Ansatz ist anders wie meiner und ich glaube, der Use Case war bis jetzt auch komplett anders, weil ich als Externer immer in andere Projekte reingekommen bin und da unterstützt habe, habe ich dieses, also sagen wir mal, mein Sammelsorium mitgebracht und so ist das auch die Zeit über gewachsen.

Mhm.

Weil ich halt immer gesehen habe, es gibt Linux-Rechner, es gibt Mac OS, es gab auch Windows-Rechner, die dann auch irgendwie versuchen, da mitzuspielen. Und das musste halt irgendwie funktionieren. Und gerade externe Abhängigkeiten, also wenn ich jetzt zum Beispiel als Externer reinkomme und sage, hier, das Ding zieht aus meinem Repository irgendwas, das wäre so uncool.

Ja. Ja. Ja.

Deswegen war... Mein Ansatz immer so, ich bringe alles mit, es wird eingecheckt, weil ich habe eine Zeit lang auch mit Git-Submodules da ein bisschen rumgespielt, aber das hat nie so richtig funktioniert und ich mag das, wenn das mit eingecheckt ist. Wenn ich Sachen ändere, kann ich das im Feature-Branch pushen. pullen und kann dann sagen, guck mal, es gab ein Update, morgen machen die alle Make Start und dann baut das automatisch die Container neu, weil natürlich neuer Quelltech-Code auch in dem Docker-Ordner mit drin ist. Bei dir macht das aber natürlich viel mehr Sinn, wenn du aus deiner Sicht mehrere Projekte betreust und die Mitarbeiter da immer das gleiche Setup vorfinden. Also bei euch ist

Ja, genau, also das, klar, wenn du immer in wechselnde Projekte reinkommst, kannst du natürlich sagen, no, wir bauen jetzt ja erstmal alles um.

Ich bringe mal meine Dependency mit und mache mich unaustauschbar. Ja. Ja.

Abgesehen davon, dass diese Makefiles auch einfach ein Composer-Package bei uns sind, ne, also, und man die einfach öffentlich machen könnte, wenn man wollte. Naja, mal drüber nachdenken. Aber, ähm, Natürlich, wenn du ständig in neue Projekte reinkommst, dann veränderst du nicht einfach alles und die ganze Welt. Anderer Anwendungsfall, wenn ich in externe Projekte reinkomme, dann habe ich das auch nicht. Aber ich kann mir ja immer, wenn ich, ich sage jetzt mal, wenn ich in meinem Wohnzimmer sitze, dann kann ich mir ja mein Wohnzimmer so gestalten, wie ich es gerne hätte.

Ja.

Und da ich irgendwie sehr viel Zeit mit diesem Zeug zubringe jeden Tag, und das ist mehr Zeit, als ich in meinem Wohnzimmer sitze, und zwar pro Tag mehr als ich in der Woche im Wohnzimmer sitze, wenn ich so drüber nachdenke, dann darf das auch schön komfortabel und einfach sein. Ich habe auch mal drüber nachgedacht, oder was wir auch machen, ist, wir arbeiten mit Devcontainers, das ist auch so ein Standard, mal ein bisschen weniger, dass wir eben als quasi Fallback-Backup-Lösung haben, wenn ich mal unterwegs bin, dass ich jedes Projekt benutzen kann, das nämlich in einem Cluster starten kann und da eine normale Entwicklungsumgebung vorfinde mit VS Code, in dem Fall nicht mit meiner Lieblings-IDE, aber das ist vernachlässigbar an der Stelle.

Ja.

Das heißt, ich kann halt ein Entwicklungssystem in einem Cluster, gesonderten Entwicklungskluster starten, ganz normal entwickeln und arbeiten und mein Zeugs machen, ohne dass ich das lokal auf dem Rechner brauche. Das ist quasi die Variante für, ich habe geiles Internet, aber ich sitze jetzt quasi nur am iPad oder so, muss jetzt aber schnell was ändern, dann kann man das machen. Oder die Variante mit, irgendwie bricht meine Verbindung ständig beim Download aus der Registry ab. weil ich jetzt gerade am anderen Ende der Welt sitze und dann die Verbindung nicht so stabil ist, die ist zwar schnell, aber nicht stabil, dann funktioniert, ich starte das im Entwicklungskluster und arbeite da stabiler und zuverlässiger, weil unsere Browser irgendwie viel besser damit klarkommen als so ein Docker-Pull, wenn die Verbindung zwischendrin weg ist.

Ja.

und klar, die Herangehensweise, aus welcher Richtung wir jetzt kommen für diese Makefights und so, ist halt gerade, ich sag, ich mach schöner Wohnen in meinem Wohnzimmer, und genau, so, und ja, das ist ja auch völlig okay, wenn ich das möchte, ist das gut,

Ich mache schöner Wohnen in deinem Wohnzimmer. Aber ich bin auch der Raumausstatter, den du gekauft hast, damit es hübsch aussieht, ne? Hm.

Und genauso, wenn ich natürlich irgendwo reinkomme in ein Projekt, dann gehe ich da ja auch anders vor. Dann sage ich jetzt nicht so, wir updaten jetzt alles auf das und das ist der einzige Weg, der existiert. Dann bringe ich vielleicht auch Teile meiner Sachen mit, aber da macht es dann wahrscheinlich auch gar keinen Sinn, diesen Puls-Deck-Komfortmodus zu wählen. Sondern da macht es dann wahrscheinlich Sinn, so ein paar Make-Befehle zu haben für, okay, ich fange jetzt mal morgens an, ich höre abends auf, ich mache hier irgendwelche Updates, vielleicht dann doch nicht so wie bei uns mit der Pipeline.

Der passt sich dem Gastgeber an.

Das ist ja einfach ein anderes Leben, wenn man in ein, ich sage mal, wenn du zu jemand anderen als Besuch kommst, kommst, dann fängst du jetzt ja auch nicht an und baust das Wohnzimmer ungefragt um. Und gestalte es um. Wenn natürlich jemand sagt und kauft mich jetzt sogar als Raumausstatter ein und sagt, hier, mach mal schön, ganz andere Baustelle, wie du schon sagst.

Ja, aber trotzdem, ich würde dann, also, um bei der Analogie zu bleiben, ich komme hin und sage, guck mal, das wären coole Vorhänge, das wäre eine coole Couch und ich komme nicht hin mit dem Maurer und irgendwie anderen Bauarbeitern und fange an, das Wohnzimmer zu zerlegen, ohne dass der Besitzer weiß, was da passiert.

Ja, vor allem komme ich nicht hin als Gast, der ja nur eingeladen ist, da mal, ich sag jetzt mal, Kuchen zu essen und zu sagen, ob der Kaffee jetzt ist.

Ja, ja. Hm.

Dann komme ich ja nicht hin und sage, na, du brauchst andere Vorhänge. Also, vielleicht ist das zum Schluss so ein Fazit, wo ich sage, mir ist noch aufgefallen, ihr könntet hier die und die Sachen ja verändern, wenn ich dann quasi in dieser beratenen Rolle eingekauft bin für, ey, sag mal, würdest du hier unser Ding nutzen, testen?

Ja, aber um von der Analogie zurückzukommen, ich finde interessant, obwohl wir unterschiedliche Anforderungen haben, also für dich die Reproduzierbarkeit und immer die gleiche Umgebung, für mich also auch Reproduzierbarkeit natürlich, aber Individualisierbarkeit eigentlich, haben wir trotzdem sehr ähnliche Lösungsansätze gewählt, dass wir einen Ordner haben, wo, sagen wir mal, modulbasiert

Also, oder ja, da hinkt jetzt das Wohnzimmer, da wäre eine Party-Location besser, aber du verstehst, was ich meine, ne? So.

die Sachen drin landen, wo mit Docker Compose werden Docker Container gestartet.

Ja.

Zum Beispiel ist es auch so, dass bei meinem Ansatz, ich denke mal bei deinem wird es auch so sein, dass man make.php.bash bei mir aufrufen kann und dann landest du in dem PHP Container und kannst dann mit PHP alles Mögliche machen. Du kannst genauso in den Node-Container oder in den Postgres-Container reingehen und da auf der Konsole Sachen machen. Also du musst nicht von außen in den Container und dann irgendwelche komischen Sachen da rum pushen, sondern mein Grundgedanke war einfach so, ich arbeite in dem Container, als ob das ein Remote-Server wäre.

Ja, und ich muss ja auch ein bisschen noch enttäuschen, ne, also wir setzen keine Dockerfiles mehr ein, sondern Containerfiles.

Also zwar nicht per SSH, aber... Ich komme auf die Bash, kann da Sachen machen, kann das Shell-Skript, also eine BIN-Konsole zum Beispiel unter Symfony ausführen und solche Sachen. Und das macht es schon sehr angenehm. Angeber. Mhm.

Kein Docker-Compose, sondern bei uns ist es tatsächlich Portman, auf das wir migrat haben. So, ähm,

Wäre mal wieder ein neues Thema. Warum?

Neues Thema, ja. Für die nächste Woche oder so.

Ja. Mhm.

Passt das? Haben wir alles gesagt oder möchten wir noch was sagen? Wir können doch noch weiter reden. Ich glaube, wir haben jetzt ja aus unterschiedlichen Richtungen sind wir gekommen. Was ich auch noch kurz, bevor ich es vergesse, zu sagen in dieser Folge, was ich hervorragend cool finde, ist die Individualisierbarkeit geht ja nicht kaputt. Du kannst ja durchaus sagen, in dem Projekt hier, selbst wenn ich die Dependency halt hier lade aus, ich sage jetzt mal mein Dev-Paket von meinem Makefile, kannst du den einzelnen make job in deiner lokalen make einem lokalen make file verändern und überschreiben und halt sagen ja pass auf dass hier funktioniert aber dieser job ich sag jetzt mal frontend bild halt anders du rufst nicht dass das bild sh auf sondern hier machst du jetzt mpx bla bla bla so das

Ja.

geht alles. Du verlierst halt durch diese Paketierung, die wir haben, nie die Möglichkeit, individuell zu sein. Es ist halt... ich sage jetzt mal, ein starker Standard, auf den wir aufbauen, den wir aber auch grundsätzlich jederzeit an allen Ständen individualisieren können und das mit wenig Aufwand.

Ja. Nicht immer die gleichen Fehler lösen.

Das heißt, wir gehen hin und ich glaube, das ist auch dein Grundgedanke, wenn ich dich richtig verstanden habe, wir machen uns das Leben einfacher bei uns mit dem Ziel, das möglichst häufig auch zu verwenden, für dich das Ziel, möglichst einfach in die Projekte reinzukommen und überall auch ja eine Standardisierbarkeit vorzufinden oder ein standardisierteres Setup vorzufinden, damit sie es, ja, und wo wollte ich denn jetzt hin? Oh, verdammt.

Machen wir wieder Cliffhanger diesmal. Ich weiß es nicht, wo du hin wolltest. Überschreibbarkeit.

Ja, ja. Ja, Standardisierbarkeit, immer das Gleiche. Und... Ach genau, du bist halt trotz dieser Standardisierung jederzeit in der Lage, individuell zu arbeiten. Aber mit diesem Standardisieren sparen wir uns im Prinzip sehr, sehr viel Zeit im täglichen Arbeiten. Das heißt, wir reduzieren diesen Zeit-Overhead durch dieses Standardisieren massiv, sind aber genauso flexibel und bei diesem Flexibelsein schneller als diejenigen, die nicht standardisieren.

Ja, ja, also genau, weil man nicht immer wieder die gleichen Fehler macht und weil man mit so einem Dev-Setup schon eine gute Grundlage für alle weiteren Schritte hat. Du kannst aus diesem Dev-Setup bei uns beiden direkt Container fürs Produktivsystem bauen, die gleich sind. Und wenn du solche Unterschiede nicht hast, spart dir das viel Lebenszeit bei Fehlersuche später.

Ja, wobei die Pipeline ja die Containerarbeit, aber du hast halt deinen... Ja, genau.

Ja, aber zumindest bei mir ist es die Docker-File, die in diesem Ordner liegt. Das Basis-Image ist sozusagen das Produktiv-Image. Dahinter kommen dann die Dev-Setup-Sachen nochmal rein. Also hier, ne?

Ja, ich wollte nur betonen, dass du ja nicht lokal das Produktiv-Image baust, sondern das baut ja die Pipeline.

Nein, okay. Ja, du hast natürlich recht, das mache ich nicht. Das wäre ja dumm.

das ist ja nicht unbedingt dumm, aber keine gute Idee.

Ja, also definitiv machen wir das nicht.

Wenn wir die Pipeline haben mit Sicherheitschecks und so weiter, dann wäre es einfach keine gute Idee zu sagen, jetzt baue ich aber lokal das Pod-Image, weil bei mir funktioniert ja alles, habe meine Dev-Dependencies und alles drin, am besten noch irgendwelche Dev-Secrets mit reinkopiert und dann sitze ich nämlich da und dann läuft es produktiv halt doch nicht so gut.

Bitbox on my machine. Hm. Ah, nee.

Das machen wir nicht, aber wir sagen halt, dass es so standardisiert, dass es startet, man eine gute Entwicklungsumgebung hat und alle Fights irgendwie drin liegen damit daraus in der Pipeline, die produktive Umgebung entsteht.

Und was auch wichtig ist, ist dadurch, dass ich vieles abstrahiert habe, brauche ich fast keine Produktiv-Secrets mehr, weil ich Tests erstmal fahren kann, ohne dass ich, also entweder mit gemockten Systemen oder ähnlichen Systemen, ohne dass ich dann irgendwie nochmal gegen das Produktiv-System was anschließen muss oder runterladen muss. Und das ist halt so nebenbei auch angenehm, einfach in der Pipeline dann keine Secrets mehr zu brauchen. Ja.

Nicht nur in der Pipeline, auch lokal, ne? Du kennst ja mal ein Kilo. Das, was ich nicht weiß, kann ich nicht vergessen. Zumindest was Secrets angeht.

Ja.

Und, ähm, tatsächlich ist es ganz nice, das alles nicht zu wissen. Die Systeme wissen es, die managen das. Ähm, ich hab's nicht irgendwo im Passwortmanager bestes Leben. Also, ich liebe es.

Und Dev-Setups sind einfach, die sparen dir viel Lebenszeit, viel Ärger, gerade auch oft, wenn irgendwas kaputt ist.

Und,

Also du bist am Entwickeln und sagst, komisch, das hat da vorhin funktioniert, warum ist das jetzt so? Einmal kurz neu gestartet, hast du wieder den Ursprungszustand und dann ist wieder der Fehler weg. Dann hast du irgendwas kaputt gemacht, wo du nicht aufgepasst hast. In der Datenbank datentechnisch, dann kannst du einfach weiterarbeiten. Und früher wäre das so irgendwie drei Stunden Fehlersuche gewesen, um zu merken, dass man dann etwas gemacht hat, was man vergessen hat. Deswegen, Dev-Setups sind super.

Genau.

Also, sparen dir so viel Lebenszeit. Ja, gerne.

Und ich glaube, nächstes Mal sprechen wir dann, wenn ich es richtig verstanden habe, warum wir nicht mehr Wale für den Containertransportbetrieb einsetzen, sondern Seehunde. Ich glaube, es sind Seehunde bei Podman. Ja. Nein, Wale sind sehr cool. Aber zwei Wale sind vielleicht zu groß. Wortwitz. Kann ich.

Ist schon Karneval. Ist schon Karneval oder was?

Hm? Noch nicht ganz. Aber dann sehen wir uns nächste Woche. Und das tisern wir jetzt schon an. Dann mit Docker versus Potman oder warum wir auf Potman sitzen. Statt auf Docker.

Ja, sehr interessant. Habe ich mich fünf Minuten vorher wieder schlau.

Bis dahin. Macht's gut.

Ciao.

Ciao.