Transcript
00:00:00o seu readme está mentindo para você, ele diz que a configuração leva cinco minutos, depois o node está errado, o python está errado
00:00:07o postgres está faltando, o docker está demorando uma eternidade e agora estamos depurando antes mesmo de começar
00:00:13o seu ambiente de desenvolvimento não deveria viver em um readme, deveria viver no git, é isso que o devbox faz
00:00:20um arquivo json do devbox, um comando devbox shell, o mesmo ambiente para todo desenvolvedor sem instalações globais
00:00:28e sem necessidade de conhecimento em nix, deixe-me mostrar
00:00:30à primeira vista, o devbox parece simples demais, você cria um devbox json e lista as ferramentas que seu projeto precisa
00:00:42node, go, python, postgres, o que seu stack realmente precisar, você faz o commit desse arquivo e qualquer outra pessoa pode apenas
00:00:50rodar o devbox shell e eles obtêm o mesmo ambiente que você, as mesmas versões, ferramentas, scripts, sem instalações globais
00:00:58nada de "por favor, instale estas oito coisas primeiro", nada de configurações de homebrew de anos atrás, sua configuração
00:01:03deixa de viver na memória de alguém e começa a viver no seu repositório, isso parece pequeno, mas se você já
00:01:09perdeu metade de um dia com uma configuração local quebrada, você já sabe que isso não é pequeno, se você gosta
00:01:16de ferramentas de código para acelerar seu fluxo de trabalho, inscreva-se, temos vídeos saindo o tempo todo
00:01:20agora, estamos começando aqui, então vou começar com um projeto vazio, vou criar uma nova pasta
00:01:25vamos chamar de devbox demo, entramos na pasta e tudo o que precisamos fazer, uma vez que temos o devbox, é rodar
00:01:31devbox init, o devbox cria um arquivo chamado devbox json, agora ele está basicamente vazio, é apenas o
00:01:39boilerplate que o devbox nos dá, agora vamos adicionar as ferramentas que este projeto realmente precisa, para adicionar ferramentas podemos
00:01:45criar um devbox add e vou instalar coisas como go, node.js e um pouco de python, agora aqui está o
00:01:52ponto importante: não estou instalando isso globalmente, não estou alterando meu node do sistema, não estou mexendo no meu sistema
00:02:00com python, essas ferramentas pertencem a este projeto, agora quando eu rodo o devbox shell e estou dentro de um projeto limpo
00:02:09ambiente, agora que você está neste ambiente, você pode simplesmente verificar as versões, certo? go version, node
00:02:14version, python version, certo? eu posso verificar tudo para ter certeza de que está rodando, agora essa é a grande vantagem
00:02:19o projeto pediu ferramentas específicas, o devbox me deu essas ferramentas, agora vamos adicionar um script e dentro do devbox
00:02:27json nós podemos definir um teste, e eu vou apenas ecoar esses testes rodando e vou pegar o node
00:02:34e a versão do go, quando você roda o devbox run test e agora esse mesmo comando funciona para qualquer pessoa usando este repositório
00:02:42mesmo script, mesmas ferramentas, mesmo ambiente, agora veja o que acontece quando eu saio, você pode simplesmente rodar exit
00:02:48você vai sair daquele ambiente e eu volto para o meu ambiente de máquina normal, então isso foi bem
00:02:53simples, certo? o que o devbox está fazendo afinal? bem, o devbox usa nix por baixo de tudo, o nix é ótimo porque
00:03:00ele foi construído para reprodutibilidade, em vez de dizer "instale o que quer que seja a versão mais recente hoje"
00:03:06ele pode fixar as ferramentas exatas que seu projeto realmente precisa, agora essa é a parte boa, a parte difícil é
00:03:12que o nix pode parecer um mundo totalmente novo, existem muitos conceitos que são ótimos, mas não exatamente
00:03:18amigáveis quando tudo o que você queria era a versão certa do node, o devbox mostra algo diferente
00:03:23aqui ele diz: "e se mantivéssemos a reprodutibilidade, mas tornássemos o fluxo de trabalho natural?" então, em vez de
00:03:29escrever expressões nix, você pode usar comandos como devbox add, devbox search, shell, run, services, todos
00:03:37esses comandos são muito mais simples e seu projeto ganha dois arquivos importantes, você recebe um arquivo json e um
00:03:44arquivo lock, pense no devbox json como o que nosso ambiente precisa, pense no arquivo de lock do devbox como o pino para fixar
00:03:52exatamente o que você obteve, você faz o commit de ambos, agora seu ambiente não é apenas um parágrafo em um arquivo readme
00:03:58é parte do projeto real, o devbox funciona no mac os, linux e wsl, ele pode integrar com vs code, ele pode
00:04:06definir scripts, ele pode gerenciar serviços como bancos de dados e, quando você precisar, ele pode exportar para coisas como
00:04:12docker, dev containers e fluxos de trabalho de ci, o valor disso não é apenas "ferramenta legal", é uma ferramenta incrivelmente simples, o
00:04:19valor é, eu acho, apenas tempo, o primeiro problema é o readme, certo? o readme poderia dizer realmente qualquer coisa, ele
00:04:26poderia dizer "ei, instale o node 18", mas o aplicativo mudou, ele realmente precisa do node 20, o segundo problema
00:04:32que isso realmente ajuda é no onboarding, é seu primeiro dia de trabalho, deveria ser fácil começar
00:04:37nós sabemos que esse não é o caso, certo? então você não deveria precisar perguntar "qual versão do node eu preciso?", você não deveria
00:04:43precisar mandar uma mensagem para alguém: "ei, qual versão do python estamos usando? eu realmente preciso de postgres localmente e por que
00:04:48isso só funciona para o timmy ali?" eles deveriam apenas clonar o repositório, entrar no shell
00:04:52e rodar o projeto, se algo quebrar, pelo menos todos estão começando do mesmo ambiente, o problema
00:04:58é a poluição global, tentar ferramentas não deveria destruir seu laptop, você quer go 1.22 para este repo, você adiciona, você
00:05:06quer node 20 aqui, mas outra coisa em outro lugar, tudo bem, isso é bom, as ferramentas vivem com o projeto, seu
00:05:13sistema permanece mais limpo com o devbox, sua definição de ambiente pode ser compartilhada entre o desenvolvimento local
00:05:18e automação, isso resolve todos os problemas de ci? não, não vai, mas remove uma enorme categoria de problemas
00:05:26bobos, e problemas bobos são os que mais nos machucam, eles são simples e ainda os temos o tempo
00:05:32todo, finalmente, aqui está o docker, fluxo de trabalho docker local pesado, mais especificamente, o docker ainda é ótimo, de longe, se
00:05:40você precisa de contêineres, use contêineres, mas muitas equipes usam docker localmente porque não têm uma maneira melhor
00:05:46de gerenciar ferramentas, agora, o que é bom aqui é que o fluxo de trabalho é incrivelmente simples, devbox add, shell, run, você
00:05:52não tem que aprender tanto, o ambiente se torna uma parte real do seu projeto, um arquivo real
00:05:57no repo, quando todos usam as mesmas versões e scripts, a depuração fica mais fácil, mas isso é ótimo,
00:06:03super simples, o que vai te irritar é, bem, o primeiro download do nix demorou um pouco para baixar
00:06:09está tudo bem, é a primeira vez, tudo bem, json é simples, mas pode ficar feio como sabemos, se adicionarmos demais
00:06:15dentro dele, para scripts básicos é bom, para lógica de configuração complexa não enfie um comando shell gigante no json
00:06:22apenas coloque a lógica em um arquivo sh, então chame isso do devbox, e finalmente o devbox não é um ide em nuvem completo
00:06:30se você precisa de codificação baseada em navegador, urls de visualização instantânea, você ainda pode querer algo como code spaces
00:06:36o devbox é melhor na reprodutibilidade local e de ci, o devbox não vai resolver todos os problemas de desenvolvimento
00:06:42mas pode resolver os que mais nos irritam, que é realmente apenas fazer o projeto
00:06:46rodar, então pode valer a pena tentar, especialmente se seu projeto tem mais de uma linguagem ou mais de
00:06:51uma ferramenta cli, se você gosta de ferramentas de código como esta, certifique-se de se inscrever no canal better stack, nós
00:06:56nos vemos em outro vídeo.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video