Desenvolvimento remoto simplificado com DevPod - uma ferramenta gratuita e de código aberto

Cheguei relativamente tarde ao assunto de Ambientes de Desenvolvimento Remoto (também conhecidos como Ambientes de Desenvolvimento em Nuvem). O principal motivo é que não trabalho em uma equipe de desenvolvimento há mais de seis anos. No entanto, agora estou trabalhando para a Loft Labs, e temos um produto de Ambiente de Desenvolvimento Remoto: DevPod . Eu queria entender nossa proposta de valor, pois estarei na FOSDEM operando o estande do DevPod .

O Problema

Como ex-desenvolvedor, lembro-me vividamente da dor de configurar o ambiente de desenvolvimento de cada desenvolvedor. No início da minha carreira, o arquiteto teve que configurar minha máquina de desenvolvimento dolorosamente, então era semelhante à configuração dele. Mais tarde, fiz o mesmo para os membros da minha equipe repetidamente. O escopo de possíveis discrepâncias que impactam o desenvolvimento é virtualmente infinito: Sistema operacional, é claro, versão e sabor dos SDKs, por exemplo , Eclipse Temurin vs SapMachine do Java, git hooks, etc. Foi suor, trabalho e sangue em cada projeto.

Ao longo dos anos, vi algumas abordagens interessantes para reproduzir ambientes de desenvolvimento. No começo, elas vinham de VMs, depois de contêineres. Acho que o Vagrant foi a primeira ferramenta que chamou minha atenção: assisti a uma palestra em 2012, onde o palestrante mencionou que ele a usava para configurar máquinas antes de suas sessões de treinamento.

As arquiteturas de aplicativos evoluíram significativamente ao longo dos anos, tornando-se mais complexas e sofisticadas. Anos atrás, as chances eram de que a única dependência de infraestrutura fosse um banco de dados SQL. No ecossistema JVM, tivemos a sorte de ter JDBC, uma API que funcionaria em todos os bancos de dados SQL. Tudo o que você precisava fazer era escrever SQL padrão, e você poderia configurar a instância do banco de dados em tempo de execução. Com bancos de dados incorporados, como Apache Derby e H2 , você não precisava de uma instância Oracle dedicada para cada desenvolvedor.

Os tempos mudaram. Não é incomum que aplicativos precisem de um banco de dados SQL, um banco de dados NoSQL, um cluster Kafka e alguns serviços de aplicativo adicionais. Organizações que desenvolvem esses aplicativos já estão usando alguma tecnologia relacionada a contêineres, por exemplo , Docker ou Kubernetes, para gerenciar essa complexidade.

Mas isso não resolve o problema inicial: como você alinha o IDE, seus plugins, o(s) SDK(s), os git hooks e tudo mais? Você provavelmente adivinhou pelo título - Ambientes de Desenvolvimento Remoto.

Contêineres de desenvolvimento

Na introdução, mencionei que RDEs são chamados de Cloud Development Environments. A ideia principal por trás dos RDEs é armazenar tudo o que você puder em uma Cloud e compartilhar com todos os desenvolvedores. Além disso, você quer que eles funcionem nos provedores de Cloud mais difundidos e nos IDEs mais comumente usados. Quando tal necessidade aparece, é hora de os atores da indústria se reunirem em torno de um padrão. A Microsoft iniciou o padrão Development Container para seu plugin de desenvolvimento VS Code Remove para esse propósito exato.

Um contêiner de desenvolvimento (ou contêiner dev para abreviar) permite que você use um contêiner como um ambiente de desenvolvimento completo. Ele pode ser usado para executar um aplicativo, para separar ferramentas, bibliotecas ou tempos de execução necessários para trabalhar com uma base de código e para auxiliar na integração e teste contínuos. Os contêineres dev podem ser executados local ou remotamente, em uma nuvem privada ou pública, em uma variedade de ferramentas e editores de suporte.

A Especificação de Contêiner de Desenvolvimento busca encontrar maneiras de enriquecer formatos existentes com configurações, ferramentas e configurações específicas de desenvolvimento comuns, ao mesmo tempo em que fornece uma opção de contêiner único simplificada e não orquestrada – para que possam ser usados como ambientes de codificação ou para integração e testes contínuos. Além dos metadados principais da especificação, a especificação também permite que os desenvolvedores compartilhem e reutilizem rapidamente as etapas de configuração do contêiner por meio de Recursos e Modelos.

-- O que são contêineres de desenvolvimento?

O arquivo de configuração é devcontainer.json . Você pode encontrar a referência do esquema aqui . Os produtos VS Code, Visual Studio e IntelliJ podem aproveitar um arquivo devcontainer.json . No lado do provedor, GitHub Codespaces, CodeSandbox e DevPod o suportam.

Apresentando o DevPod

DevPod é uma solução que alavanca devcontainer.json . Ele implementa três propriedades principais:

• Código aberto: sem dependência de fornecedor. 100% gratuito e de código aberto, criado por desenvolvedores para desenvolvedores.

• Somente cliente: Nenhuma configuração do lado do servidor necessária. Baixe o aplicativo de desktop ou o CLI para começar.

• Sem opinião: ambiente de desenvolvimento repetível para qualquer infraestrutura, qualquer IDE e qualquer linguagem de programação.

O DevPod foi projetado para ser fácil de usar e direto, tornando-o fácil de usar. Decidi escrever este post porque fiquei impressionado com o produto e para colocar meus pensamentos em ordem.

O primeiro passo é instalar o DevPod em si. Estou no Mac; há uma receita do Homebrew.

 brew install devpod

Uma vez instalado, você pode iniciá-lo a partir da CLI ou da GUI. Eu prefiro GUIs, no começo, para ajudar a entender as opções disponíveis.

O DevPod oferece provedores: locais onde executar os contêineres. O padrão é Docker. Você pode adicionar provedores adicionais, incluindo Cloud Providers e clusters Kubernetes.

Para esta publicação, vou manter o Docker — estou usando o OrbStack. Agora, vamos ao que interessa. Vamos ao item de menu workspaces. Se você já criou workspaces, eles devem aparecer aqui. Como é nossa primeira visita, criaremos um. Clique no botão btn:[Create workspace]. Vamos tentar um dos exemplos de início rápido, ou seja , Rust. Meu IDE de escolha é o IntelliJ IDEA, mas você pode escolher o seu. Depois de selecionar uma imagem, um IDE e um provedor, clique em Create Workspace.

Neste ponto, o DevPod baixará a imagem e abrirá o projeto em execução no OrbStack no IntelliJ.

A partir de agora, podemos começar a trabalhar alegremente em nosso projeto Rust, confiantes de que todos os membros da equipe usarão a mesma versão do Rust.

Note que na primeira vez que você usar essa configuração, o DevPod baixará o cliente JetBrains também. Mas é um atraso de download único.

O mesmo vale para os hooks de pré-commit do Git, por exemplo. Se você preferir desenvolver dentro de outro IDE, selecione-o no momento do lançamento e pronto. Quando terminar o trabalho do seu dia, pare o contêiner. Se você estiver executando na Nuvem, isso economiza dinheiro. No dia seguinte, retome o contêiner e continue seu trabalho.

Conclusão

DevPod é uma ferramenta bacana em volta do seu cinto de ferramentas que permite que sua(s) equipe(s) de desenvolvimento compartilhe(m) a mesma configuração de máquina sem problemas. Nesta postagem de blog introdutória, mostrei uma pequena fração do que você pode fazer. Eu o encorajo a aproveitar seu poder se enfrentar ambientes de desenvolvimento heterogêneos.

Para ir mais longe:

• Contêineres de desenvolvimento
• DevPod - Ambientes de desenvolvimento de código aberto como código
• Gitpod vs. Codespaces vs. Coder vs. DevPod: Comparação de 2024