LapDev – Open-Source-Software zur Verwaltung entfernter Entwicklungsumgebungen

 (github.com/lapce)
17 Punkte von GN⁺ 2024-03-25 | 1 Kommentare | Auf WhatsApp teilen
  • Einfaches Self-Hosting: Entwickelt, damit Installation und Wartung mit minimalem Aufwand möglich sind. Die Anwendung ist so aufgebaut, dass sie ohne aufwendige Behebung interner Probleme funktioniert.
  • Horizontale Skalierbarkeit: Mit einer einfachen, aber leistungsfähigen Architektur kann Lapdev von einer einzelnen Maschine bis zu einer Server-Fleet skaliert werden und bietet ein Verwaltungssystem für Entwicklungsumgebungen, das mit wachsenden Entwicklerteams mitwächst.
  • Als Code definierte Entwicklungsumgebungen: Mit der offenen Devcontainer-Spezifikation lassen sich Entwicklungsumgebungen als Code definieren, sodass standardisierte Umgebungen für verschiedene Entwickler reproduziert werden können, um umgebungsbedingte Probleme zu vermeiden und für alle eine konsistente Konfiguration sicherzustellen.
  • Zeitersparnis beim Onboarding: Beim Onboarding von Entwicklern für ein neues Projekt sind keine Stunden oder Tage mehr nötig, um die Umgebung auf einer Maschine vorzubereiten. Man kann sofort mit dem Coden beginnen.

Geplante Funktionen

  • Unterstützung für verschiedene Workspace-Typen: Derzeit unterstützt Lapdev nur containerbasierte Workspaces, was etwa dann Einschränkungen mit sich bringt, wenn man im Entwicklungsablauf einen k8s-Cluster ausführen möchte. Unterstützung für VMs und Bare-Metal-Maschinen steht auf der Roadmap, ebenso wie Support für verschiedene Betriebssysteme wie Windows, Linux und macOS. Dadurch können Entwickler auf derselben lokalen Maschine entwickeln und debuggen, ohne zwischen Maschinen wechseln zu müssen.

Meinung von GN⁺

  • Lapdev ist ein Tool, mit dem Entwickler entfernte Entwicklungsumgebungen auf eigenen Servern oder in der Cloud einfach einrichten und verwalten können. Durch standardisierte Entwicklungsumgebungen und schnelles Onboarding kann die Effizienz gesteigert werden.
  • Solche Tools können besonders für große Entwicklungsteams oder Organisationen nützlich sein, die gleichzeitig an verschiedenen Projekten arbeiten, da sie Konsistenz in Entwicklungsumgebungen bewahren und zugleich Skalierbarkeit bieten.
  • Vor der Einführung dieser Technologie können jedoch Aspekte rund um Sicherheit, Kompatibilität und Support zu berücksichtigen sein; zudem sollte der zusätzliche Wartungsaufwand bedacht werden, der durch eine Self-Hosting-Lösung entstehen kann.
  • Auf dem Markt gibt es bereits andere Tools mit ähnlichem Funktionsumfang, etwa die Remote Development Extensions von Visual Studio Code, und Nutzer sollten das Werkzeug wählen, das am besten zu ihren Anforderungen passt.
  • Dass Lapdev Unterstützung für VMs und Bare-Metal-Maschinen plant, kann als Teil der Bemühungen gesehen werden, unterschiedliche Anforderungen an Entwicklungsumgebungen abzudecken, was Entwicklern mehr Auswahl bieten dürfte.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-25

Hacker-News-Kommentare

  • Die Möglichkeit, Entwicklungscontainer (devcontainers) auf lokaler Server-Hardware ohne monatliche Gebühren zu nutzen, klingt wirklich gut. Bisher habe ich Docker-compose und die Remote-SSH-Entwicklung von JetBrains verwendet, aber ich erwarte, dass dieser neue Ansatz deutlich besser ist.

  • Ich interessiere mich für Remote-Entwicklungsumgebungen, bin aber nicht besonders begeistert davon, noch mehr Software in der Cloud zu verwalten. Ich halte das für eine gute Idee, weil man mit Skypilot per Plugin für Cloud-APIs Entwicklungsmaschinen starten kann, ohne einen k8s-Cluster verwalten zu müssen. Zum Starten eines Jupyter-Servers hat es besser funktioniert, aber eine „vollständige“ Entwicklungsmaschine scheint mit nur etwas SSH-/VS-Code-Konfiguration ebenfalls möglich zu sein.

  • Remote-Entwicklungsumgebungen könnten für bestimmte Arten der Entwicklung Einschränkungen haben. Zum Beispiel könnten iOS- und Android-App-Entwicklung schwierig sein, oder bei Spieleentwicklung mit GPU-Anforderungen könnte das Herunterladen von Build-Artefakten langsam sein. Ich frage mich, ob es dafür Leitfäden gibt.

  • Ich würde gern mehr über solche Tools erfahren. Ich habe gesehen, dass Coder Alpha-Support für .devcontainer enthält, aber ich kenne keine anderen OSS-Optionen.

  • Mit einem Proxmox-Setup kann man einfach bestehende VMs/Container klonen und dann nur noch VSCode darauf zeigen lassen. Was fügt das hier tatsächlich hinzu? Es ist keine Automatisierung (ein paar Klicks in Proxmox könnte man automatisieren) und auch kein Ressourcenmanagement (Proxmox kümmert sich um Storage usw.). Geht es um die Entwickleridentität? Wenn das das Einzige ist, was gebraucht wird, dann sollte man ein relativ einfaches Skript schreiben, um SSH-Schlüssel in die Umgebung zu verteilen.

  • Aus meiner Erfahrung, bei der ich code-server und SSH zusammen installieren musste, um ein auf einer Remote-Maschine gehostetes VSCode zu nutzen, ist die Aussicht auf eine wesentlich besser verwaltete Erfahrung für beides sehr interessant.

  • Eine weitere Implementierung in diesem Bereich ist devpod.sh.

  • Ich gebe den Design-Hinweis, den Text auf dem Button zentriert auszurichten, damit er wie ein Button aussieht. Wenn der Text linksbündig ist, kann es wie ein Label wirken; eine kleine Änderung, aber sie könnte die Conversion verbessern.

  • Ich verstehe, dass es auf dem Remote-Server installiert wird. Aber stellt das eine Remote-Umgebung bereit oder eine lokale Umgebung? Und was bedeutet in diesem Kontext überhaupt „Umgebung“? Eine Docker-compose-Datei und .env? Code oder vim-Konfiguration? Eine VM wie bei Vagrant?

  • Das Hauptproblem von devcontainers ist derzeit, dass sich GUI-Apps bei Remote-Ausführung nur auf dem Server selbst öffnen. Ich frage mich, ob diese Lösung GUIs remote exportieren kann.