Diese eine Datei hat meine Entwicklungsumgebung repariert (Devbox)
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술
Transcript
00:00:00Deine README lügt dich an, sie sagt, die Einrichtung dauert fünf Minuten, dann ist Node falsch, Python ist falsch
00:00:07Postgres fehlt, Docker braucht ewig und jetzt debuggen wir, bevor wir überhaupt angefangen haben
00:00:13Deine Entwicklungsumgebung sollte nicht in einer README leben, sondern in Git – genau das macht devbox
00:00:20Eine devbox.json-Datei, ein Befehl: devbox shell, dieselbe Umgebung für jeden Entwickler ohne globale Installationen
00:00:28Und ohne Nix-Kenntnisse, lass es mich dir zeigen
00:00:30Zuerst sieht devbox fast zu einfach aus: Du erstellst eine devbox.json und listest die Tools auf, die dein Projekt benötigt
00:00:42Node, Go, Python, Postgres, was auch immer dein Stack tatsächlich braucht, du committest die Datei, dann kann jeder andere einfach
00:00:50devbox shell ausführen und erhält dieselbe Umgebung wie du, dieselben Versionen, Tools, Skripte, keine globalen
00:00:58Installationen, kein „Bitte installiere zuerst diese acht Dinge“, kein Homebrew-Zustand von vor Jahren; dein Setup
00:01:03lebt nicht mehr im Gedächtnis von jemandem, es lebt in deinem Repo. Das klingt klein, aber wenn du
00:01:09jemals einen halben Tag an ein kaputtes lokales Setup verloren hast, weißt du bereits, dass das nicht klein ist. Wenn dir
00:01:16Coding-Tools gefallen, die deinen Workflow beschleunigen, abonniere uns, wir veröffentlichen ständig neue Videos
00:01:20Wir fangen hier also an, ich starte mit einem leeren Projekt, ich erstelle einen neuen Ordner
00:01:25wir nennen ihn devbox-demo, wir wechseln in den Ordner und alles, was wir tun müssen, sobald wir devbox haben, ist
00:01:31devbox init auszuführen. Devbox erstellt eine Datei namens devbox.json, aktuell ist sie im Grunde leer, es ist nur das
00:01:39Boilerplate, das devbox uns gibt. Jetzt fügen wir die Tools hinzu, die dieses Projekt tatsächlich braucht, um Tools hinzuzufügen, können wir
00:01:45devbox add erstellen und ich installiere Dinge wie Go, Node.js und etwas Python. Hier ist der
00:01:52wichtige Teil: Ich installiere diese nicht global, ich ändere nicht mein System-Node, ich fasse nicht mein System
00:02:00mit Python an, diese Tools gehören zu diesem Projekt. Jetzt, wenn ich devbox shell ausführe und mich in einem sauberen Projekt
00:02:09befinde, jetzt, wo du in dieser Umgebung bist, kannst du einfach die Versionen überprüfen, z. B. go version, node
00:02:14version, python version, richtig, ich kann alles überprüfen, um sicherzugehen, dass es läuft. Das ist der große Vorteil
00:02:19das Projekt fragte nach spezifischen Tools, devbox hat mir diese Tools gegeben. Jetzt fügen wir ein Skript hinzu, und innerhalb der devbox
00:02:27json können wir tatsächlich einen Test definieren und ich werde nur kurz echo ausgeben, dass wir Tests ausführen, und ich hole mir die Node-
00:02:34und die Go-Version. Wenn du devbox run test ausführst, funktioniert jetzt derselbe Befehl für jeden, der dieses Repo verwendet
00:02:42dasselbe Skript, dieselben Tools, dieselbe Umgebung. Jetzt schau, was passiert, wenn ich gehe, du kannst einfach exit ausführen
00:02:48du verlässt diese Umgebung und ich bin zurück in meiner normalen Rechner-Umgebung. Das war also verdammt
00:02:53einfach, oder? Was macht devbox eigentlich? Nun, devbox nutzt Nix im Hintergrund. Nix ist großartig, weil
00:03:00es für Reproduzierbarkeit gebaut wurde. Anstatt zu sagen, installiere, was auch immer heute gerade das Neueste ist
00:03:06kann es die exakten Tools festlegen, die dein Projekt wirklich braucht. Das ist der gute Teil. Der schwierige Teil ist
00:03:12dass sich Nix wie eine ganz neue Welt anfühlen kann, es gibt viele Konzepte, die großartig sind, aber nicht gerade
00:03:18freundlich, wenn alles, was du wolltest, die richtige Node-Version war. Devbox zeigt uns etwas anderes
00:03:23Hier heißt es: Was wäre, wenn wir die Reproduzierbarkeit beibehalten, aber den Workflow normal anfühlen lassen würden? Anstatt also
00:03:29Nix-Ausdrücke zu schreiben, kannst du Befehle wie devbox add, devbox search, shell, run, services nutzen; all
00:03:37diese Befehle sind viel einfacher und dein Projekt erhält zwei wichtige Dateien: eine JSON-Datei und eine
00:03:44Lock-Datei. Betrachte die devbox.json als das, was unsere Umgebung braucht, betrachte die devbox.lock-Datei als den Fixierpunkt, um
00:03:52genau festzuhalten, was du erhalten hast. Du committest beides, jetzt ist deine Umgebung nicht nur ein Absatz in einer README-Datei
00:03:58sondern Teil des eigentlichen Projekts. Devbox funktioniert auf macOS, Linux und WSL, es kann in VS Code integriert werden, es kann
00:04:06Skripte definieren, es kann Services wie Datenbanken verwalten und wenn du es brauchst, kann es in Dinge exportieren wie
00:04:12Docker, Dev Containers und CI-Workflows. Der Wert daran ist nicht nur, dass es ein cooles Tool ist, sondern ein verdammt einfaches Tool. Der
00:04:19Wert liegt meiner Meinung nach einfach in der Zeit. Das erste Problem ist die README, richtig? Die README könnte wirklich alles sagen; es
00:04:26könnte heißen: Hey, installiere Node 18, aber die App hat sich geändert, sie braucht wirklich Node 20. Das zweite Problem
00:04:32bei dem dies tatsächlich hilft, ist das Onboarding. Es ist dein erster Arbeitstag, es sollte einfach sein, loszulegen
00:04:37wir wissen, dass das nicht der Fall ist, oder? Also solltest du nicht fragen müssen, welche Node-Version brauche ich, du solltest nicht
00:04:43jemanden anpingen müssen: Hey, welche Python-Version nutzen wir, brauche ich wirklich lokal Postgres und warum funktioniert das
00:04:48nur bei dem kleinen Timmy da drüben? Sie sollten einfach das Repo klonen, die Shell betreten
00:04:52und das Projekt ausführen müssen. Wenn etwas kaputtgeht, starten zumindest alle von derselben Umgebung aus. Das Problem
00:04:58ist globale Verschmutzung. Das Ausprobieren von Tools sollte deinen Laptop nicht zerstören. Du willst Go 1.22 für dieses Repo, du fügst es hinzu, du
00:05:06willst Node 20 hier, aber etwas anderes anderswo, ist in Ordnung, okay, das ist in Ordnung. Die Tools leben mit dem Projekt, dein
00:05:13System bleibt sauberer. Mit devbox kann deine Umgebungsdefinition zwischen lokaler Entwicklung
00:05:18und Automatisierung geteilt werden. Löst das jedes CI-Problem? Nein, wird es nicht, aber es beseitigt eine riesige Klasse von dummen
00:05:26Problemen, und dumme Probleme sind die, die uns am meisten schmerzen. Sie sind einfach, wir haben sie trotzdem ständig
00:05:32Zum Schluss noch zum schweren lokalen Docker-Workflow. Docker ist immer noch großartig, bei weitem. Wenn
00:05:40du Container brauchst, benutze Container, aber viele Teams nutzen Docker lokal, weil sie keinen besseren
00:05:46Weg haben, Tools zu verwalten. Was hier gut ist: Der Workflow ist kinderleicht, devbox add, shell, run, du
00:05:52musst nicht so viel lernen. Die Umgebung wird ein echter Teil deines Projekts, eine echte Datei
00:05:57im Repo. Wenn jeder dieselben Versionen und Skripte verwendet, wird das Debuggen einfacher. Aber das ist großartig,
00:06:03super einfach. Was dich nerven wird, ist: Nun, der erste Nix-Download hat eine Weile gedauert,
00:06:09es ist in Ordnung, es ist das erste Mal, okay. JSON ist einfach, aber es kann hässlich werden, wie wir wissen, wenn wir zu viel
00:06:15hineinpacken. Für einfache Skripte ist es in Ordnung. Für komplexe Setup-Logik, quetsche keinen riesigen Shell-Befehl in JSON,
00:06:22packe die Logik einfach in eine .sh-Datei, dann rufe die von devbox auf. Und schließlich: devbox ist keine komplette Cloud-IDE,
00:06:30wenn du browserbasiertes Programmieren, sofortige Vorschau-URLs brauchst, willst du vielleicht immer noch etwas wie Codespaces
00:06:36Devbox ist am besten für lokale und CI-Reproduzierbarkeit. Devbox wird nicht jedes Entwicklungsproblem
00:06:42lösen, aber es kann die lösen, die uns am meisten nerven, was wirklich nur ist, das Projekt zum
00:06:46Laufen zu bringen. Könnte also einen Versuch wert sein, besonders wenn dein Projekt mehr als eine Sprache oder mehr als
00:06:51ein CLI-Tool hat. Wenn dir solche Coding-Tools gefallen, abonniere unbedingt den Better-Stack-Kanal, wir
00:06:56sehen uns im nächsten Video.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video