Transcript
Kai Ole Hartwig: Willkommen zu einer weiteren wunderbaren Folge Secrets Not Included, nachdem ich letztes Mal Daniel abrupt in seinen Diplomates unterbrochen habe.
Kai Ole Hartwig: Wieder zurück mit Daniel und Ole und ich glaube, wir steigen einfach nahtlos ein in das Ende der letzten Woche.
Daniel Langemann: Ja, wir lösen endlich den Cliffhanger auf.
Daniel Langemann: So, nach der letzten Folge geht es jetzt nicht weiter, mitten im Plot.
Kai Ole Hartwig: und reden einfach mal so ein bisschen über Deployment und Standardisierung, auch was Entwicklungsumgebung angeht.
Kai Ole Hartwig: Sehr gut.
Kai Ole Hartwig: Ich glaube, wir waren dabei stehen geblieben, dass wir gesagt haben, automatisierte Deployments sind heute das Bare Minimum und kein Princess Treatment mehr.
Kai Ole Hartwig: nicht nur für Entwickler, sondern für die gesamte Company.
Kai Ole Hartwig: 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?
Daniel Langemann: Ja, also wir reden ja immer viel von Secrets und wie Sachen zu funktionieren haben.
Daniel Langemann: 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.
Daniel Langemann: Aber...
Daniel Langemann: Das fängt ja nicht nur beim Deployment an, sondern eigentlich viel früher.
Daniel Langemann: Und zwar ist es, es fängt mit der Entwicklerumgebung an.
Daniel Langemann: Also wie ich auf dem lokalen Rechner entwickle,
Daniel Langemann: Habe ich die gleichen Abhängigkeiten installiert?
Daniel Langemann: Gibt es Testdaten?
Daniel Langemann: Wie sind Sachen aufgebaut?
Daniel Langemann: Und wie komme ich theoretisch von?
Daniel Langemann: Oder ich sage mal, theoretisches Beispiel ist, Chef ruft an, oh mein Gott, im Shop ist irgendwas kaputt.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Ein Icon, ein Bild ist verrutscht, ein Button ist rot und nicht grün.
Daniel Langemann: Irgendwie solche Sachen gibt es ja immer so.
Daniel Langemann: Man ist gerade schön in seinem Thema und dann wird man so komplett rausgerissen.
Daniel Langemann: Erste Frage ist, okay, auf welchem Stand ist denn das Produktivsystem gerade?
Daniel Langemann: Weil ich bin ja gerade aktiv am Entwickeln, ein anderer Kollege ist was am Machen.
Daniel Langemann: Es gibt schon zwei Features, die sind fertig, die sollen ausgerollt werden, die habe ich auch mitgetestet.
Daniel Langemann: Und schon hast du so erstmal, was ist gerade die Produktivversion?
Daniel Langemann: Vielleicht hast du auch irgendeinen komischen Fall, den du lokal hast, das Feature gebaut.
Daniel Langemann: So ein üblicher Fall mit Works on my Machine.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Das ist bis auf Produktiv gekommen und da knallt das.
Daniel Langemann: 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.
Kai Ole Hartwig: Ach Daniel, du machst das alles viel zu kompliziert, weißt du, ne?
Kai Ole Hartwig: Wir haben früher direkt auf dem Produktivsystem noch mit FTP deployed, warum sollten wir nicht einfach drauf gehen?
Kai Ole Hartwig: Aufs Produktivsystem, dann entwickeln wir kurz da mit Cloud Code oder Open Code oder whatever welcher KI und das löst doch alle Probleme.
Daniel Langemann: Ja, war das... Ich darf jetzt öffentlich keine Gewalt androhen.
Kai Ole Hartwig: Ich weiß gar nicht, was du da jetzt... Gut, dass uns ein paar Kilometer trennen.
Daniel Langemann: Nein, also jeder hat das schon mal gemacht, ich natürlich auch.
Daniel Langemann: Es führt einfach dazu, wenn ich alleine als Entwickler arbeite, dann kann sowas fast noch funktionieren.
Daniel Langemann: Also ich bin zu schlampig dafür, ich schaffe das selbst alleine nicht, aber es gibt ordentliche Leute, die schaffen das.
Daniel Langemann: spätestens ab zwei oder drei Entwicklern ist das so, irgendjemand macht was, lädt was hoch, vergisst die Datei.
Daniel Langemann: Und schon hast du auf jedem Rechner, also jeder Entwickler hat eine andere Version.
Daniel Langemann: Der eine hat seine Version hochgeladen, Entwickler B lädt seine, also eine Version von einer anderen Datei hochgeladen.
Kai Ole Hartwig: Nein, nein.
Kai Ole Hartwig: 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.
Daniel Langemann: Du möchtest dich bald trennen sehen.
Kai Ole Hartwig: Also ich kenne jemand, der tut das.
Daniel Langemann: Ja, ich versuche gerade,
Kai Ole Hartwig: Also es bin nicht mal ich selber.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Jetzt habe ich dich kurz geschockt.
Kai Ole Hartwig: Ich trinke kurz einen Tee zwischendrin.
Kai Ole Hartwig: Ohne Rum.
Daniel Langemann: Ich versuche gerade den nächsten Shitstorm zu vermeiden, indem ich mich zu sehr dazu äußere und... Wie kann ich denn da... Hm.
Kai Ole Hartwig: Nein, aber wir sind uns ja einig, wenn man, also zugegebenerweise ist es ein einzelner Entwickler.
Kai Ole Hartwig: Ich finde das ein crazy Ansatz.
Kai Ole Hartwig: Mir ist der zu verrückt.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Da gibt es auch keine Pipelines, ne?
Daniel Langemann: Nee.
Daniel Langemann: Ja, hm.
Kai Ole Hartwig: Übrigens fällt mir dabei so auf.
Kai Ole Hartwig: Brauchst du ja nicht, wenn du auf dem Produktivsystem arbeitest.
Kai Ole Hartwig: Aber jeder hat ja halt ein Testsystem, ne?
Kai Ole Hartwig: Um mal den Bogen zu bekommen.
Kai Ole Hartwig: Wenn das Produktivsystem natürlich nicht das Testsystem ist, gewinnt man schon viel.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Und, ähm, hey, ja, natürlich entwickelt man auch mit KI gar nichts dagegen, aber vielleicht auch nicht auf dem Produktivsystem.
Kai Ole Hartwig: Wir haben mal festgestellt, ähm,
Kai Ole Hartwig: die KI-produktive Infrastruktur managen zu lassen, selbstständig ohne Review ist auch keine gute Idee.
Kai Ole Hartwig: Aber erst.
Kai Ole Hartwig: Also, nicht, dass mir das nicht letztens selber passiert ist.
Daniel Langemann: Ihr räumt gerne auf, so Produktivdatenbanken habe ich gehört.
Daniel Langemann: Hat mir ein Freund erzählt.
Kai Ole Hartwig: Es war aber nur das Testsystem, also nicht so schlimm.
Daniel Langemann: Ja.
Daniel Langemann: Genau.
Kai Ole Hartwig: Auf dem Produktivsystem der KI Zugriff geben, dafür bin ich nicht mutig genug.
Kai Ole Hartwig: Aber auf dem Testsystem hat sich tatsächlich einfach mal die Datenbank weggeschmissen.
Kai Ole Hartwig: Sehr gut.
Kai Ole Hartwig: Aber heißt ja, das, was, glaube ich, wir beide bevorzugen, sind starke Entwicklungsumgebungen, die im Prinzip das Produktivsystem vollständig nachbilden.
Kai Ole Hartwig: oder zumindest in dem Teil vollständig nachbilden, in dem wir arbeiten.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: Und dann müssen wir ja darüber nachdenken, was machen wir denn damit, die Entwickler auch irgendwie parat kommen.
Kai Ole Hartwig: Miteinander, aber auch mit der Umgebung an sich.
Kai Ole Hartwig: Das heißt, wir brauchen ja auch eine Standardisierung dieser Entwicklungsumgebung.
Kai Ole Hartwig: 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.
Daniel Langemann: Da werde ich heute Nacht von träumen, danke.
Kai Ole Hartwig: Bitte, den Psychiater musst du aber bitte selber bezahlen.
Daniel Langemann: Ja, ja, mache ich.
Daniel Langemann: Ja, also die Entwicklungsumgebung ist einfach so, ich möchte ja erst mal
Daniel Langemann: etwas ausprobieren können.
Daniel Langemann: Also wenn ich ein Feature baue oder ein Bug fixe, ich möchte etwas ausprobieren können.
Kai Ole Hartwig: Ja, also nur wenn du in Deutschland Zug fährst.
Daniel Langemann: Wie weit kann ich das denn lokal?
Daniel Langemann: Und dann ist zum Beispiel die Frage, gerade wenn man remote arbeitet, nicht immer ist eine gute Internetverbindung da.
Daniel Langemann: Also es könnte Leute geben, die arbeiten aus dem Zug.
Daniel Langemann: Zum Beispiel, da kannst du gar nicht per SSH irgendwie auf den Server und da andauernd tun und machen.
Daniel Langemann: Ja, das ist jetzt meine Annahme.
Daniel Langemann: In anderen Ländern vielleicht nicht, aber
Kai Ole Hartwig: Also ich kann dir sagen, sobald der Eurostar über die Gänze ist, funktioniert Internet tadellos im Zug.
Kai Ole Hartwig: Selbst unterm Ärmelkanal, alles kein Thema.
Daniel Langemann: Schalten wir es dann an?
Daniel Langemann: Ja, also...
Kai Ole Hartwig: Da kannst du auch deinen Videolivestream machen, das ist kein Thema.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Oder halt nicht so viel Datenvolumen, um mal eben mal wieder Container-Dependencies oder sonst irgendwas runterzuladen.
Daniel Langemann: Andersrum ist es ja auch so, externe Dienste sind auch nicht zuverlässig.
Daniel Langemann: 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.
Daniel Langemann: Also erstmal die Abhängigkeiten nach außen hin möchte man natürlich nicht haben.
Kai Ole Hartwig: Mhm.
Daniel Langemann: 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.
Daniel Langemann: Ich möchte zum Beispiel sagen können, was passiert, wenn die Datenbank nicht da ist?
Daniel Langemann: Wie verhält sich meine Applikation?
Daniel Langemann: 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.
Daniel Langemann: Im Produktivsystem testen wäre jetzt nicht so cool und in anderen Setups ist das auch schwer dann zu testen zum Beispiel.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und wenn es darum geht, irgendwas zu löschen in der Datenbank und ich baue gerade das Feature, was zum Löschen da ist.
Daniel Langemann: wenn ich da tausendmal klicken muss und das wieder von Hand anlegen muss, da werde ich verrückt dabei.
Daniel Langemann: 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
Kai Ole Hartwig: Ne?
Daniel Langemann: du hast einen Quelltext, kannst im Browser Local Host eingeben oder vielleicht sogar mit PSSH auf irgendeine lokale Domain zugreifen und kannst dann entwickeln.
Daniel Langemann: Machst irgendwas kaputt, gerade die Jüngeren oder die Neueren müssen ja auch keine Angst haben, was kaputt zu machen.
Daniel Langemann: Ja, das war am Anfang für mich ein großes Problem.
Daniel Langemann: Wir haben zum Beispiel in einer Agentur, war früher so üblich, zentral auf einem Server gearbeitet,
Daniel Langemann: in einem Verzeichnis mit vier Entwicklern.
Daniel Langemann: Ich habe irgendwas ausprobiert, war halt ein altes Drupal und das hat direkt dazu geführt, dass die Entity nicht zur Datenbank passt.
Daniel Langemann: Bumm, fünf Leute arbeitslos.
Daniel Langemann: Also nicht in der Lage zu arbeiten, weil ich sie blockiert habe.
Daniel Langemann: Und das hat dazu geführt, dass ich immer mehr Angst hatte.
Kai Ole Hartwig: Ich dachte, das war die Datenbank mit den Arbeitsverträgen.
Kai Ole Hartwig: Alle entlassen.
Kai Ole Hartwig: Nein, aber, ja.
Daniel Langemann: Ja, okay, nicht ganz, also arbeitslos im Sinne von die Band.
Daniel Langemann: Die haben sich gefreut über meine Hilfe, ne?
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: Da kommt Freude auf.
Kai Ole Hartwig: Ich habe auch so Dinge erlebt zu SVN-Zeiten noch, Subversion-Zeiten, wo halt alle Projekte in einem Ding drin lagen.
Daniel Langemann: Hm.
Kai Ole Hartwig: Und dann hat da jemand mit Certification einen Fehler gemacht und schon konnten x Leute nicht arbeiten.
Kai Ole Hartwig: Das ist so.
Kai Ole Hartwig: Da sind wir ja, wir beide.
Kai Ole Hartwig: Andere möchte ich da jetzt nicht inkludieren.
Kai Ole Hartwig: Zum Glück sehr weit weg von.
Kai Ole Hartwig: Und ich kenne auch viele andere Leute, die da sehr weit weg von sind.
Kai Ole Hartwig: Ich möchte aber nicht ausschließen, dass so etwas noch irgendwo überlebt hat die letzten Jahrzehnte.
Kai Ole Hartwig: Und ich finde...
Kai Ole Hartwig: Deswegen muss man auch so sehr über Standardisierung nachdenken, nicht nur in der Softwareentwicklung, sondern auch in der Entwicklungsumgebung.
Kai Ole Hartwig: 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,
Daniel Langemann: Dito?
Daniel Langemann: Dito?
Kai Ole Hartwig: mir meine Compose ja mal aus der OCI Hürge Street ziehen.
Kai Ole Hartwig: Also zum Beispiel wissen, dieses Projekt benutzt Laravel und Postgres oder Typo3 und Postgres und MariaDB und so.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und dann...
Kai Ole Hartwig: halt die Entwicklungsumgebung mit den richtigen Compose-Files quasi aufbauen und starten.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und ganz ehrlich, es ist einfach ein extremer, entspannter Luxus, morgens hinzugehen und zu sagen, Make, Start.
Daniel Langemann: Make Restart ist noch geiler, wenn nichts mehr läuft.
Daniel Langemann: Ja.
Daniel Langemann: Hm.
Kai Ole Hartwig: Genau, und halt importier mir eine Datenbank, exportier mir die Datenbank, mach mal die ganzen Tests, prüf mal dieses, mach mal jenes.
Kai Ole Hartwig: Ich liebe es einfach, mit diesen Make-Files zu arbeiten und damit auch komplett unsere eigenen Container zu benutzen.
Kai Ole Hartwig: Das sind am Tagesende mehr oder weniger die Container, die wir auch deployen und ausrollen.
Kai Ole Hartwig: Das heißt, ich habe
Kai Ole Hartwig: die gleichen Probleme wie auf Prod habe ich lokal.
Kai Ole Hartwig: 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.
Daniel Langemann: Niemals.
Kai Ole Hartwig: Ich habe das jetzt
Daniel Langemann: 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
Daniel Langemann: Rutscht bis auf Prott, wenn ich das richtig verstanden habe, ne?
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: Das ist sehr unabhängig davon, ob du jetzt irgendwie ein standardisiertes lokales Setup fährst oder ob du ernsthaft Container machst.
Kai Ole Hartwig: Wenn du ernsthaft Containerisierung machst und die Container
Kai Ole Hartwig: ü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
Daniel Langemann: Ich kann mir sowas nicht merken.
Kai Ole Hartwig: automatisiert hast.
Kai Ole Hartwig: Du musst nicht mehr darüber nachdenken, wie funktioniert denn jetzt, dass ich den Datenbankdump einspiele?
Kai Ole Hartwig: Oder wie komme ich denn in diesen Container rein?
Kai Ole Hartwig: Ja, Make, Shell oder SSH oder whatever.
Kai Ole Hartwig: Mache Pizza.
Daniel Langemann: 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.
Kai Ole Hartwig: Das habe ich auch zum Beispiel.
Daniel Langemann: Oder andere Befehle, ne?
Kai Ole Hartwig: Ja, ich kombiniere auch im Make tatsächlich unterschiedliche Make-Befehle.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ich sage jetzt mal Make Start hat auch zum Beispiel Make Frontend Build drin.
Kai Ole Hartwig: Und so Sachen, damit so Sachen dann halt auch mitlaufen.
Kai Ole Hartwig: Was interessiert mich, wie dieser Frontend Build funktioniert?
Kai Ole Hartwig: Da liegt ein Bash-Script, das das aufruft und macht und tut, dass dann irgendwie die...
Kai Ole Hartwig: Packages oder so.
Kai Ole Hartwig: Das ist jetzt wieder der Part, wo ich nicht Frontend-Entwicklung, aber aufruft und da die Bildbefehle ausführt.
Kai Ole Hartwig: So, I don't care am Tagesende, weil das ist nicht mein Spielbereich, wo ich mich gut auskenne.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Das ist standardisiert, das liegt da drin, das funktioniert in jedem Projekt.
Kai Ole Hartwig: Und dann ist auf einmal das Leben so entspannt, ja, du hampelst da nicht mehr rum.
Kai Ole Hartwig: Genauso wie halt Composer Update, Composer Install und NPM und der ganze Kram wird halt im Container ausgeführt.
Kai Ole Hartwig: Der Container bringt die passende NPM-Version mit.
Kai Ole Hartwig: Das war früher, fand ich, das Schlimmste wirklich irgendwie für mich zum Entwickeln war,
Kai Ole Hartwig: 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
Kai Ole Hartwig: Und dann findest du das Formular nicht oder so.
Kai Ole Hartwig: Also als Backendentwickler ist mir relativ egal.
Kai Ole Hartwig: Aber dann kannst du es ja auch niemandem zeigen mit, hey, schau mal, das funktioniert jetzt.
Kai Ole Hartwig: Ist das so, wie wir das besprochen haben?
Kai Ole Hartwig: Sondern es sieht direkt alles scheiße aus.
Kai Ole Hartwig: Wenn du das im PM zeigst, dann zumindest in meinen Agenturzeiten früher, dann
Kai Ole Hartwig: nee, so können wir aber nicht.
Kai Ole Hartwig: Ja, aber das ist doch gar nicht meine Arbeit.
Daniel Langemann: Ja.
Daniel Langemann: Ja, das macht vieles einfacher.
Kai Ole Hartwig: Das ist der Frontend-Bild.
Kai Ole Hartwig: Keine Ahnung, da gab es irgendein Update.
Kai Ole Hartwig: Was weiß ich denn, wie das funktioniert?
Kai Ole Hartwig: Diese Themen hast du halt alle nicht mehr.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Was machst du denn noch?
Kai Ole Hartwig: Fancy Stuff mit deinen Makefights.
Daniel Langemann: 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.
Kai Ole Hartwig: Jetzt alle Geheimnisse auf den Tisch hier heute.
Daniel Langemann: Also es soll fast nichts auf dem Host ausgeführt werden.
Daniel Langemann: Bei mir ist es, glaube ich, aktuell einmal Make.
Daniel Langemann: Ich habe einmal YQ, also um Jason so ein bisschen zu manipulieren für die ganzen Composer-Yamels.
Daniel Langemann: Und eigentlich
Kai Ole Hartwig: Ja, und halt auch, um auszulesen halt vor allem, ne?
Daniel Langemann: Was meinst du mit auslesen?
Daniel Langemann: Also, ja, da mache ich möglichst wenig mit.
Kai Ole Hartwig: Ja, die JSON- und HTML-Files auszulesen, um halt darauf zu reagieren, was das ist.
Daniel Langemann: Also ich habe wirklich ein Make-File, was über einen Unterordner, der auch Docker heißt, einfach drüber iteriert.
Daniel Langemann: Für mich war dieser Modul-Gedanke da, dass es da so ein Paket, also ein Ordner PHP gibt, ein Postgres, ein Node.js.
Daniel Langemann: 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.
Daniel Langemann: Irgendwelche Sachen liegen dann immer in dem passenden Ordner.
Daniel Langemann: Make macht per Find einfach einen Docker-Compose, sucht alle Compose-Jammels, die da drin liegen und macht einen Docker-Compose ab.
Daniel Langemann: 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?
Kai Ole Hartwig: Ja.
Daniel Langemann: Und der Rest, also da versuche ich möglichst wenig Logik.
Daniel Langemann: Also ich habe ein bisschen Bash-Skripte und ein bisschen Farbe noch mit reingemacht, damit es hübsch aussieht.
Daniel Langemann: Und viel mehr versuche ich da aktuell nicht.
Kai Ole Hartwig: Ja, dann machen wir tatsächlich mal ein bisschen unterschiedlich.
Kai Ole Hartwig: Ich mache ja in der Composer-JSON steht die PHP-Version.
Kai Ole Hartwig: Sorry.
Daniel Langemann: Mmh.
Daniel Langemann: Mmh.
Kai Ole Hartwig: Das löst aus, welchen Container ich benutze vom PHP.
Kai Ole Hartwig: Ja, das war gerber.
Kai Ole Hartwig: Aber ich habe halt zum Beispiel auch keine Compose-Files bei mir im Repository liegen.
Kai Ole Hartwig: sondern die sind so verallgemeinert, dass ich jetzt, ich sag jetzt mal, ein Basisding habe und dann Ergänzungs-Compose-Files.
Kai Ole Hartwig: 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...
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also wirklich so weit standardisieren und abstrahieren, dass man halt wirklich sagen kann, mein Projekt ist im Prinzip, wird definiert aus drei Dateien.
Kai Ole Hartwig: Das Basis Make-File,
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und damit zieht er sich dann aus der Registry die passenden Container, beziehungsweise baut die passenden Container,
Kai Ole Hartwig: für die Entwicklungsumgebung, ne?
Kai Ole Hartwig: Die Entwicklungsumgebung zieht sich den Port-Container quasi und geht dann hin und updatet den Container mit meinen Dev-Dependencies, die ich brauche.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und ich muss sagen, ich liebe es, weil das halt bedeutet, wir haben die gleichen Befehle in allen Projekten,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Oder das ist ein Multi-Domain-Projekt und das ist ein Single-Domain-Projekt.
Kai Ole Hartwig: Ja, da gibt es dann kleine Abweichungen, aber so vernachlässigbar im Großen und Ganzen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und damit ist halt alles so überschaubar und gleich geworden.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Was dann natürlich wieder Composer macht, nicht Make.
Kai Ole Hartwig: Und ich sage jetzt mal, die einzige Arbeit, die wir zum Beispiel haben, um ein neues Projekt aufzusetzen, ist,
Kai Ole Hartwig: 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
Daniel Langemann: Ja.
Kai Ole Hartwig: 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
Kai Ole Hartwig: Dann wird das ganze Graffel neu gebaut, wenn du dann natürlich sagst, hey, ich brauch's jetzt einmal neu, ne?
Daniel Langemann: Ja, klar.
Daniel Langemann: Ja.
Kai Ole Hartwig: Nicht so magisch, die Datei hat sich geändert und jetzt mach ich was.
Kai Ole Hartwig: Und ja, natürlich, wenn du die Abhängigkeiten in der falschen Reihenfolge updatest, dann bekommst du Probleme.
Kai Ole Hartwig: Kein Wunder, aber wenn du das in der richtigen Reihenfolge machst, dann steht das System halt mit der neuen PHP-Version da.
Kai Ole Hartwig: Mit den neuen Dependencies, die für die neue PHP-Version sind.
Kai Ole Hartwig: Die Versionen sind da und alles ist fein.
Kai Ole Hartwig: So, und okay, dieses Dependency-Update dauert halt, weil, hatten wir mal besprochen, läuft über die Pipeline bei uns.
Daniel Langemann: Ja.
Kai Ole Hartwig: Aber du baust, dann gibt es halt den neuen Container und dann wird das halt gebaut, gezogen, dann dauert das halt eine Zeit.
Kai Ole Hartwig: Das ist eher etwas, was man abends starten sollte, damit es über Nacht dann quasi fertig läuft.
Kai Ole Hartwig: Und am nächsten Morgen hast du das da stehen und kannst weitermachen.
Kai Ole Hartwig: Oder hast ganz viele rote Pipelines, die sagen, nee, Junge, jetzt hast du aber hier Mist gemacht.
Kai Ole Hartwig: Ja, so.
Daniel Langemann: Dann machst du einen Laptop, den du da zugehörst und nimmst frei.
Daniel Langemann: 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.
Kai Ole Hartwig: Mhm.
Daniel Langemann: 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.
Daniel Langemann: Und das musste halt irgendwie funktionieren.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Deswegen war...
Daniel Langemann: 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.
Daniel Langemann: Wenn ich Sachen ändere, kann ich das im Feature-Branch pushen.
Daniel Langemann: 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.
Daniel Langemann: 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.
Daniel Langemann: Also bei euch ist
Kai Ole Hartwig: 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.
Daniel Langemann: Ich bringe mal meine Dependency mit und mache mich unaustauschbar.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Naja, mal drüber nachdenken.
Kai Ole Hartwig: Aber, ähm,
Kai Ole Hartwig: Natürlich, wenn du ständig in neue Projekte reinkommst, dann veränderst du nicht einfach alles und die ganze Welt.
Kai Ole Hartwig: Anderer Anwendungsfall, wenn ich in externe Projekte reinkomme, dann habe ich das auch nicht.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und da ich irgendwie sehr viel Zeit mit diesem Zeug zubringe jeden Tag, und das ist mehr Zeit, als ich in meinem Wohnzimmer sitze,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich habe auch mal drüber nachgedacht, oder was wir auch machen, ist, wir arbeiten mit Devcontainers, das ist auch so ein Standard,
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: Das heißt, ich kann halt ein Entwicklungssystem in einem Cluster,
Kai Ole Hartwig: gesonderten Entwicklungskluster starten, ganz normal entwickeln und arbeiten und mein Zeugs machen, ohne dass ich das lokal auf dem Rechner brauche.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Oder die Variante mit, irgendwie bricht meine Verbindung ständig beim Download aus der Registry ab.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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,
Daniel Langemann: Ich mache schöner Wohnen in deinem Wohnzimmer.
Daniel Langemann: Aber ich bin auch der Raumausstatter, den du gekauft hast, damit es hübsch aussieht, ne?
Daniel Langemann: Hm.
Kai Ole Hartwig: Und genauso, wenn ich natürlich irgendwo reinkomme in ein Projekt, dann gehe ich da ja auch anders vor.
Kai Ole Hartwig: Dann sage ich jetzt nicht so, wir updaten jetzt alles auf das und das ist der einzige Weg, der existiert.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
Daniel Langemann: Der passt sich dem Gastgeber an.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und gestalte es um.
Kai Ole Hartwig: 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.
Daniel Langemann: 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.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, ja.
Daniel Langemann: Hm.
Kai Ole Hartwig: Dann komme ich ja nicht hin und sage, na, du brauchst andere Vorhänge.
Kai Ole Hartwig: 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?
Daniel Langemann: 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
Kai Ole Hartwig: Also, oder
Kai Ole Hartwig: ja, da hinkt jetzt das Wohnzimmer, da wäre eine Party-Location besser, aber du verstehst, was ich meine, ne?
Kai Ole Hartwig: So.
Daniel Langemann: die Sachen drin landen, wo mit Docker Compose werden Docker Container gestartet.
Kai Ole Hartwig: Ja.
Daniel Langemann: 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
Daniel Langemann: mit PHP alles Mögliche machen.
Daniel Langemann: Du kannst genauso in den Node-Container oder in den Postgres-Container reingehen und da auf der Konsole Sachen machen.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, und ich muss ja auch ein bisschen noch enttäuschen, ne, also wir setzen keine Dockerfiles mehr ein, sondern Containerfiles.
Daniel Langemann: Also zwar nicht per SSH, aber...
Daniel Langemann: 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.
Daniel Langemann: Und das macht es schon sehr angenehm.
Daniel Langemann: Angeber.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Kein Docker-Compose, sondern bei uns ist es tatsächlich Portman, auf das wir migrat haben.
Kai Ole Hartwig: So, ähm,
Daniel Langemann: Wäre mal wieder ein neues Thema.
Daniel Langemann: Warum?
Kai Ole Hartwig: Neues Thema, ja.
Kai Ole Hartwig: Für die nächste Woche oder so.
Daniel Langemann: Ja.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Passt das?
Kai Ole Hartwig: Haben wir alles gesagt oder möchten wir noch was sagen?
Kai Ole Hartwig: Wir können doch noch weiter reden.
Kai Ole Hartwig: Ich glaube, wir haben jetzt ja aus unterschiedlichen Richtungen sind wir gekommen.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: 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
Daniel Langemann: Ja.
Kai Ole Hartwig: geht alles.
Kai Ole Hartwig: Du verlierst halt durch diese Paketierung, die wir haben, nie die Möglichkeit, individuell zu sein.
Kai Ole Hartwig: Es ist halt...
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Daniel Langemann: Nicht immer die gleichen Fehler lösen.
Kai Ole Hartwig: 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
Kai Ole Hartwig: 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?
Kai Ole Hartwig: Oh, verdammt.
Daniel Langemann: Machen wir wieder Cliffhanger diesmal.
Daniel Langemann: Ich weiß es nicht, wo du hin wolltest.
Daniel Langemann: Überschreibbarkeit.
Kai Ole Hartwig: Ja, ja.
Kai Ole Hartwig: Ja, Standardisierbarkeit, immer das Gleiche.
Kai Ole Hartwig: Und... Ach genau, du bist halt trotz dieser Standardisierung
Kai Ole Hartwig: jederzeit in der Lage, individuell zu arbeiten.
Kai Ole Hartwig: Aber mit diesem Standardisieren sparen wir uns im Prinzip sehr, sehr viel Zeit im täglichen Arbeiten.
Kai Ole Hartwig: 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.
Daniel Langemann: 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.
Daniel Langemann: Du kannst aus diesem Dev-Setup bei uns beiden direkt Container fürs Produktivsystem bauen, die gleich sind.
Daniel Langemann: Und wenn du solche Unterschiede nicht hast, spart dir das viel Lebenszeit bei Fehlersuche später.
Kai Ole Hartwig: Ja, wobei die Pipeline ja die Containerarbeit, aber du hast halt deinen... Ja, genau.
Daniel Langemann: Ja, aber zumindest bei mir ist es die Docker-File, die in diesem Ordner liegt.
Daniel Langemann: Das Basis-Image ist sozusagen das Produktiv-Image.
Daniel Langemann: Dahinter kommen dann die Dev-Setup-Sachen nochmal rein.
Daniel Langemann: Also hier, ne?
Kai Ole Hartwig: Ja, ich wollte nur betonen, dass du ja nicht lokal das Produktiv-Image baust, sondern das baut ja die Pipeline.
Daniel Langemann: Nein, okay.
Daniel Langemann: Ja, du hast natürlich recht, das mache ich nicht.
Daniel Langemann: Das wäre ja dumm.
Kai Ole Hartwig: das ist ja nicht unbedingt dumm, aber keine gute Idee.
Daniel Langemann: Ja, also definitiv machen wir das nicht.
Kai Ole Hartwig: 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.
Daniel Langemann: Bitbox on my machine.
Daniel Langemann: Hm.
Daniel Langemann: Ah, nee.
Kai Ole Hartwig: 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.
Daniel Langemann: 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.
Daniel Langemann: Und das ist halt so nebenbei auch angenehm, einfach in der Pipeline dann keine Secrets mehr zu brauchen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Nicht nur in der Pipeline, auch lokal, ne?
Kai Ole Hartwig: Du kennst ja mal ein Kilo.
Kai Ole Hartwig: Das, was ich nicht weiß, kann ich nicht vergessen.
Kai Ole Hartwig: Zumindest was Secrets angeht.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und, ähm, tatsächlich ist es ganz nice, das alles nicht zu wissen.
Kai Ole Hartwig: Die Systeme wissen es, die managen das.
Kai Ole Hartwig: Ähm, ich hab's nicht irgendwo im Passwortmanager bestes Leben.
Kai Ole Hartwig: Also, ich liebe es.
Daniel Langemann: Und Dev-Setups sind einfach, die sparen dir viel Lebenszeit, viel Ärger, gerade auch oft, wenn irgendwas kaputt ist.
Kai Ole Hartwig: Und,
Daniel Langemann: Also du bist am Entwickeln und sagst, komisch, das hat da vorhin funktioniert, warum ist das jetzt so?
Daniel Langemann: Einmal kurz neu gestartet, hast du wieder den Ursprungszustand und dann ist wieder der Fehler weg.
Daniel Langemann: Dann hast du irgendwas kaputt gemacht, wo du nicht aufgepasst hast.
Daniel Langemann: In der Datenbank datentechnisch, dann kannst du einfach weiterarbeiten.
Daniel Langemann: Und früher wäre das so irgendwie drei Stunden Fehlersuche gewesen, um zu merken, dass man dann
Daniel Langemann: etwas gemacht hat, was man vergessen hat.
Daniel Langemann: Deswegen, Dev-Setups sind super.
Kai Ole Hartwig: Genau.
Daniel Langemann: Also, sparen dir so viel Lebenszeit.
Daniel Langemann: Ja, gerne.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich glaube, es sind Seehunde bei Podman.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Nein, Wale sind sehr cool.
Kai Ole Hartwig: Aber zwei Wale sind vielleicht zu groß.
Kai Ole Hartwig: Wortwitz.
Kai Ole Hartwig: Kann ich.
Daniel Langemann: Ist schon Karneval.
Daniel Langemann: Ist schon Karneval oder was?
Kai Ole Hartwig: Hm?
Kai Ole Hartwig: Noch nicht ganz.
Kai Ole Hartwig: Aber dann sehen wir uns nächste Woche.
Kai Ole Hartwig: Und das tisern wir jetzt schon an.
Kai Ole Hartwig: Dann mit Docker versus Potman oder warum wir auf Potman sitzen.
Kai Ole Hartwig: Statt auf Docker.
Daniel Langemann: Ja, sehr interessant.
Daniel Langemann: Habe ich mich fünf Minuten vorher wieder schlau.
Kai Ole Hartwig: Bis dahin.
Kai Ole Hartwig: Macht's gut.
Daniel Langemann: Ciao.
Kai Ole Hartwig: Ciao.
