Secrets Not Included: Standardisierung & Entwicklungsumgebung

Hey Daniel, schön, dass du hier bist, unsere ersten Folge Secrets Not Included. Lass uns heute mal ganz locker ins Thema starten mit Standardisierung in unseren Projekt-Setups.

Ja, hi. Ja, gerne. Wir hatten uns das Thema ausgesucht und ich glaube, wir gehen unterschiedlich an die Sachen ran. Also, ich...

Ja, ich befürchte das auch. Ich bin ja so ein Mensch. Ich stehe unfassbar auf Standardisierung und auf, ich sage jetzt mal, sehr gleiche Setups.

Mhm.

Und bin da vielleicht auch ein wenig... sehr leidenschaftlich drin zu sagen, ein Setup fits all. Aber ja, erzähl mal, wie machst du das?

Das ist unterschiedlich und finde ich auch extrem schwer, weil je nach Kunden und Auftraggeber unterscheiden die Sachen sich. Und da habe ich einfach mein Problem, dass ich, also es gibt nicht diesen Moment, wo ich sage, ich habe eine Checkliste, die arbeite ich ab und sage, dieser Punkt, dieser Punkt, dieser Punkt, dieser Punkt. Sondern viele Sachen ergeben sich einfach aus dem bestehenden Setup oft. Also ich hatte bis jetzt nicht so oft den Luxus, dass man auf der grünen Wiese anfangen kann. Ich glaube, das ist der große Unterschied. Und wenn man viele bestehende Projekte sieht oder reinkommt, übernimmt, mitmacht, wie auch immer, dass dann einfach schon was Existierendes da ist. Und das muss man dann gucken, dass man das irgendwie adaptiert oder auf ein Level kriegt, mit dem man leben kann. Und da hat sich für mich einfach ergeben, dass... Also ich habe es nie geschafft, irgendwie so eine Checkliste zusammenzubauen oder... Man hat zwar immer so eine Idealvorstellung von einem Dev-Setup oder einer Entwicklungsumgebung, wie sie denn sein sollte und es ist aber extrem schwer, oder ich tue mich extrem schwer damit zu sagen, es gibt dieses eine Setup und wenn jemand kommt, schneide ich die Blöcke und das Ding ist fertig. Weil halt viel Altlasten oder oft Altlasten mitkommen bei Projekten.

historisch gewachsene Projekte, ne?

Ja.

Das ist natürlich auch eine eigene Kategorie, aber ich finde gerade so etwas wie die Dev-Setups lassen sich unfassbar gut heute standardisieren. Also ich sag jetzt mal, den PHP-Container, den hat man halt in Version ABC 8.2, 8.3, 8.4 irgendwie rumfliegen.

Mhm.

Und ja, okay, dann installiere ich halt im Zweifelsfall noch mal ein paar Module oder irgendwelche Special-Sachen da rein. Aber vom Grundsatz her habe ich erstmal das PHP da rumfliegen, das nehme ich wieder. Und genauso den Web-Server und alles, was so sonst in diesem Ecosystem rumfliegt. Und das versuche ich aber auch zunehmend. also gerade auch bei Projekten, die wir irgendwie übernehmen, dass wir quasi das, was vorhanden ist, gegebenenfalls gegen Versionen austauschen oder gegen Module austauschen, die wir immer wieder einsetzen.

Oh ja.

Dass man wirklich so eine Standardisierung da reinbringt und jetzt nicht sagt, also ich meine, ich habe schon verrückte Dinge gesehen, wo in einem CMS-Setup auf einmal das auf Symphonie-basierte, auf einmal Lagerwell komplett nochmal eingebunden wurde, um dann damit eine Aufgabe zu lösen. Solche Dinge, die total offensichtlich sind, also weißt du, da fällt es mir schwer zu sagen, ah, das ist historisch gewachsen, wir lassen das alles mal so. Ich finde, da sollte man ganz, ganz stark gegen eigene Best Practices gehen und nicht unbedingt mit der Checkliste, aber mit starken Standards, die man dann eventuell durch Konfigurationen abändern kann. Ich sage jetzt mal, du setzt eigentlich immer Graphic Magic ein für die Bildverarbeitung. Du kannst auch einstellen, in diesem Projekt läuft halt Image Magic, weil keine Ahnung, warum auch immer das da notwendig ist.

Mhm.

Das ist mehr so den Ansatz, den ich eigentlich verfolge bei uns, dass ich sage, okay, wir haben einen Standard und wir versuchen diesen Standard nicht sofort, aber nach und nach in die Projekte immer wieder reinzubringen, damit wir auch so etwas machen können, wie halt unsere standardisierten Tests zu verwenden, unsere Container und Setups komplett auszuschöpfen und halt wirklich Synergieeffekte auch zu haben, dass wir nicht in jedem Projekt für jeden Kunden alles neu bauen. Na, ich sag jetzt mal,

Ja.

Es gibt ja in jedem Projekt die gleichen Dinge. Das werden jetzt in deinen E-Commerce-Projekten ein bisschen anders sein als in meinen CMS-Projekten. Aber ich sage jetzt mal, so ein Slider, irgendwelche Pop-Ups, die aufgehen, diese ganzen Störer, die kommen immer wieder vor. Ja klar, bei dem einen slidet es schneller, beim anderen sind fünf statt vier... Die Pfeile sind ein bisschen woanders, sehen mal anders aus. Aber vom Grundsatz her ist das ja von dem Code, der da ausgeführt wird, für die Datenbank, fürs PHP, aber auch fürs JavaScript, ist das ja standardisierbar. Das kann ich ja immer wieder verwenden.

Ja, also ich glaube, wir können festhalten, dass Docker quasi Standard ist, zumindest aus unserer Sicht.

Und dann, wenn ich halt irgendwo einen Fehler drin habe, wenn ich das entsprechend gekapselt habe als Programm, und dann kann ich das per Composer oder irgendeinem anderen Paketmanager ja entsprechend verteilen und updaten.

Ich erlebe viele Projekte, wo das nicht so ist und wo mir immer wieder auffällt, dass es gewisse Standards gibt, die man einfach erwartet oder wo man gar nicht mehr damit rechnet, dass Leute zum Beispiel mit dem PHP internen Dev-Server irgendwie entwickeln auf ihrer lokalen Kiste. Also ich glaube schon... Echt?

Ich glaube, gerade dieser PHP-interne Dev-Server kommt jetzt vermehrt, ist mein Eindruck. Dadurch, dass immer mehr Projekte das nativ unterstützen, Symfony jetzt zum Beispiel auch, oder auch Franken-PHP, glaube ich, ja auch in einer gewissen Form, dass du das direkt starten kannst,

Hm... Ja. Mhm.

glaube ich, wird das mehr kommen. Ich glaube, oder mein Bauchgefühl ist auch, je nach Projekt ist das auch okay. Ja, wenn das ein kleines Projekt ist und man vielleicht auch nicht die Erfahrung mit Containerisierung hat, dann ist es ja in Ordnung, eine andere Lösung zu verwenden.

Also, aber ich glaube, das ist genau das Thema, was interessant wird, wo wir über Standardisierung reden oder was ich zwar nicht mit einer Checkliste abarbeite, aber für mich ist das so, spätestens wenn ich ins Projekt dazukomme oder eine zweite Person dazukommt und man zum Beispiel einen Datenbank-Dump jemand anderes irgendwie schicken muss, damit der auch eine Entwicklungsumgebung aufbauen kann, oder irgendwelche besonderen Config-Variablen oder Secrets hin- und herschicken muss, damit Sachen funktionieren. Ich glaube, dann ist Standardisierung und Dockerisierung oder Containerisierung, ich will jetzt nicht nur Docker nennen, also gibt ja mehr.

Ja.

Ich glaube, dann spielt das viele Vorteile aus, an die man sich als Entwickler eigentlich unbewusst gewöhnt hat und schon vergessen hat, wie die Schmerzen sind, wenn man es nicht hat. Also das Übliche ist ja mit, ich habe heute was gemacht, habe ein Projekt, alles läuft, das Ding, Setup läuft und in einem halben Jahr will ich das nochmal starten. Was ich vergessen habe zwischendurch ist, dass ich mal den Rechner gewechselt habe, eine andere PHP-Version läuft oder Node.js oder was auch immer, eine andere Version läuft, irgendwelche Config habe ich geändert, hinzu installiert, weg installiert und auf einmal läuft mein Projekt nicht mehr. Und das ist ja das, was mich dann so tierisch nervt immer, dass man eigentlich gerade Zeit hätte, etwas zu machen und aber dann wieder zwei Stunden mit Debugging verbringt, um rauszufinden, ach stimmt, die PHP-Version passt nicht oder Node.js passt nicht. Gerade bei Node und JavaScript ist es ja ein bisschen anfälliger, was NPM und Versionen betrifft, welche Packages in welcher Version zusammen installiert wurden. Und das abstrahiere ich gerne mit Docker-Containern weg, dass man das im Projekt hat und dann

Ja, definitiv.

Deswegen, also wenn die Projekte starten, zum Starten jetzt gerade mit Vibe-Coding und allem, glaube ich, ist das ein perfekter Start, dass irgendwas lokal läuft und dass man etwas laufend hat, aber das hält nicht lange oder macht nicht lange Spaß. Ich glaube, es wird nicht lange Spaß machen, das so zu haben.

Ja, ich denke, wenn man über ein Proof of Concept hinausgeht, dann sollte man über ein besseres Setup nachdenken oder ein standardisiertes Setup. Das muss ja nicht besser sein, zu sagen, man nimmt jetzt einen Container.

Hm. Hm.

Also ich gehe mittlerweile sogar hin und habe auf meinem Rechner selber gar keinen MPM und kein PHP mehr installiert, weil ich alles immer über die Container laufen lasse. In der Annahme dass das da dann immer gleich sein wird und immer laufen wird.

Ja.

Bisher fahre ich auch wirklich gut damit. Also das ist jetzt nicht, wo ich sage, uh, jetzt muss ich hier aber den Container wieder anpassen und so. Also das läuft sauberer und besser, als wenn man jetzt irgendwie die Entwicklungsumgebung so direkt auf dem... auf dem Mac startet in irgendeiner Art und Weise und sagt, ah ja, jetzt habe ich hier das PHP und fange ich ein anderes Projekt an und dann ach, ich muss kurz das PHP ändern. Ja, ist ja auch kein Thema mit Homebrew, schnell umgestellt, aber das ist ja auch immer, man muss sich da erinnern. Klar, man kann sich das wieder wegskripten. Ja, ich wechsle das Projekt in meiner Asile-Eye und dann fängt das an, die Sachen zu machen. Nicht, dass ich die Idee nicht auch schon hatte und auch mal so laufen hatte, aber es fühlt sich mittlerweile irgendwie falsch an, das zu machen.

Und das ist ja nur der Anfang. Dann kommt als nächster Schritt, du hast eine Datenbank. MariaDB, was auch immer, die du starten willst. Du brauchst Daten da drin. Symfony und andere Frameworks bringen ganz schöne Fixture-Bibliotheken mit, wo du sagen kannst, wenn ich das Projekt starte, fülle mir mal die Datenbank mit meinen Demodaten. Damit, wenn ich morgens starte, immer das System im Status quo dasteht und dann auch Testing funktioniert. Wenn ich jetzt irgendwie lokal mir was zusammengebaut habe, Ich habe gerade ein bisschen im Admin-Bereich rumgeklickt, irgendwas gelöscht. Ja, das war meine Demo-Brand, wo meine End-to-End-Tests drauflaufen. Die Tests failen. Warum failen die? Die bugge ich wieder, finde raus, dass ich mir selber ein Bein gestellt habe, muss dann gucken, dass ich die Demo-Brand wieder zurückklicke, damit die wieder da ist oder einen SQL-Dump einspielen und dann verliere ich Zeit. Und das ist halt, oder das finde ich bei Docker-Containern angenehm, wenn du damit anfängst, Der erste Schritt ist ja erstmal nur wirklich PHP-Version. Der nächste Schritt, dann hast du eine Datenbank, die du abstrahiert hast in der richtigen Version. Die kommunizieren untereinander. Du hast schon Umgebungsvariablen, so ein bisschen ähnlicher wie auf dem Produktivsystem. Also ich will nicht sagen gleich, aber ähnlicher wie auf dem Produktivsystem, weil vielleicht auch die Datenbank irgendwo anders liegt. Das nächste Thema sind E-Mails. Ja, mit Docker hast du ganz schnell einen Mailcatcher installiert, wo alle E-Mails drin landen. Da kannst du E-Mails testen oder zumindest mal als Mensch auch gucken, was da passiert. Dann AWS und Hyperscaler kommen wir auch nicht drum rum. Mit LocalStack kannst du sowas sogar lokal abstrahieren. Oder, weiß ich nicht, eine andere Message Queue lokal installiert. Und dann schon bist du bei einem Stack, der richtig groß wird und das Ganze irgendwie dann organisiert werden muss.

Ja, du hast das Caching noch völlig außen vor gelassen. Ja, dann...

Ja, genau, caching auch noch. Redis. Hm. Hm.

Redis, vielleicht dann auch noch ein Varnish oder ähnliches als Fullpage Cache davor. So, und dann kommst du ja ganz schnell in den Bereich, wo du auch sagst, ah, vielleicht kommen ja auch Konfigurationen oder Informationen noch aus anderen Teams. Ja, auf einmal hast du so einen Varnish, der dann irgendwie von drei Teams bespielt wird, die da irgendwie wild Konfigurationen reinschreiben. hoffentlich nicht ganz so wild, sondern natürlich über Git versioniert und vernünftig deployed mit GitOps und so weiter und so fort.

Ja.

Aber da kommt ja schnell Komplexität zusammen, gerade in größeren Projekten, wo man halt sagen muss, okay, wir müssen dafür sorgen, damit jeder auch zügig arbeiten kann und das jeden Tag und nicht nur einmal im Monat oder so, dass dieser lokalen Entwicklungsumgebungen, die DEF-Umgebungen so schnell aufzusetzen sind und so schnell jeden Morgen wieder laufen, dass man auch gar nicht merkt, dass man das jetzt irgendwie macht. Also ich sage jetzt mal, man sagt meinetwegen Make Start oder so, wenn man das per Make File machen will oder DDEV oder wie auch immer.

schuldig. Ja.

Es gibt ja eine Million Möglichkeiten, das zu standardisieren. Da muss man sich ja auch einfach für einen Weg entscheiden. Ich bin jetzt auch großer Fan von Make Files, die dann einfach... Oder was es einfach, die halt die Möglichkeit geben, dass auch jemand, der sich gut auskennt mit diesen Setups, das vorbereitet und ein Entwickler, der jetzt nicht so in diesen Themen drin ist, sondern nur entwickelt. halt auch sagen kann, okay, ich habe hier schnell meine Entwicklungsumgebung und ich habe nicht jetzt diese Confluence-Seite, wo ich eine Stunde durchscrolle, bevor ich am Ende bin und wo ich x Schritte machen muss und dann steht auch noch drin, naja, aber manchmal musst du auch das machen oder dieses und dann fehlt trotzdem immer noch was, weil jemand hat noch eine Umgebungsvariable hinzugefügt und

Mhm.

das steht nirgendwo, das wurde vergessen zu dokumentieren und dann läuft das Projekt nicht. Und das sind ja diese ganzen Sachen. Ganz spannend finde ich auch eigentlich Secret Management für die lokalen Entwicklungsumgebungen. Ich habe ja in letzter Zeit einen sehr radikalen Ansatz gefahren und tatsächlich, soweit es geht, alle Passwörter irgendwie eliminiert und quasi dynamisch neu gesetzt.

Mhm. Mhm.

Weiß ich nicht. Du startest deine Entwicklungsumgebung und dann sagt er, ja, hey, ich habe dir einen Admin-Account angelegt für dich lokal und das ist dein Passwort.

Ah, okay, also dass du das beim Setup theoretisch setzt.

Genau, so und halt auch sehr mit dem Ziel, in den Produktivsystemen gar nicht mehr hohe Berechtigungen vergeben zu müssen. Das ist jetzt, also sprich, dass auf einem Produktivsystem es gar keinen Admin mehr gibt.

Ja. Ja.

Im CMS-Bereich bestimmt eine ganze Ecke leichter als im Shop-Bereich. Aber mit dem Gedanken, wir versionieren eh alle Konfigurationen vollständig. Das heißt, es sollte niemanden geben, der in einem Produktivsystem diese Berechtigung benötigt, etwas an diesen Einstellungen, die wir versioniert deployen, zu ändern.

Ja.

Wenn das nämlich notwendig ist, dann ist ja davor irgendwas schiefgegangen. Klar, für den Notfall, wenn alles brennt, muss man irgendwie die Möglichkeit haben, also ein Backup für den Prozess, dass man das machen kann. Ohne Frage. Aber im Normalbetrieb sollte es eigentlich nicht notwendig sein, dass jemand daran geht, diese Konfigurationen anpassen kann oder verändert. Ganz spannend finde ich auch persönlich für den Betrieb nachher, jetzt gehen wir gerade von der Standardisierung ein bisschen weg, aber von der Idee her, Read-Only-Filesysteme zu haben in den Containern. Ja, dass nur noch bestimmte Verzeichnisse, wo es notwendig ist, darauf beschrieben werden kann und alles andere ist nicht veränderbar.

Temp und war. Ja.

Ja, das wird einmal im Bildprozess gebaut, in den Container gepackt, signiert, dass es von dort kommt, dass alles in der Version getestet ist, ausgespielt, validiert, dass es auch wirklich die Version ist und dann hast du quasi nur noch den User-Generated-Content, vielleicht sind es aber auch deine Redakteure, die die User sind, die dann Daten verändern im Sinne von Inhalten, Bilder hochladen, Texte einstellen. Genau, sowieso.

Aber das sind ja Sachen, die landen dann entweder in einem S3-Bucket, NFS-Storage, also außerhalb von dem Container. Egal, was du machst, ob es jetzt AWS oder Kubernetes, würdest du das ja auch nicht irgendwo in den Container mit schreiben. Also da hast du dann auch ein Storage irgendwo.

Also nicht, wenn du nicht völlig verrückt bist und bei eben die Promit auf einmal Daten verlierst.

Ja. Ja.

Ich glaube, das haben auch schon Menschen bestimmt gemacht. Die Idee gehabt, ah ja, ich habe hier den Docker-Container und das ist ja quasi wie ein normaler Server und jetzt behandle ich den so und dann deploy ich das wieder, ist ja auch egal, wo rein, Und dann ist dieses Volume weg auf einmal und dann stehst du da und alle Daten sind weg. Ja, doof. Alle Bilder weg.

Chef, wir haben ein Problem. Ja.

Also das Marketing, das hat alle Bilder gelöscht.

genau die anderen was, das ist immer gut, ja. Mhm.

Ja, natürlich waren es die anderen. Das waren nie, nie, nie die Entwickler und natürlich auch nie Ops und auch nie, egal wer dran war, es war nie jemand.

Technik. Ja. Ja, aber zumindest, das heißt, du organisierst deine Secrets wie? Oder beziehungsweise worüber? Wie kommen die in den Container rein?

Ready?

Ich habe jetzt zum Beispiel auch wieder letztens in einem Gespräch mitbekommen, das sind auch wieder so Themen, wo ich sage, Secrets im Container, ich bekenne mich schuldig für die Dev-Umgebung, weil ich einfach zu faul bin, da irgendwie noch einen Secrets Manager in eine Dev-Umgebung mit einzubauen und sage so, komm, die haben keine Relation zum Produktivsystem. Ich habe keine Secrets, die irgendwie relevant sind, also von keinem externen System. Alles, was ich lokal habe, ist das Passwort von der lokalen Datenbank. keine Ahnung, ein Hash oder ein Seed für einen JWT-Token, der lokal ist, der nie deployed wird, das ist okay für mich. Aber was ich gehört habe, ist, dass Leute auch in Docker-Container, die die sozusagen in die Registry später pushen, ihre Secrets drin stehen haben für extern. Mhm.

Ja, es ist verrückt, ne? Also, es gibt das, ich weiß das. Ich gehe da sehr anders ran, also ich bin ein Freund davon, die grundsätzlich nur zur Laufzeit zu haben.

Ja. Also.

Für lokale Entwicklungsumgebungen haben wir die tatsächlich verschlüsselt im Git-Versioniert. Also bedeutet aber auch nur, der Entwickler, deren Key, deren Public Key auch hinterlegt ist, kann die auch entschlüsseln. Und wir reichen die dann zur Laufzeit rein. Also... Ja...

Also ähnlich wie Symphony Secrets gibt es ja auch mittlerweile als Bundle. Also gibt es tausend Lösungen, das ist die, die mir jetzt gerade einfällt.

Es gibt tausend Lösungen. Ich müsste jetzt nachschauen, wie unsere heißt. Das ist aber auch eine Standardlösung. Da ist nichts Wildes, Selbstgebautes. Und in Produktivumgebungen bin ich eigentlich ein großer Fan, auch via Sidecars über ein Vote oder so die Secrets reinzugeben.

Das ist auch interessant, ja.

Muss man natürlich auch schauen, je nachdem, wie groß oder klein das Setup ist. muss man sagen, finde ich, bevor man jetzt ein Boot betreibt, ohne dass man das woanders benutzt, dann vielleicht doch lieber über Verschlüsselung und dann wird es zur Laufzeit entschlüsselt oder so. Das zu regeln.

Mhm.

Ja, auf jeden Fall erstmal nicht in den Container rein und nicht schreiben, sondern eigentlich in der jeweiligen Umgebung von außen reingeben und

Genau, weil die Container eigentlich nur als Grundstruktur funktionieren sollten und nicht für eine spezielle Umgebung gebaut werden sollten.

Ja, ja.

Das ist auch so ein Grundkonzept, was ich oft gesehen habe, dass ein Container für eine Stage-Umgebung gebaut wird und dann wird ein neuer für eine Produktiv-Umgebung gebaut, der aber ja dann komplett anders sein kann. Und gerade dieser Gedanke mit, ich kann den gebauten Container überall hinschmeißen, ist ja dann der Schöne, dass man sagt, ich habe das schon getestet und so funktionieren die Abhängigkeiten untereinander.

Genau, ich halte es für völligen Unfug eigentlich, hinzugehen zu sagen, ich baue jetzt die Version und ich sage jetzt, okay, das ist Version X Test. Ich spiele die auf Test aus, da wird die getestet. Und dann gehe ich hin und baue wieder neu. Weil eigentlich veränderst du ja im Zweifelsfall das, vielleicht nicht unbedingt den PHP-Code, den du reingeschmissen hast, aber vielleicht die Nginx-Version oder Libc oder irgendetwas anderes wird zu dem Zeitpunkt dann neu gezogen, weil es ein Update gab und dann ändert sich auf einmal die Ausführung oder das Ergebnis, was nachher ausgespielt wird. Also eigentlich ist es

einfach fehlende Schreibrechte für irgendeinen Ordner, der nachträglich auf einmal benötigt wird.

Ja, irgendwelche dummen Dinge passieren dann ja.

Fliegt dir alles um die Ohren.

Nicht jedes Mal, aber irgendwann dann, wenn man es nicht gebrauchen kann. Ja, letztes Deployment vor Weihnachten, 16 Uhr, Weihnachtsfeier startet quasi.

Ja, ja, genau.

Wackfix musst du unbedingt raus. Man baut das neu und dann passiert irgendwas. So. Oder freitags, nachmittags oder whatever. Es ist ja immer so, dass solche Seiteneffekte dann auftreten, wenn man die eigentlich unter gar keinen Umständen gerade gebrauchen kann.

Wenn es richtig weh tut, wenn es richtig weh tut, ja.

Dann geht was kaputt, dann muss sich da jemand hinsetzen, das wieder alles fixen.

Hm.

Und deswegen halte ich die Idee, immer wieder diese Container neu zu bauen, für grundlegend falsch. Eigentlich, wenn man einmal die Testversion gebaut hat, dann schreibt man halt nur einen neuen Tag an die jeweilige Version ran und sagt jetzt, hey, ja, okay, das war meine Testversion, das ist jetzt meine Beta-Version, das ist meine Stable-Version, go for it. Aber halt nicht zu sagen, ah, jetzt hat sich was verändert. Es würde ja auch niemand hingehen und sagen, na, das Composer-Log-File hat sich zwar verändert, Aber ich schreibe jetzt trotzdem einfach dran, dass das die Stable-Version ist, auch wenn das in der Zusammensetzung gar nicht getestet wurde.

Ja.

Und ich finde auch den, also ich weiß, wie Teams da hinkommen. Ich habe auch schon von Unternehmen gehört, die in ihrem Deployment halt wirklich ihre Composer JSON deployed haben und dann auf jedem System ganz klassische V-Hosts Composer Update gesagt haben. So, dass das schief geht, da sollte man eigentlich direkt drauf kommen, aber manchmal ist man ja betriebsblind und dann muss jemand von außen kommen und sagen, das ist gar keine schlaue Idee gewesen.

Ich glaube einfach, dass wir nur schneller waren.

Ich finde,

Wir haben schon als Erste ins Klo gegriffen. Also jedem ist das doch mal passiert. Jeder hat da schon richtig mal so ein Produktivsystem abgeschossen und Fehler gemacht, von denen wir gerade erzählen, die sich so in unser Gedächtnis eingebrannt haben, dass wir schon fast panisch darauf reagieren, das nochmal zu machen. Meine Analogie ist immer so die Herdplatte. Als Kind packst du einmal drauf, verbrennst dir so richtig die Finger. Und spätestens, wenn du dann fünf Jahre später nochmal die Herdplatte siehst, weißt direkt, heiß, aua, mache ich nicht nochmal. Und dann passieren die Sachen, dass wir jetzt sagen, guck mal, sowas macht man gar nicht, aber nur, weil wir den Fehler schon mindestens einmal gemacht haben.

Ja gut, wer hat noch nie ein Produktivsystem abgeschossen?

Und ich glaube, viele, die das machen, denen ist das noch nicht passiert.

Also, genau.

Ja, ja, die Bauchschmerzen dabei.

Das ist natürlich, Lernen durch Schmerzen ist sehr effektiv an der Stelle, stimme ich dir absolut zu.

Ja.

Aber ich glaube auch, wenn man einmal so Grundkonzepte verstanden hat, wie laufen saubere Update-Prozesse, dann kannst du das ja abstrahieren und weißt, wenn ich das im PHP nicht mache, dann mache ich das doch auch nicht für ganze Container. Also, an manchen Tagen halte ich mich für so schlau, dass ich glaube, dass ich das hinbekomme, Fehler nicht häufiger zu machen. An Tagen ohne ausreichend Koffeinzufuhr möchte ich das aber nicht garantieren. So,

Ja, ja. Und genau dafür sind dann Automatisierungen perfekt, die uns davon abhalten, dumme Fehler nochmal zu machen.

Ja, genau. Deswegen baut man ja zum Beispiel Pipelines einmal oder baut auch weiter aus iterativ und sagt, ah ja, wir haben festgestellt, dann treten so komische Fehler auf und dann ist es keine schlaue Idee, das zu machen.

Mhm.

Wir hatten zum Beispiel in einem Projekt mal einen ganz komischen Fehler. Wir haben... zusätzliche Libraries installiert und auch deinstalliert wieder. Also sprich rausgenommen im Sinne von, wir haben das aus der Zeile, aus dem Docker-File rausgenommen. Aber der Build-Prozess war cached. Und dann war quasi dieser alte Layer, wo es drin war, in der Version war noch vorhanden. Und hat dann natürlich weiter die Fehler geschmissen.

Das Übliche.

So, total...

It works on my machine. Scheiße.

Genau, so, du hast das lokal gebaut, hast gesehen, ja, der Container ist voll super, hast das in der Pipeline gebaut und der Container war scheiße.

Ja, ja, ja, genau.

Das sind natürlich so Learnings, da kommt man dann dazu, deswegen auch iterativ, so eine Pipeline ist, glaube ich, nie fertig.

Bis jetzt.

weil es gibt immer mal wieder Dinge, an die muss man ran, die verändert man, da stellt man nachher fast, der Weg, den wir hier gegangen sind, der funktioniert zwar für uns, aber ein anderer Weg ist viel schneller. Das ist ja auch so eine Erkenntnis manchmal in Standardisierung, dass man auch mit PHP-Libraries, die man selber baut und Modulen, dass man immer mal wieder ein Projekt hat, wo man feststellt, der Algorithmus, den ich da gebaut habe, der funktioniert zwar super, aber hier in dem Projekt habe ich jetzt viel mehr Traffic und jetzt geht es auf einmal kaputt.

Ja. Ja.

Und dann verbessert man den und dadurch, dass man das da verbessert, kann man das dann, wenn man das schön in ein allgemeines Paket gepackt hat, kann man damit automatisch alle anderen Projekte auch verbessern. Und stellt dann fest, naja, schau mal, jetzt... jetzt ballern wir einfach tausend Datensätze in einer Sekunde dadurch. Ja, oder meinetwegen auch in einer Minute, weil die XML ist groß und mehr oder Gigabyte Stream ist immer ein bisschen ätzend. So Sachen kann man dann ja super machen. Und ich finde, deswegen mag ich nicht dieses zu sagen, oder generell hinzugehen und zu sagen, ja, wir machen alles immer wieder individuell, weil ich finde, hinzugehen und zu sagen, wir machen alles immer wieder individuell für ein Projekt, für einen Kunden, bedeutet nur, ich muss jedes Mal wieder aufs Knie fallen, jedes Mal den gleichen Fehler machen, um dann das hinzukommen, weil irgendjemand erinnert sich ja nicht daran, dass ich gesagt habe, ich habe den Algorithmus mir aus dem Projekt herkopiert, jetzt habe ich den da verbessert, jetzt kopiere ich den auch ins andere Projekt, aber dann müsste ich da ja auch wieder komplett neu testen und vielleicht habe ich gar keine Testcases dafür geschrieben und ich weiß gar nicht, ob das in dem Projekt auch dann alles noch funktioniert. Also ich finde, Individualität ist an manchen Stellen einfach auch gefährlich.

Ja, es ist schwer. Also es ist schwer, dass

Also das hält ja niemanden davon ab, ein anderes Design zu haben. Oder auch andere Funktionen einzubauen, die kann man ja trotzdem standardisieren, in Pakete reinpacken und da sauber verwalten, versionieren, mit Tests ausstatten.

Um nochmal bei dem Beispiel zu bleiben, was wir am Anfang hatten, also Docker und das Dev-Setup. Also ich habe mir auch, ich glaube, jeder hat das, also nicht nur ich, sondern alle haben irgendwie so ihr Dev-Setup, mit dem die gut funktionieren und arbeiten und was die so von Projekt zu Projekt mitnehmen oder eine Idee, wie ein Dev-Setup aussehen sollte. Und das habe ich auch. Also bei mir sind das auch so Unterordner, die Funktionalität enthalten, Makefiles, die halt die Unterordner einbinden. Und da kann man generalisieren, genau wie du sagst, mit zum Beispiel einem PHP-Container kommt damit, ein Nginx-Container kommt damit, eine Datenbank, Mailcatcher, das geht. Und die Spezialisierung ist natürlich immer das Problem, was dann dagegen steht. Und das ist auch so ein bisschen, wo ich dann immer am kämpfen oder am überlegen bin, ist, mit einerseits kann ich das Dev-Setup mitbringen, aber bis jetzt war jedes Projekt so, dass ich das anpassen musste, weil entweder auf anderen Ports irgendwas gemacht wurde, weil PHP-Erweiterungen benötigt wurden, Image Magic, irgendwas, wo du dann sagst, das ist der Teil, den man individuell bauen muss und wo ich mich dann auch immer schwer tue und sage so, jedes Projekt ist gleich und ich nehme das mit, packe das da rein, fertig.

Ja.

Und ich, also das war so der Grund meiner Aussage, dass, also grundlegend, es gibt Sachen, die so wiederholen sich immer und es wäre doof, das Rad immer neu zu erfinden oder jedes Mal Make neu zu schreiben und zu erfinden. Also nicht, dass man das nicht schon versucht hätte, aber kann ich nur sagen, ist eine dumme Idee. Mhm.

Ich gehe ja mittlerweile hin, ich kopiere ein Make-File immer in mein Projekt rein und das sorgt dafür, dass ein anderes Make-File über Composer, also ich kopiere ein Makefile rein und ein PHP-Paket via Composer, wo ein allgemeines Makefile drin liegt, das ich dann darüber einbinde, über das Projekt Makefile. Und dann kann ich natürlich in dem Projekt Makefile beliebig überschreiben und verändern. Ich arbeite halt auch in den Makefiles mit Variablen, dass ich das anpassen kann. Also sprich an Stellen, wo ich festgestellt habe, da brauchen wir Flexibilität, da habe ich das natürlich auch konfigurierbar gemacht am Tagesende über Variablen oder allgemein, dass man Funktionen austauschen kann über eine Fluid API für Konfigurationen oder so. Und bisher funktioniert das nicht, Sehr gut. Ich möchte nicht sagen, dass das immer funktioniert für jedes Projekt, aber für das, was wir gerade so tun, funktioniert das hervorragend. Aber es ist natürlich auch schwierig, also es kommt auch auf die Projektgröße an. Wenn du natürlich quasi den einen Service alleine verantwortest und den verändern kannst, wie du möchtest, also alleine vielleicht auch im Sinne von alleine in dem Team, wo man ist,

Oh ja, das wird dann auch so ein Hin und Her mit wer ist wofür zuständig und in welchem Projekt oder Git-Repo liegen dann die Sachen und wie kommen die zusammen?

dann sind Veränderungen natürlich viel einfacher, als wenn man sich mit x anderen Teams abstimmen muss. Und Ja, also das muss man auch natürlich so sehen, wenn man jetzt sagt, okay, das CMS als Service, einer von vielen Services, liegt in einem Team und dieses Team braucht eine Entwicklungsumgebung, dann kann man das natürlich entsprechend aufbauen, umbauen, verändern.

Ja.

Wenn jetzt das Team, das irgendwie den Shop-Anteil verwaltet, eine andere Entwicklungsumgebung hat, die für die funktioniert, ist das ja auch völlig okay. Wahrscheinlich haben die noch nicht mal die anderen, den anderen Services mit drin unbedingt oder denen irgendwie nur gemockt oder ziehen sich von irgendeinem Testsystem dann die Daten da ins System. Ich sage jetzt mal, wenn wir so ein Content-Commerce-Projekt machen, dann habe ich auch sehr selten lokal den Shop auch laufen mit irgendwelchen Testdaten, weil das macht ein anderes Team, Und für mich ist es gut genug, wenn ich irgendwie sage, okay, hol mir diese Daten einfach aus dem Testsystem raus. Also sowas wie das Menü, dass das zusammengebaut wird, das ist okay, wenn du dir die Daten einfach woanders holst. Oder das ist gemockt oder so. Das ist auch recht völlig aus, weil mein Job ist irgendwie...

Reicht vollkommen aus. Wenn es eine

hier braucht es ein neues Inhaltselement oder wir implementieren eine neue Schnittstelle irgendwo anders hin, Richtung ERP oder sonst irgendwas. Dann I don't care, was der Shop macht am Tagesende.

Ja.

Oder ich spreche halt einen Service an, der gibt mir das Zeugs zurück. Also das ist ja, es gibt ja eine Million Varianten, wie man das machen kann. Ich finde so ein Standard-Entwicklungsumgebung Das drückt halt auch viel aus, wie man persönlich arbeiten möchte oder in dem Team, in dem man ist, arbeiten möchte. Und ich finde, es gibt ein paar gute Wege und ein paar, die ich nicht machen möchte.

Was wären denn die guten Wege? Also beziehungsweise was ist das, was für dich wirklich ausschlaggebend ist in der Entwicklungsvergebung, wo du sagst, das muss sein, damit ich vernünftig arbeiten kann?

Ja, ich, genau, also ich bin großer Fan davon, dass ich die einfach mit einem Befehl starten kann, ja, also ich sage jetzt mal, geht Pull und dann irgendwie, okay, starte das Ding.

Also ich habe da gerade was vor Augen. Also.

So, es ist okay, wenn ich dann dabei Kaffee ziehen kann, meinetwegen auch Kaffee trinken kann und dann klettert alles durch und macht, das, das finde ich total nice. Ähm, Ich persönlich bevorzuge Make, es gibt auch Menschen, die bevorzugen LIDEV, das ist auch in Ordnung, da werden auch Container hochgezogen.

Ich glaube, wir sind beide Team Make. Ja.

Meintwegen auch ein Bash-Script, ist mir egal. Ja, also da bin ich jetzt leidenschaftslos am Tagesende, zumindest wenn es nicht meine Umgebung ist, die ich aufgebaut habe, ja. Was ich finde, was gar nicht geht, ich finde das viel wichtiger zu wissen, so was wie Mump, war ja früher der Standard, oder so nativ irgendwie den Apache und dann nativ die PHP-Version und dann muss man alles da, ich finde auch Vagrant mittlerweile nicht mehr attraktiv.

XEMF. Mhm.

Vagrant war mal nett, Aber ich fände, Background-Boxen selber bauen, auf das Level bin ich da zum Beispiel nicht gekommen. Da war Docker viel freundlicher zu mir.

Ja, also ich bin da gewesen. Das ist so die erste Bekanntschaft mit Virtualisierung, die ich gemacht habe. Und es war für mich eine ganz neue Welt, weil ich das geil fand. Es war besser als das, was ich vorher hatte, weil da haben wir in einer Agentur zentral auf den Servern auf dem gleichen Dingen gearbeitet.

Definitiv.

Heißt, an dem gleichen Projekt, an der gleichen Datenbank. Und wenn ich etwas im Quellcode geändert habe, habe ich fünf Kollegen blockiert, weil die... dass die Datenbank kaputt gemacht hat. Halben Tag ging nichts mehr. Daniel war der blöde neue Developer. Geiles Gefühl, hat richtig Spaß gemacht. Und dann kam Vagrant und das war so cool. Ich drücke drauf und so wie du beschreibst, ich gehe Kaffee holen. Das Ding war mit Ansible so verwaltet, dass dann Ansible innen alles hergerichtet hat in dem Container und dann lief der und dann haben wir dieses Image immer verteilt, so über das Netzwerk und dann konnte man damit schon mal schnell starten. Das war so der erste Schritt. Dann kam irgendwann mal dieses neue Docker-Zeug. Das hat mich erst mal voll nicht abgeholt, bis ich überhaupt verstanden habe, dass es halt nicht wie Vagrant nur eine kleinere Box ist, sondern dass man damit Dienste orchestrieren kann. Und seitdem bin ich... Also ich kann gar nicht mehr ohne. Ich wüsste auch nicht, wie ich ohne arbeiten wollen würde, weil...

Am Anfang habe ich Docker auch wirklich nicht gemocht. Das muss ich auch zugeben. Ständig ist irgendwas kaputt gegangen, aber das war auch einfach die fehlende Erfahrung, möchte ich.

Ja. Früher. Ja, genau. Genau. Ja, da musst du mir noch ein bisschen Byte selber klöppeln.

Und das fehlende Wissen auch an der Stelle.

Mhm.

Aber auf das Level bin ich zum Beispiel mit Vagrant nie gekommen. Ich weiß es nicht, das war... Ich meine, da war ich dann ja auch ein paar Tage noch jünger als doch, bevor doch, also früher, damals, als wir nichts hatten. Ja, jedes Einzelne mit viel Liebe von Hand. Ich sage jetzt mal, wir leben ja mittlerweile auch durch die Erfahrung, die wir gesammelt haben, in einer sehr glücklichen Welt. wo sehr, sehr viel möglich ist und wo sehr viele Dinge im täglichen Doing einfacher geworden sind, mit dem man sich weniger beschäftigen muss, aber was auch mehr Komplexität gebracht hat.

Ja, Komplexität ist explodiert.

Also du musst ein breiteres Wissen haben an einigen Stellen und

Muss man das?

Das ist

Also, weil die Quizfrage ist jetzt genau durch das Dev-Setup. Also ich glaube, unsere beiden, ohne dass wir uns jetzt abgesprochen haben, die dürften sehr ähnlich sein. Das finde ich geil. Das müssen wir gleich mal übereinander legen. Mein Beispiel ist, das Devsetup, was ich habe, nutze ich in vielen Sachen. Und das war immer so, Frontend-Entwickler freuen sich, weil die haben ein laufendes Backend im Hintergrund, was mit Fixture-Daten komplett gefüllt ist. Die können ihre Tests schreiten, die können wirklich gegen reale API entwickeln. Was aber immer dazu führt, ist mit, Daniel, da ist irgendwas. Irgendwas ist kaputt. Ich habe es aufgesetzt, ich kenne es in- und auswendig. Natürlich finde ich den Fehler schneller als andere. Und ich würde jetzt auch nicht erwarten, dass andere... egal wo sie sind, also auch Backend-Entwickler genauso, die müssen gar nicht so tief in dem Thema drin sein, weil dieses Thema DevOps einfach mir persönlich mehr liegt oder ich durch Vagrant und andere Sachen vielleicht schon tiefer drin bin. Also du kannst ja gar nicht mehr alles wissen. Ich kann zum Beispiel auch umgekehrt genauso Frontend-mäßig, wenn da irgendwie Highload-Sachen in React passieren müssen, Kann ich mal mein Glück versuchen. Vielleicht finde ich auch was, aber das dürfte dauern, bis ich was finde. Und da sind andere Leute schneller. Und ich glaube, das ist so die Spezialisierung in vielen Teams, die du hast, wo du wirklich dann Leute hast, die können, die wissen, wie Make funktioniert, die wissen, was Docker ist. Die können auch rausfinden, dass bei denen Docker Desktop auf dem macOS gerade nicht läuft und das starten. Aber musst du das debuggen können, wenn, weiß ich nicht, PHP in der Version irgendwo nicht kompiliert und da so ein C-Fehler, die um die Ohren fliegt oder... Netzwerktechnik.

Das meine ich zum Beispiel gar nicht, aber du musst halt ein breites Wissen haben, neben deinem tiefen Spezialwissen.

Achso. Ja.

Weißt du, früher bist du hingegangen, also gerade als es noch die Entwicklungsserver gab quasi, wo du deine Umgebung hattest, die hat ja irgendein Admin verwaltet, aufgesetzt, Und dann lief es hoffentlich oder halt auch nicht so gut, je nachdem. Und dann hattest du diese eine Umgebung, da bist du hingegangen, du musstest eigentlich nichts von Server wissen, von Linux wissen, sondern nur PHP im besten Fall oder halt auch ein bisschen HTML und so.

Oh, SVN. Danke für die Flashbacks. Hm.

Und konntest halt deinen Job machen. Jetzt musst du halt irgendwie dann doch schon wissen, okay, es gibt hier GIT ist ja auch noch dazu gekommen, von da, wo wir angefangen haben. Oder erst SVN und dann GIT. Ich sage jetzt mal, die Toolchain, die man benutzt und die Tools, die man dann doch irgendwie ein bisschen zumindest kennen muss, die sind einfach mehr geworden. Früher hattest du dein FTP-Programm, hast das einfach auf den Server geknallt, dann ist es kaputt gegangen. Aber es war halt irgendwie, du hattest das FTP-Programm, du hattest deinen Editor, in dem du programmiert hast, also, und da hast du keine Tests geschrieben und all so Dinge, das sind ja, ich sag jetzt mal, außerhalb des rein Codeschreibens sind ja viel mehr Dinge dazugekommen. Also irgendwie dieses Ding, okay, wir schreiben jetzt auf, wir schreiben Tests, wir versionieren das Zeugs, nicht mehr durch, wir ändern die Dateiendung oder so, sondern so ganz echt.

Zum Glück.

Wir haben Entwicklungsumgebungen, wir haben Composer, ja, auch das oder andere Versionsverwaltungsmöglichkeiten oder Paketverwaltungen. Und das ist ja einfach ein Toolstack, der heute existiert, der eine gewisse Komplexität reinbringt, aber halt auch ein breites Wissen erfordert. Das heißt nicht, du musst jeden Git-Befehl auswendig kennen, den du nicht häufig benutzt.

Ja.

Die Standardbefehle reichen, dass du die kennst, aber es gibt halt mehr und das ist ja schon etwas, das muss man vielleicht auch wissen. Genauso musst du wissen, okay, ich habe da irgendein, meinetwegen Docker laufen oder Podman oder sonst irgendetwas und da kommen diese Container und wo kommen denn diese Container her und wen spreche ich denn im Zweifelsfall an, wenn das Ding halt einfach nicht läuft? Und ich finde, da ist halt schon die Standardisierung, so sehr ich sie liebe, Und so sehe ich auch, es bevorzuge, dass wir heute diese Prozesse haben und diese Versionierung da haben, hat das halt im Gegensatz zu früher, vor zwei Jahrzehnten, als ich angefangen habe, vielleicht sogar ein bisschen über zwei Jahrzehnte mittlerweile, hat das natürlich Komplexität gebracht. Und die muss man heute halt auch erstmal jedem beibringen.

Es macht uns mehr Arbeit, das Ganze wieder zu standardisieren.

Und deswegen belächle ich auch reine Vibe, oder was heißt belächle, aber da finde ich diese Vibe-Coding eigentlich auch sehr spannend, gerade weil ich finde Vibe-Coding bringt uns auch weg von der Schalantistisierung ein bisschen. Aber vielleicht das stimmt.

Also ich finde Vibe Coding erstmal gut, weil das, also ich weiß nicht, ob wir überhaupt vom Thema jetzt abweichen wollen, aber wenn wir schon anfangen, ich finde es gut, weil du kannst schneller Sachen ausprobieren. Ich habe schon mehrfach jetzt gehört mit, guck mal, ich habe da irgendwas gemacht. Ich habe eigentlich keine Ahnung vom Programmieren, aber ich habe da schon mal eine Idee. Da stehe ich von OVL mit den Tatsachen.

Stimmt, dafür finde ich das super.

Also wenn ich dann dazukomme und sagen kann, guck mal, das ist geil, rumklicken, alles gut und toll, aber speichere vielleicht den Key von deiner API oder so nicht im Frontend oder weiß ich nicht, das und das kannst du anders machen, damit die Sachen schneller laufen. Dann sind wir schon im Lösungsmodus. Vorher war das so, da hat jemand eine Idee und man hat zusammen was auseinandergeklammüse, hat dann ganz viele Boards gemacht und analysiert, ob die Idee was werden könnte. Das kannst du ja skippen.

Ja, also du bist halt schneller beim POC, also schneller den POC und dann kommst du halt, wenn du Richtung MVP gehst, denke ich halt in so einen Prozess rein. Aber vielleicht sparen wir uns das Thema auch für ein andermal, weil ich finde, man muss auch vielleicht als letzten Satz zu diesem Vibe-Coding noch kurz unterscheiden zwischen Vibe-Coding und Agentic-Coding.

Also ich habe keine Ahnung, wie unterscheidest du das?

Also ich finde, Vibe-Coding ist einfach wirklich dieses Ding mit, ich hacke das rein und es kommt was funktionierendes raus auf der grünen Wiese.

Okay. Erzeuge mir Übersetzungen in sieben Sprachen zu dem E-Mail-Template.

Und Agentic-Coding bewegt sich ich sage jetzt mal, in dem Rahmen, wo sich auch ein Entwickler jeden Tag bewegt und unterstützt den halt. Dadurch, dass er halt gewisse Aufgaben übernimmt, wie zum Beispiel das Schreiben von Testfällen oder das Schreiben von Dokumentation meinetwegen auch. Oder, oder, oder. Also da kann man sich ja selber aussuchen, Genau, also gerade, welche Themen man vielleicht nicht gerne macht. Das kann man sich als Entwickler jetzt aussuchen. Wenn ich jetzt Bock habe, meinen Algorithmus selber zu schreiben und auch irgendwie die Vorstellung habe, dann kann ich das eher machen. Dann kann ich sagen, hey, schreib die Testfelder oder jetzt dokumentiere das bitte, was ich gemacht habe. Aber ich glaube, damit sollten wir jetzt nicht einsteigen. Wir haben sehr viel über Standardisierung jetzt geredet. Ich glaube, wir sollten jetzt zu einem Abschluss kommen. Wenn ich auf die Uhr schaue.

Ja. Ja, wir waren fleißig, das stimmt. Was ist der Abschluss? Sind wir uns einig oder sind wir uns einig, dass wir uns uneinig sind?

Ich glaube, wir sind uns einig, dass in bestimmten Punkten wir Standardisierung cool finden, aber unterschiedlich weitgehend darin. So.

Ja, das glaube ich schon. Damit kann ich leben. Ja, genau. Bis ich bekehrt bin. Das gefällt mir.

Ich auch. Hervorragend. Nein, wir müssen uns jetzt noch eine Stunde darüber unterhalten, dass mein Ansatz viel besser ist als dein Ansatz. Genau. Hervorragend. Dann war das unsere erste Folge Secrets Not Included. Ich hoffe, ihr hattet so viel Spaß wie wir.

Ja. Bis zum nächsten Mal.

Und dann hören wir uns hoffentlich beim nächsten Mal.

Ciao.

Ciao.