Transcript
Kai Ole Hartwig: Hey Daniel, schön, dass du hier bist, unsere ersten Folge Secrets Not Included.
Kai Ole Hartwig: Lass uns heute mal ganz locker ins Thema starten mit Standardisierung in unseren Projekt-Setups.
DAN: Ja, hi.
DAN: Ja, gerne.
DAN: Wir hatten uns das Thema ausgesucht und ich glaube, wir gehen unterschiedlich an die Sachen ran.
DAN: Also, ich...
Kai Ole Hartwig: Ja, ich befürchte das auch.
Kai Ole Hartwig: Ich bin ja so ein Mensch.
Kai Ole Hartwig: Ich stehe unfassbar auf Standardisierung und auf, ich sage jetzt mal, sehr gleiche Setups.
DAN: Mhm.
Kai Ole Hartwig: Und bin da vielleicht auch ein wenig...
Kai Ole Hartwig: sehr leidenschaftlich drin zu sagen, ein Setup fits all.
Kai Ole Hartwig: Aber ja, erzähl mal, wie machst du das?
DAN: Das ist unterschiedlich und finde ich auch extrem schwer, weil je nach Kunden und Auftraggeber unterscheiden die Sachen sich.
DAN: 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.
DAN: Sondern viele Sachen ergeben sich einfach aus dem bestehenden Setup oft.
DAN: Also ich hatte bis jetzt nicht so oft den Luxus, dass man auf der grünen Wiese anfangen kann.
DAN: Ich glaube, das ist der große Unterschied.
DAN: Und wenn man viele bestehende Projekte sieht oder reinkommt, übernimmt, mitmacht, wie auch immer, dass dann einfach schon was Existierendes da ist.
DAN: Und das muss man dann gucken, dass man das irgendwie adaptiert oder auf ein Level kriegt, mit dem man leben kann.
DAN: Und da hat sich für mich einfach ergeben, dass... Also ich habe es nie geschafft, irgendwie so eine Checkliste zusammenzubauen oder...
DAN: 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.
DAN: Weil halt viel Altlasten oder oft Altlasten mitkommen bei Projekten.
Kai Ole Hartwig: historisch gewachsene Projekte, ne?
DAN: Ja.
Kai Ole Hartwig: Das ist natürlich auch eine eigene Kategorie, aber ich finde gerade so etwas wie die Dev-Setups lassen sich unfassbar gut heute standardisieren.
Kai Ole Hartwig: Also ich sag jetzt mal, den PHP-Container, den hat man halt in Version ABC 8.2, 8.3, 8.4 irgendwie rumfliegen.
DAN: Mhm.
Kai Ole Hartwig: Und ja, okay, dann installiere ich halt im Zweifelsfall noch mal
Kai Ole Hartwig: ein paar Module oder irgendwelche Special-Sachen da rein.
Kai Ole Hartwig: Aber vom Grundsatz her habe ich erstmal das PHP da rumfliegen, das nehme ich wieder.
Kai Ole Hartwig: Und genauso den Web-Server und alles, was so sonst in diesem Ecosystem rumfliegt.
Kai Ole Hartwig: Und das versuche ich aber auch zunehmend.
Kai Ole Hartwig: 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.
DAN: Oh ja.
Kai Ole Hartwig: 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
Kai Ole Hartwig: auf einmal das auf Symphonie-basierte, auf einmal Lagerwell komplett nochmal eingebunden wurde, um dann damit eine Aufgabe zu lösen.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich finde, da sollte man ganz, ganz stark gegen eigene Best Practices gehen und nicht unbedingt mit der Checkliste, aber mit
Kai Ole Hartwig: starken Standards, die man dann eventuell durch Konfigurationen abändern kann.
Kai Ole Hartwig: Ich sage jetzt mal, du setzt eigentlich immer Graphic Magic ein für die Bildverarbeitung.
Kai Ole Hartwig: Du kannst auch einstellen, in diesem Projekt läuft halt Image Magic, weil keine Ahnung, warum auch immer das da notwendig ist.
DAN: Mhm.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Na, ich sag jetzt mal,
DAN: Ja.
Kai Ole Hartwig: Es gibt ja in jedem Projekt die gleichen Dinge.
Kai Ole Hartwig: Das werden jetzt in deinen E-Commerce-Projekten ein bisschen anders sein als in meinen CMS-Projekten.
Kai Ole Hartwig: Aber ich sage jetzt mal, so ein Slider, irgendwelche Pop-Ups, die aufgehen, diese ganzen Störer, die kommen immer wieder vor.
Kai Ole Hartwig: Ja klar, bei dem einen slidet es schneller, beim anderen sind fünf statt vier...
Kai Ole Hartwig: Die Pfeile sind ein bisschen woanders, sehen mal anders aus.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das kann ich ja immer wieder verwenden.
DAN: Ja, also ich glaube, wir können festhalten, dass Docker quasi Standard ist, zumindest aus unserer Sicht.
Kai Ole Hartwig: 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.
DAN: Ich erlebe viele Projekte, wo das nicht so ist und wo mir immer wieder auffällt,
DAN: 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.
DAN: Also ich glaube schon... Echt?
Kai Ole Hartwig: Ich glaube, gerade dieser PHP-interne Dev-Server kommt jetzt vermehrt, ist mein Eindruck.
Kai Ole Hartwig: 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,
DAN: Hm...
DAN: Ja.
DAN: Mhm.
Kai Ole Hartwig: glaube ich, wird das mehr kommen.
Kai Ole Hartwig: Ich glaube, oder mein Bauchgefühl ist auch, je nach Projekt ist das auch okay.
Kai Ole Hartwig: 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.
DAN: 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,
DAN: oder irgendwelche besonderen Config-Variablen oder Secrets hin- und herschicken muss, damit Sachen funktionieren.
DAN: Ich glaube, dann ist Standardisierung und Dockerisierung oder Containerisierung, ich will jetzt nicht nur Docker nennen, also gibt ja mehr.
Kai Ole Hartwig: Ja.
DAN: 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.
DAN: 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
DAN: will ich das nochmal starten.
DAN: 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.
DAN: Und das ist ja das, was mich dann so tierisch nervt immer, dass man eigentlich gerade Zeit hätte, etwas zu machen
DAN: und aber dann wieder zwei Stunden mit Debugging verbringt, um rauszufinden, ach stimmt, die PHP-Version passt nicht oder Node.js passt nicht.
DAN: 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.
DAN: Und das abstrahiere ich gerne mit Docker-Containern weg, dass man das im Projekt hat und dann
Kai Ole Hartwig: Ja, definitiv.
DAN: 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ß.
DAN: Ich glaube, es wird nicht lange Spaß machen, das so zu haben.
Kai Ole Hartwig: Ja, ich denke, wenn man über ein Proof of Concept hinausgeht, dann sollte man über ein besseres Setup nachdenken oder ein standardisiertes Setup.
Kai Ole Hartwig: Das muss ja nicht besser sein, zu sagen, man nimmt jetzt einen Container.
DAN: Hm.
DAN: Hm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: In der Annahme
Kai Ole Hartwig: dass das da dann immer gleich sein wird und immer laufen wird.
DAN: Ja.
Kai Ole Hartwig: Bisher fahre ich auch wirklich gut damit.
Kai Ole Hartwig: Also das ist jetzt nicht, wo ich sage, uh, jetzt muss ich hier aber den Container wieder anpassen und so.
Kai Ole Hartwig: Also das läuft sauberer und besser, als wenn man jetzt irgendwie die Entwicklungsumgebung so direkt auf dem...
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ja, ist ja auch kein Thema mit Homebrew, schnell umgestellt, aber das ist ja auch immer, man muss sich da erinnern.
Kai Ole Hartwig: Klar, man kann sich das wieder wegskripten.
Kai Ole Hartwig: Ja, ich wechsle das Projekt in meiner Asile-Eye und dann fängt das an, die Sachen zu machen.
Kai Ole Hartwig: 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.
DAN: Und das ist ja nur der Anfang.
DAN: Dann kommt als nächster Schritt, du hast eine Datenbank.
DAN: MariaDB, was auch immer, die du starten willst.
DAN: Du brauchst Daten da drin.
DAN: 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.
DAN: Damit, wenn ich morgens starte, immer das System im Status quo dasteht und dann auch Testing funktioniert.
DAN: Wenn ich jetzt irgendwie lokal mir was zusammengebaut habe,
DAN: Ich habe gerade ein bisschen im Admin-Bereich rumgeklickt, irgendwas gelöscht.
DAN: Ja, das war meine Demo-Brand, wo meine End-to-End-Tests drauflaufen.
DAN: Die Tests failen.
DAN: Warum failen die?
DAN: 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.
DAN: Und das ist halt, oder das finde ich bei Docker-Containern angenehm, wenn du damit anfängst,
DAN: Der erste Schritt ist ja erstmal nur wirklich PHP-Version.
DAN: Der nächste Schritt, dann hast du eine Datenbank, die du abstrahiert hast in der richtigen Version.
DAN: Die kommunizieren untereinander.
DAN: Du hast schon Umgebungsvariablen, so ein bisschen ähnlicher wie auf dem Produktivsystem.
DAN: Also ich will nicht sagen gleich, aber ähnlicher wie auf dem Produktivsystem, weil vielleicht auch die Datenbank irgendwo anders liegt.
DAN: Das nächste Thema sind E-Mails.
DAN: Ja, mit Docker hast du ganz schnell einen Mailcatcher installiert, wo alle E-Mails drin landen.
DAN: Da kannst du E-Mails testen oder zumindest mal als Mensch auch gucken, was da passiert.
DAN: Dann AWS und Hyperscaler kommen wir auch nicht drum rum.
DAN: Mit LocalStack kannst du sowas sogar lokal abstrahieren.
DAN: Oder, weiß ich nicht, eine andere Message Queue lokal installiert.
DAN: Und dann schon bist du bei einem Stack, der richtig groß wird und das Ganze irgendwie dann organisiert werden muss.
Kai Ole Hartwig: Ja, du hast das Caching noch völlig außen vor gelassen.
Kai Ole Hartwig: Ja, dann...
DAN: Ja, genau, caching auch noch.
DAN: Redis.
DAN: Hm.
DAN: Hm.
Kai Ole Hartwig: Redis, vielleicht dann auch noch ein Varnish oder ähnliches als Fullpage Cache davor.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ja, auf einmal hast du so einen Varnish, der dann irgendwie von drei Teams bespielt wird, die da irgendwie wild Konfigurationen reinschreiben.
Kai Ole Hartwig: hoffentlich nicht ganz so wild, sondern natürlich über Git versioniert und vernünftig deployed mit GitOps und so weiter und so fort.
DAN: Ja.
Kai Ole Hartwig: 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
Kai Ole Hartwig: lokalen Entwicklungsumgebungen, die DEF-Umgebungen so schnell aufzusetzen sind und so schnell jeden Morgen wieder laufen,
Kai Ole Hartwig: dass man auch gar nicht merkt, dass man das jetzt irgendwie macht.
Kai Ole Hartwig: 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.
DAN: schuldig.
DAN: Ja.
Kai Ole Hartwig: Es gibt ja eine Million Möglichkeiten, das zu standardisieren.
Kai Ole Hartwig: Da muss man sich ja auch einfach für einen Weg entscheiden.
Kai Ole Hartwig: Ich bin jetzt auch großer Fan von Make Files, die dann einfach...
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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
DAN: Mhm.
Kai Ole Hartwig: das steht nirgendwo, das wurde vergessen zu dokumentieren und dann läuft das Projekt nicht.
Kai Ole Hartwig: Und das sind ja diese ganzen Sachen.
Kai Ole Hartwig: Ganz spannend finde ich auch eigentlich Secret Management für die lokalen Entwicklungsumgebungen.
Kai Ole Hartwig: 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.
DAN: Mhm.
DAN: Mhm.
Kai Ole Hartwig: Weiß ich nicht.
Kai Ole Hartwig: 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.
DAN: Ah, okay, also dass du das beim Setup theoretisch setzt.
Kai Ole Hartwig: Genau, so und halt auch sehr mit dem Ziel, in den Produktivsystemen gar nicht mehr hohe Berechtigungen vergeben zu müssen.
Kai Ole Hartwig: Das ist jetzt, also sprich, dass auf einem Produktivsystem es gar keinen Admin mehr gibt.
DAN: Ja.
DAN: Ja.
Kai Ole Hartwig: Im CMS-Bereich bestimmt eine ganze Ecke leichter als im Shop-Bereich.
Kai Ole Hartwig: Aber mit dem Gedanken, wir versionieren eh alle Konfigurationen vollständig.
Kai Ole Hartwig: 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.
DAN: Ja.
Kai Ole Hartwig: Wenn das nämlich notwendig ist, dann ist ja davor irgendwas schiefgegangen.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ohne Frage.
Kai Ole Hartwig: Aber im Normalbetrieb sollte es eigentlich nicht notwendig sein, dass jemand daran geht, diese Konfigurationen anpassen kann oder verändert.
Kai Ole Hartwig: Ganz spannend finde ich auch persönlich für den Betrieb nachher,
Kai Ole Hartwig: jetzt gehen wir gerade von der Standardisierung ein bisschen weg, aber von der Idee her, Read-Only-Filesysteme zu haben in den Containern.
Kai Ole Hartwig: Ja, dass nur noch bestimmte Verzeichnisse, wo es notwendig ist, darauf beschrieben werden kann und alles andere ist nicht veränderbar.
DAN: Temp und war.
DAN: Ja.
Kai Ole Hartwig: Ja, das wird einmal im Bildprozess gebaut, in den Container gepackt, signiert, dass es von dort kommt,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Genau, sowieso.
DAN: Aber das sind ja Sachen, die landen dann entweder in einem S3-Bucket, NFS-Storage, also außerhalb von dem Container.
DAN: Egal, was du machst, ob es jetzt AWS oder Kubernetes, würdest du das ja auch nicht irgendwo in den Container mit schreiben.
DAN: Also da hast du dann auch ein Storage irgendwo.
Kai Ole Hartwig: Also nicht, wenn du nicht völlig verrückt bist und bei eben die Promit auf einmal Daten verlierst.
DAN: Ja.
DAN: Ja.
Kai Ole Hartwig: Ich glaube, das haben auch schon Menschen bestimmt gemacht.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: Und dann ist dieses Volume weg auf einmal und dann stehst du da und alle Daten sind weg.
Kai Ole Hartwig: Ja, doof.
Kai Ole Hartwig: Alle Bilder weg.
DAN: Chef, wir haben ein Problem.
DAN: Ja.
Kai Ole Hartwig: Also das Marketing, das hat alle Bilder gelöscht.
DAN: genau die anderen was, das ist immer gut, ja.
DAN: Mhm.
Kai Ole Hartwig: Ja, natürlich waren es die anderen.
Kai Ole Hartwig: Das waren nie, nie, nie die Entwickler und natürlich auch nie Ops und auch nie, egal wer dran war, es war nie jemand.
DAN: Technik.
DAN: Ja.
DAN: Ja, aber zumindest, das heißt, du organisierst deine Secrets wie?
DAN: Oder beziehungsweise worüber?
DAN: Wie kommen die in den Container rein?
Kai Ole Hartwig: Ready?
DAN: 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,
DAN: da irgendwie noch einen Secrets Manager in eine Dev-Umgebung mit einzubauen und sage so, komm, die haben keine Relation zum Produktivsystem.
DAN: Ich habe keine Secrets, die irgendwie relevant sind, also von keinem externen System.
DAN: Alles, was ich lokal habe, ist das Passwort von der lokalen Datenbank.
DAN: 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.
DAN: 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.
DAN: Mhm.
Kai Ole Hartwig: Ja, es ist verrückt, ne?
Kai Ole Hartwig: Also, es gibt das, ich weiß das.
Kai Ole Hartwig: Ich gehe da sehr anders ran, also ich bin ein Freund davon, die grundsätzlich nur zur Laufzeit zu haben.
DAN: Ja.
DAN: Also.
Kai Ole Hartwig: Für lokale Entwicklungsumgebungen haben wir die tatsächlich verschlüsselt im Git-Versioniert.
Kai Ole Hartwig: Also bedeutet aber auch nur, der Entwickler, deren Key, deren Public Key auch hinterlegt ist, kann die auch entschlüsseln.
Kai Ole Hartwig: Und wir reichen die dann zur Laufzeit rein.
Kai Ole Hartwig: Also... Ja...
DAN: Also ähnlich wie Symphony Secrets gibt es ja auch mittlerweile als Bundle.
DAN: Also gibt es tausend Lösungen, das ist die, die mir jetzt gerade einfällt.
Kai Ole Hartwig: Es gibt tausend Lösungen.
Kai Ole Hartwig: Ich müsste jetzt nachschauen, wie unsere heißt.
Kai Ole Hartwig: Das ist aber auch eine Standardlösung.
Kai Ole Hartwig: Da ist nichts Wildes, Selbstgebautes.
Kai Ole Hartwig: Und in Produktivumgebungen bin ich eigentlich ein großer Fan, auch via Sidecars über ein Vote oder so die Secrets reinzugeben.
DAN: Das ist auch interessant, ja.
Kai Ole Hartwig: Muss man natürlich auch schauen, je nachdem, wie groß oder klein das Setup ist.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das zu regeln.
DAN: Mhm.
Kai Ole Hartwig: Ja, auf jeden Fall erstmal nicht in den Container rein und nicht schreiben, sondern eigentlich in der jeweiligen Umgebung von außen reingeben und
DAN: Genau, weil die Container eigentlich nur als Grundstruktur funktionieren sollten und nicht für eine spezielle Umgebung gebaut werden sollten.
Kai Ole Hartwig: Ja, ja.
DAN: 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.
DAN: 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.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich spiele die auf Test aus, da wird die getestet.
Kai Ole Hartwig: Und dann gehe ich hin und baue wieder neu.
Kai Ole Hartwig: Weil eigentlich veränderst du ja im Zweifelsfall das,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also eigentlich ist es
DAN: einfach fehlende Schreibrechte für irgendeinen Ordner, der nachträglich auf einmal benötigt wird.
Kai Ole Hartwig: Ja, irgendwelche dummen Dinge passieren dann ja.
DAN: Fliegt dir alles um die Ohren.
Kai Ole Hartwig: Nicht jedes Mal, aber irgendwann dann, wenn man es nicht gebrauchen kann.
Kai Ole Hartwig: Ja, letztes Deployment vor Weihnachten, 16 Uhr, Weihnachtsfeier startet quasi.
DAN: Ja, ja, genau.
Kai Ole Hartwig: Wackfix musst du unbedingt raus.
Kai Ole Hartwig: Man baut das neu und dann passiert irgendwas.
Kai Ole Hartwig: So.
Kai Ole Hartwig: Oder freitags, nachmittags oder whatever.
Kai Ole Hartwig: Es ist ja immer so, dass solche Seiteneffekte dann auftreten, wenn man die eigentlich unter gar keinen Umständen gerade gebrauchen kann.
DAN: Wenn es richtig weh tut, wenn es richtig weh tut, ja.
Kai Ole Hartwig: Dann geht was kaputt, dann muss sich da jemand hinsetzen, das wieder alles fixen.
DAN: Hm.
Kai Ole Hartwig: Und deswegen halte ich die Idee, immer wieder diese Container neu zu bauen, für grundlegend falsch.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Aber halt nicht zu sagen, ah, jetzt hat sich was verändert.
Kai Ole Hartwig: Es würde ja auch niemand hingehen und sagen, na, das Composer-Log-File hat sich zwar verändert,
Kai Ole Hartwig: Aber ich schreibe jetzt trotzdem einfach dran, dass das die Stable-Version ist, auch wenn das in der Zusammensetzung gar nicht getestet wurde.
DAN: Ja.
Kai Ole Hartwig: Und ich finde auch den, also ich weiß, wie Teams da hinkommen.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
DAN: Ich glaube einfach, dass wir nur schneller waren.
Kai Ole Hartwig: Ich finde,
DAN: Wir haben schon als Erste ins Klo gegriffen.
DAN: Also jedem ist das doch mal passiert.
DAN: 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.
DAN: Meine Analogie ist immer so die Herdplatte.
DAN: Als Kind packst du einmal drauf, verbrennst dir so richtig die Finger.
DAN: Und spätestens, wenn du dann fünf Jahre später nochmal die Herdplatte siehst, weißt direkt, heiß, aua, mache ich nicht nochmal.
DAN: 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.
Kai Ole Hartwig: Ja gut, wer hat noch nie ein Produktivsystem abgeschossen?
DAN: Und ich glaube, viele, die das machen, denen ist das noch nicht passiert.
Kai Ole Hartwig: Also, genau.
DAN: Ja, ja, die Bauchschmerzen dabei.
Kai Ole Hartwig: Das ist natürlich, Lernen durch Schmerzen ist sehr effektiv an der Stelle, stimme ich dir absolut zu.
DAN: Ja.
Kai Ole Hartwig: Aber ich glaube auch, wenn man einmal so Grundkonzepte verstanden hat, wie laufen saubere Update-Prozesse,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also, an manchen Tagen halte ich mich für so schlau, dass ich glaube, dass ich das hinbekomme, Fehler nicht häufiger zu machen.
Kai Ole Hartwig: An Tagen ohne ausreichend Koffeinzufuhr möchte ich das aber nicht garantieren.
Kai Ole Hartwig: So,
DAN: Ja, ja.
DAN: Und genau dafür sind dann Automatisierungen perfekt, die uns davon abhalten, dumme Fehler nochmal zu machen.
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: 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.
DAN: Mhm.
Kai Ole Hartwig: Wir hatten zum Beispiel in einem Projekt mal einen ganz komischen Fehler.
Kai Ole Hartwig: Wir haben...
Kai Ole Hartwig: zusätzliche Libraries installiert und auch deinstalliert wieder.
Kai Ole Hartwig: Also sprich rausgenommen im Sinne von, wir haben das aus der Zeile, aus dem Docker-File rausgenommen.
Kai Ole Hartwig: Aber der Build-Prozess war cached.
Kai Ole Hartwig: Und dann war quasi dieser alte Layer, wo es drin war, in der Version war noch vorhanden.
Kai Ole Hartwig: Und hat dann natürlich weiter die Fehler geschmissen.
DAN: Das Übliche.
Kai Ole Hartwig: So, total...
DAN: It works on my machine.
DAN: Scheiße.
Kai Ole Hartwig: 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.
DAN: Ja, ja, ja, genau.
Kai Ole Hartwig: Das sind natürlich so Learnings, da kommt man dann dazu, deswegen auch iterativ, so eine Pipeline ist, glaube ich, nie fertig.
DAN: Bis jetzt.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das ist ja auch so eine Erkenntnis manchmal in Standardisierung, dass man auch mit PHP-Libraries, die man selber baut und Modulen,
Kai Ole Hartwig: 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.
DAN: Ja.
DAN: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und stellt dann fest, naja, schau mal, jetzt...
Kai Ole Hartwig: jetzt ballern wir einfach tausend Datensätze in einer Sekunde dadurch.
Kai Ole Hartwig: Ja, oder meinetwegen auch in einer Minute, weil die XML ist groß und mehr oder Gigabyte Stream ist immer ein bisschen ätzend.
Kai Ole Hartwig: So Sachen kann man dann ja super machen.
Kai Ole Hartwig: Und ich finde, deswegen mag ich nicht dieses zu sagen,
Kai Ole Hartwig: 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,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also ich finde, Individualität ist an manchen Stellen einfach auch gefährlich.
DAN: Ja, es ist schwer.
DAN: Also es ist schwer, dass
Kai Ole Hartwig: Also das hält ja niemanden davon ab, ein anderes Design zu haben.
Kai Ole Hartwig: Oder auch andere Funktionen einzubauen, die kann man ja trotzdem standardisieren, in Pakete reinpacken und da sauber verwalten, versionieren, mit Tests ausstatten.
DAN: Um nochmal bei dem Beispiel zu bleiben, was wir am Anfang hatten, also Docker und das Dev-Setup.
DAN: 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.
DAN: Und das habe ich auch.
DAN: Also bei mir sind das auch so Unterordner, die Funktionalität enthalten, Makefiles, die halt die Unterordner einbinden.
DAN: 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.
DAN: Und die Spezialisierung ist natürlich immer das Problem, was dann dagegen steht.
DAN: 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
DAN: 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.
Kai Ole Hartwig: Ja.
DAN: 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.
DAN: Also nicht, dass man das nicht schon versucht hätte, aber kann ich nur sagen, ist eine dumme Idee.
DAN: Mhm.
Kai Ole Hartwig: 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
Kai Ole Hartwig: ü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.
Kai Ole Hartwig: Und dann kann ich natürlich in dem Projekt Makefile beliebig überschreiben und verändern.
Kai Ole Hartwig: Ich arbeite halt auch in den Makefiles mit Variablen, dass ich das anpassen kann.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und bisher funktioniert das nicht,
Kai Ole Hartwig: Sehr gut.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Aber es ist natürlich auch schwierig, also es kommt auch auf die Projektgröße an.
Kai Ole Hartwig: 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,
DAN: 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?
Kai Ole Hartwig: dann sind Veränderungen natürlich viel einfacher, als wenn man sich mit x anderen Teams abstimmen muss.
Kai Ole Hartwig: Und
Kai Ole Hartwig: 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.
DAN: Ja.
Kai Ole Hartwig: Wenn jetzt das Team, das irgendwie den Shop-Anteil verwaltet, eine andere Entwicklungsumgebung hat, die für die funktioniert,
Kai Ole Hartwig: ist das ja auch völlig okay.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: Und für mich ist es gut genug, wenn ich irgendwie sage, okay, hol mir diese Daten einfach aus dem Testsystem raus.
Kai Ole Hartwig: Also sowas wie das Menü, dass das zusammengebaut wird, das ist okay, wenn du dir die Daten einfach woanders holst.
Kai Ole Hartwig: Oder das ist gemockt oder so.
Kai Ole Hartwig: Das ist auch recht völlig aus, weil mein Job ist irgendwie...
DAN: Reicht vollkommen aus.
DAN: Wenn es eine
Kai Ole Hartwig: hier braucht es ein neues Inhaltselement oder wir implementieren eine neue Schnittstelle irgendwo anders hin, Richtung ERP oder sonst irgendwas.
Kai Ole Hartwig: Dann I don't care, was der Shop macht am Tagesende.
DAN: Ja.
Kai Ole Hartwig: Oder ich spreche halt einen Service an, der gibt mir das Zeugs zurück.
Kai Ole Hartwig: Also das ist ja, es gibt ja eine Million Varianten, wie man das machen kann.
Kai Ole Hartwig: Ich finde so ein Standard-Entwicklungsumgebung
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und ich finde, es gibt ein paar gute Wege und ein paar, die ich nicht machen möchte.
DAN: Was wären denn die guten Wege?
DAN: 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?
Kai Ole Hartwig: 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.
DAN: Also ich habe da gerade was vor Augen.
DAN: Also.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ähm,
Kai Ole Hartwig: Ich persönlich bevorzuge Make, es gibt auch Menschen, die bevorzugen LIDEV, das ist auch in Ordnung, da werden auch Container hochgezogen.
DAN: Ich glaube, wir sind beide Team Make.
DAN: Ja.
Kai Ole Hartwig: Meintwegen auch ein Bash-Script, ist mir egal.
Kai Ole Hartwig: Ja, also da bin ich jetzt leidenschaftslos am Tagesende, zumindest wenn es nicht meine Umgebung ist, die ich aufgebaut habe, ja.
Kai Ole Hartwig: 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.
DAN: XEMF.
DAN: Mhm.
Kai Ole Hartwig: Vagrant war mal nett,
Kai Ole Hartwig: Aber ich fände, Background-Boxen selber bauen, auf das Level bin ich da zum Beispiel nicht gekommen.
Kai Ole Hartwig: Da war Docker viel freundlicher zu mir.
DAN: Ja, also ich bin da gewesen.
DAN: Das ist so die erste Bekanntschaft mit Virtualisierung, die ich gemacht habe.
DAN: Und es war für mich eine ganz neue Welt, weil ich das geil fand.
DAN: 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.
Kai Ole Hartwig: Definitiv.
DAN: Heißt, an dem gleichen Projekt, an der gleichen Datenbank.
DAN: Und wenn ich etwas im Quellcode geändert habe, habe ich fünf Kollegen blockiert, weil die...
DAN: dass die Datenbank kaputt gemacht hat.
DAN: Halben Tag ging nichts mehr.
DAN: Daniel war der blöde neue Developer.
DAN: Geiles Gefühl, hat richtig Spaß gemacht.
DAN: Und dann kam Vagrant und das war so cool.
DAN: Ich drücke drauf und so wie du beschreibst, ich gehe Kaffee holen.
DAN: 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
DAN: über das Netzwerk und dann konnte man damit schon mal schnell starten.
DAN: Das war so der erste Schritt.
DAN: Dann kam irgendwann mal dieses neue Docker-Zeug.
DAN: 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.
DAN: Und seitdem bin ich... Also ich kann gar nicht mehr ohne.
DAN: Ich wüsste auch nicht, wie ich ohne arbeiten wollen würde, weil...
Kai Ole Hartwig: Am Anfang habe ich Docker auch wirklich nicht gemocht.
Kai Ole Hartwig: Das muss ich auch zugeben.
Kai Ole Hartwig: Ständig ist irgendwas kaputt gegangen, aber das war auch einfach die fehlende Erfahrung, möchte ich.
DAN: Ja.
DAN: Früher.
DAN: Ja, genau.
DAN: Genau.
DAN: Ja, da musst du mir noch ein bisschen Byte selber klöppeln.
Kai Ole Hartwig: Und das fehlende Wissen auch an der Stelle.
DAN: Mhm.
Kai Ole Hartwig: Aber auf das Level bin ich zum Beispiel mit Vagrant nie gekommen.
Kai Ole Hartwig: Ich weiß es nicht, das war...
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ja, jedes Einzelne mit viel Liebe von Hand.
Kai Ole Hartwig: Ich sage jetzt mal, wir leben ja mittlerweile auch durch die Erfahrung, die wir gesammelt haben, in einer sehr glücklichen Welt.
Kai Ole Hartwig: 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.
DAN: Ja, Komplexität ist explodiert.
Kai Ole Hartwig: Also du musst ein breiteres Wissen haben an einigen Stellen und
DAN: Muss man das?
Kai Ole Hartwig: Das ist
DAN: Also, weil die Quizfrage ist jetzt genau durch das Dev-Setup.
DAN: Also ich glaube, unsere beiden, ohne dass wir uns jetzt abgesprochen haben, die dürften sehr ähnlich sein.
DAN: Das finde ich geil.
DAN: Das müssen wir gleich mal übereinander legen.
DAN: Mein Beispiel ist, das Devsetup, was ich habe, nutze ich in vielen Sachen.
DAN: 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.
DAN: Die können ihre Tests schreiten, die können wirklich gegen reale API entwickeln.
DAN: Was aber immer dazu führt, ist mit, Daniel, da ist irgendwas.
DAN: Irgendwas ist kaputt.
DAN: Ich habe es aufgesetzt, ich kenne es in- und auswendig.
DAN: Natürlich finde ich den Fehler schneller als andere.
DAN: Und ich würde jetzt auch nicht erwarten, dass andere...
DAN: 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.
DAN: Also du kannst ja gar nicht mehr alles wissen.
DAN: Ich kann zum Beispiel auch umgekehrt genauso Frontend-mäßig, wenn da irgendwie Highload-Sachen in React passieren müssen,
DAN: Kann ich mal mein Glück versuchen.
DAN: Vielleicht finde ich auch was, aber das dürfte dauern, bis ich was finde.
DAN: Und da sind andere Leute schneller.
DAN: 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.
DAN: Die können auch rausfinden, dass bei denen Docker Desktop auf dem macOS gerade nicht läuft und das starten.
DAN: 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...
DAN: Netzwerktechnik.
Kai Ole Hartwig: Das meine ich zum Beispiel gar nicht, aber du musst halt ein breites Wissen haben, neben deinem tiefen Spezialwissen.
DAN: Achso.
DAN: Ja.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: Und dann lief es hoffentlich oder halt auch nicht so gut, je nachdem.
Kai Ole Hartwig: 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.
DAN: Oh, SVN.
DAN: Danke für die Flashbacks.
DAN: Hm.
Kai Ole Hartwig: Und konntest halt deinen Job machen.
Kai Ole Hartwig: Jetzt musst du halt irgendwie dann doch schon wissen, okay, es gibt hier
Kai Ole Hartwig: GIT ist ja auch noch dazu gekommen, von da, wo wir angefangen haben.
Kai Ole Hartwig: Oder erst SVN und dann GIT.
Kai Ole Hartwig: Ich sage jetzt mal, die Toolchain, die man benutzt und die Tools, die man dann doch irgendwie ein bisschen zumindest kennen muss,
Kai Ole Hartwig: die sind einfach mehr geworden.
Kai Ole Hartwig: Früher hattest du dein FTP-Programm, hast das einfach auf den Server geknallt, dann ist es kaputt gegangen.
Kai Ole Hartwig: 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
Kai Ole Hartwig: rein Codeschreibens sind ja viel mehr Dinge dazugekommen.
Kai Ole Hartwig: 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.
DAN: Zum Glück.
Kai Ole Hartwig: Wir haben Entwicklungsumgebungen, wir haben Composer, ja, auch das oder
Kai Ole Hartwig: andere Versionsverwaltungsmöglichkeiten oder Paketverwaltungen.
Kai Ole Hartwig: Und das ist ja einfach ein Toolstack, der heute existiert, der eine gewisse Komplexität reinbringt, aber halt auch ein breites Wissen erfordert.
Kai Ole Hartwig: Das heißt nicht, du musst jeden Git-Befehl auswendig kennen, den du
Kai Ole Hartwig: nicht häufig benutzt.
DAN: Ja.
Kai Ole Hartwig: Die Standardbefehle reichen, dass du die kennst, aber es gibt halt mehr und das ist ja schon etwas, das muss man vielleicht auch wissen.
Kai Ole Hartwig: 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?
Kai Ole Hartwig: Und ich finde, da ist halt schon die Standardisierung, so sehr ich sie liebe,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und die muss man heute halt auch erstmal jedem beibringen.
DAN: Es macht uns mehr Arbeit, das Ganze wieder zu standardisieren.
Kai Ole Hartwig: Und
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Aber vielleicht das stimmt.
DAN: 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.
DAN: Ich habe schon mehrfach jetzt gehört mit, guck mal, ich habe da irgendwas gemacht.
DAN: Ich habe eigentlich keine Ahnung vom Programmieren, aber ich habe da schon mal eine Idee.
DAN: Da stehe ich von OVL mit den Tatsachen.
Kai Ole Hartwig: Stimmt, dafür finde ich das super.
DAN: 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.
DAN: Dann sind wir schon im Lösungsmodus.
DAN: 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.
DAN: Das kannst du ja skippen.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
DAN: Also ich habe keine Ahnung, wie unterscheidest du das?
Kai Ole Hartwig: 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.
DAN: Okay.
DAN: Erzeuge mir Übersetzungen in sieben Sprachen zu dem E-Mail-Template.
Kai Ole Hartwig: Und Agentic-Coding bewegt sich
Kai Ole Hartwig: ich sage jetzt mal, in dem Rahmen, wo sich auch ein Entwickler jeden Tag bewegt und unterstützt den halt.
Kai Ole Hartwig: Dadurch, dass er halt gewisse Aufgaben übernimmt, wie zum Beispiel das Schreiben von Testfällen oder das Schreiben von Dokumentation meinetwegen auch.
Kai Ole Hartwig: Oder, oder, oder.
Kai Ole Hartwig: Also da kann man sich ja selber aussuchen,
Kai Ole Hartwig: Genau, also gerade, welche Themen man vielleicht nicht gerne macht.
Kai Ole Hartwig: Das kann man sich als Entwickler jetzt aussuchen.
Kai Ole Hartwig: Wenn ich jetzt Bock habe, meinen Algorithmus selber zu schreiben und auch irgendwie die Vorstellung habe, dann kann ich das eher machen.
Kai Ole Hartwig: Dann kann ich sagen, hey, schreib die Testfelder oder jetzt dokumentiere das bitte, was ich gemacht habe.
Kai Ole Hartwig: Aber ich glaube, damit sollten wir jetzt nicht einsteigen.
Kai Ole Hartwig: Wir haben sehr viel über Standardisierung jetzt geredet.
Kai Ole Hartwig: Ich glaube, wir sollten jetzt zu einem Abschluss kommen.
Kai Ole Hartwig: Wenn ich auf die Uhr schaue.
DAN: Ja.
DAN: Ja, wir waren fleißig, das stimmt.
DAN: Was ist der Abschluss?
DAN: Sind wir uns einig oder sind wir uns einig, dass wir uns uneinig sind?
Kai Ole Hartwig: Ich glaube, wir sind uns einig, dass in bestimmten Punkten wir Standardisierung cool finden, aber unterschiedlich weitgehend darin.
Kai Ole Hartwig: So.
DAN: Ja, das glaube ich schon.
DAN: Damit kann ich leben.
DAN: Ja, genau.
DAN: Bis ich bekehrt bin.
DAN: Das gefällt mir.
Kai Ole Hartwig: Ich auch.
Kai Ole Hartwig: Hervorragend.
Kai Ole Hartwig: Nein, wir müssen uns jetzt noch eine Stunde darüber unterhalten, dass mein Ansatz viel besser ist als dein Ansatz.
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Hervorragend.
Kai Ole Hartwig: Dann war das unsere erste Folge Secrets Not Included.
Kai Ole Hartwig: Ich hoffe, ihr hattet so viel Spaß wie wir.
DAN: Ja.
DAN: Bis zum nächsten Mal.
Kai Ole Hartwig: Und dann hören wir uns hoffentlich beim nächsten Mal.
DAN: Ciao.
Kai Ole Hartwig: Ciao.
