- Auto-hébergement simplifié : conçu pour permettre une installation et une maintenance avec un minimum d’effort. L’application est pensée pour fonctionner sans avoir à résoudre de problèmes internes complexes.
- Scalabilité horizontale : grâce à une architecture simple mais puissante, Lapdev peut passer d’une machine unique à une flotte de serveurs, offrant un système de gestion d’environnements de développement capable d’évoluer avec la croissance des équipes de développeurs.
- Environnements de développement définis par le code : en utilisant la spécification ouverte Devcontainer, il est possible de définir les environnements de développement sous forme de code, afin de répliquer des environnements standardisés entre différents développeurs, d’éviter les problèmes liés à l’environnement et de garantir une configuration cohérente pour tous.
- Gain de temps pour l’onboarding : lors de l’intégration de développeurs sur un nouveau projet, il n’est plus nécessaire de passer des heures ou des jours à préparer l’environnement sur une machine. Ils peuvent commencer à coder immédiatement.
Fonctionnalités prévues
- Prise en charge de divers types d’espaces de travail : actuellement, Lapdev ne prend en charge que les espaces de travail basés sur des conteneurs, ce qui impose des limites, par exemple lorsqu’on souhaite exécuter un cluster k8s dans le flux de développement. La prise en charge des VM et des machines bare metal figure sur la feuille de route, tout comme celle de différents OS tels que Windows, Linux et macOS. Cela permettra aux développeurs de faire du développement et du débogage sur la même machine locale, sans avoir à changer de machine.
L’avis de GN⁺
- Lapdev est un outil qui permet aux développeurs de configurer et de gérer facilement des environnements de développement à distance sur leurs propres serveurs ou dans le cloud, et peut améliorer l’efficacité en rendant possible la standardisation des environnements de développement ainsi qu’un onboarding rapide.
- Ce type d’outil peut être particulièrement utile pour les grandes équipes de développement ou les organisations menant plusieurs projets en parallèle, car il offre de la scalabilité tout en maintenant la cohérence des environnements de développement.
- Toutefois, avant d’adopter cette technologie, il peut être nécessaire de prendre en compte des aspects liés à la sécurité, à la compatibilité et au support, ainsi que la charge de maintenance supplémentaire pouvant découler de l’utilisation d’une solution auto-hébergée.
- Il existe déjà sur le marché d’autres outils offrant des fonctionnalités similaires, comme Remote Development Extensions de Visual Studio Code, et les utilisateurs doivent choisir l’outil le mieux adapté à leurs besoins.
- Le fait que Lapdev prévoie la prise en charge des VM et des machines bare metal peut être vu comme une volonté de répondre à des besoins variés en matière d’environnements de développement, ce qui offrira un éventail de choix plus large aux développeurs.
1 commentaires
Avis sur Hacker News
Il semble vraiment appréciable de pouvoir utiliser des conteneurs de développement (
devcontainers) sur du matériel serveur local sans frais mensuels. Jusqu’à présent, j’utilisais Docker-compose et le développement distant en SSH de JetBrains, mais j’espère que cette nouvelle approche sera bien meilleure.Je m’intéresse aux environnements de développement distants, mais je ne suis pas particulièrement enthousiaste à l’idée de gérer encore plus de logiciels dans le cloud. Cela dit, je trouve que c’est une bonne idée, car avec Skypilot, on peut lancer des machines de développement grâce à un plugin pour les API cloud, sans avoir à gérer un cluster k8s. Cela fonctionnait mieux pour démarrer un serveur Jupyter, mais une machine de développement « complète » semble possible avec seulement quelques réglages SSH/VS Code.
Les environnements de développement distants peuvent être limités pour certains types de développement. Par exemple, le développement d’apps iOS et Android peut être délicat, ou le téléchargement des artefacts de build peut être lent pour le développement de jeux nécessitant un GPU. Je me demande s’il existe un guide pour résoudre ce genre de problèmes.
J’aimerais en savoir plus sur ce type d’outils. J’ai vu que Coder inclut un support alpha pour
.devcontainer, mais je ne connais pas d’autres options OSS.Avec une configuration Proxmox, il suffit de cloner une VM ou un conteneur existant et de pointer VSCode dessus. Qu’est-ce que cela apporte réellement de plus ? Ce n’est pas de l’automatisation (on peut automatiser quelques clics dans Proxmox), ni de la gestion des ressources (Proxmox gère déjà le stockage, etc.). La seule chose serait-elle l’identité développeur ? Si c’est le seul besoin, il faudrait simplement écrire un script (relativement simple) pour déployer des clés SSH dans l’environnement.
D’après mon expérience où il fallait installer ensemble
code-server, c’est-à-dire VSCode hébergé sur une machine distante, et SSH, l’idée d’une expérience où les deux sont mieux gérés est très intéressante.Une autre implémentation dans ce domaine est
devpod.sh.Petit conseil de design : centrer le texte du bouton pour qu’il ressemble vraiment à un bouton. Si le texte est aligné à gauche, cela peut donner l’impression d’un simple label ; c’est un petit changement, mais il peut améliorer les conversions.
Je comprends que cela s’installe sur un serveur distant. Mais est-ce que cela fournit un environnement distant ou un environnement local ? Et que signifie exactement « environnement » dans ce contexte ? Un fichier Docker compose et un
.env? Le code ou une configurationvim? Une VM comme avec Vagrant ?Le principal problème actuel des
devcontainers, c’est que lorsqu’on exécute des apps GUI à distance, l’interface ne s’ouvre que sur le serveur. Je me demande si cette solution peut exporter l’interface graphique à distance.