- Auto-hospedagem simples: projetado para permitir instalação e manutenção com o mínimo de esforço. O aplicativo foi feito para funcionar sem exigir solução de problemas internos complexos.
- Escalabilidade horizontal: com uma estrutura simples, mas poderosa, o Lapdev pode escalar de uma única máquina até uma frota de servidores, oferecendo um sistema de gerenciamento de ambientes de desenvolvimento que pode crescer junto com a equipe de desenvolvedores.
- Ambientes de desenvolvimento definidos como código: usando a especificação aberta do Devcontainer, é possível definir ambientes de desenvolvimento como código, reproduzindo ambientes padronizados entre diferentes desenvolvedores para evitar problemas relacionados ao ambiente e garantir uma configuração consistente para todos.
- Economia de tempo no onboarding: ao integrar desenvolvedores em um novo projeto, não é necessário gastar horas ou dias preparando o ambiente na máquina. É possível começar a programar imediatamente.
Recursos planejados
- Suporte a vários tipos de workspace: atualmente, o Lapdev oferece suporte apenas a workspaces baseados em contêineres, mas isso traz limitações, por exemplo, quando se deseja executar um cluster k8s no fluxo de desenvolvimento. O suporte a VMs e máquinas bare metal está no roadmap, e também há planos para compatibilidade com vários sistemas operacionais, como Windows, Linux e macOS. Com isso, os desenvolvedores poderão desenvolver e depurar na mesma máquina local sem precisar alternar de equipamento.
Opinião do GN⁺
- O Lapdev é uma ferramenta que facilita a configuração e o gerenciamento de ambientes de desenvolvimento remoto em servidores próprios ou na nuvem, podendo aumentar a eficiência ao viabilizar a padronização do ambiente e um onboarding mais rápido.
- Ferramentas desse tipo podem ser especialmente úteis para equipes de desenvolvimento grandes ou organizações que conduzem vários projetos ao mesmo tempo, pois oferecem escalabilidade ao mesmo tempo em que mantêm a consistência do ambiente de desenvolvimento.
- No entanto, antes de adotar essa tecnologia, pode haver questões a considerar relacionadas a segurança, compatibilidade e suporte, além da carga adicional de manutenção que pode surgir ao usar uma solução auto-hospedada.
- Atualmente, existem outras ferramentas no mercado que oferecem funcionalidades semelhantes, como as Remote Development Extensions do Visual Studio Code, e os usuários devem escolher a ferramenta mais adequada às suas necessidades.
- O fato de o Lapdev planejar suporte a VMs e máquinas bare metal pode ser visto como parte de um esforço para atender a diferentes necessidades de ambientes de desenvolvimento, o que deve oferecer aos desenvolvedores um leque mais amplo de opções.
1 comentários
Comentários no Hacker News
Parece muito bom poder usar contêineres de desenvolvimento (devcontainers) em hardware de servidor local sem taxa mensal. Até agora eu vinha usando Docker-compose e desenvolvimento remoto via SSH do JetBrains, mas espero que essa nova abordagem seja bem melhor.
Tenho interesse em ambientes de desenvolvimento remotos, mas não fico muito animado com a ideia de gerenciar ainda mais software na nuvem. Acho uma boa ideia usar o Skypilot, já que ele tem plugins para APIs de nuvem e permite iniciar máquinas de desenvolvimento sem precisar gerenciar um cluster k8s. Funcionou melhor para iniciar um servidor Jupyter, mas uma máquina de desenvolvimento “completa” parece viável com apenas algumas configurações de SSH/VS Code.
Ambientes de desenvolvimento remotos podem ser limitados para certos tipos de desenvolvimento. Por exemplo, desenvolvimento de apps iOS e Android pode ser complicado, ou no desenvolvimento de jogos que exige GPU o download dos artefatos de build pode ser lento. Fico curioso se existe algum guia para resolver isso.
Gostaria de saber mais sobre ferramentas desse tipo. Vi que o Coder inclui suporte alfa para
.devcontainer, mas não conheço outras opções OSS.Com uma configuração usando Proxmox, dá para clonar uma VM/contêiner existente e simplesmente apontar o VSCode para ela. O que exatamente isso acrescenta? Não é automação, porque dá para automatizar alguns cliques no Proxmox, nem gerenciamento de recursos, porque o Proxmox já cuida de armazenamento etc. É a identidade do desenvolvedor? Se isso for a única coisa necessária, eu teria que escrever um script relativamente simples para distribuir chaves SSH nos ambientes.
Pela experiência que tive de precisar instalar juntos o code-server, que é o VSCode hospedado em uma máquina remota, e o SSH, uma experiência em que ambos sejam melhor gerenciados é bem interessante.
Outra implementação nessa área é o devpod.sh.
Dou uma dica de design: centralizem o texto do botão para que ele pareça mesmo um botão. Se o texto ficar alinhado à esquerda, pode parecer um rótulo; é uma mudança pequena, mas pode melhorar a conversão.
Entendo o que está instalado no servidor remoto. Mas isso fornece um ambiente remoto ou um ambiente local? E o que significa “ambiente” nesse contexto? É um arquivo Docker compose e um
.env? É o código ou a configuração do vim? É uma VM como o Vagrant?O principal problema atual dos devcontainers é que, ao executar apps com GUI remotamente, a interface só abre no servidor. Fico curioso se essa solução consegue exportar a GUI remotamente.