Você não precisa escrever isso manualmente. A forma mais fácil de configurar seu ambiente é iniciar uma sessão do Devin e pedir que ele configure o repo. O Devin analisará o projeto, instalará dependências e proporá uma configuração — você clica em Approve nos cartões de sugestão na sua timeline.Este guia é para quando você quiser entender o que o Devin gerou, personalizá-la ou escrever uma configuração do zero.
O Devin roda em sua própria VM. Cada sessão é iniciada a partir de uma imagem da máquina — um snapshot salvo com suas ferramentas, repositórios e dependências pré-instalados. Você controla o que entra nessa imagem editando a configuração do seu ambiente em Configurações > Ambiente do Devin.
Use initialize para qualquer coisa lenta ou que só precise acontecer uma vez: instalar gerenciadores de pacotes, ferramentas globais de CLI, compilar dependências nativas ou adicionar pacotes do sistema.Os resultados ficam salvos na imagem da máquina e não são executados novamente no início da sessão.
A string multilinha é executada como um único script bash com set -e, então qualquer linha que falhar interrompe o build. Use \ para continuação de linha ou mude para a forma expandida para etapas nomeadas que aparecem individualmente nos logs de build.
O arquivo de segredos é removido antes de a imagem da máquina ser salva. Se um comando em initialize gravar um valor secreto em um arquivo de configuração (por exemplo, um token de autenticação em .npmrc), esse valor pode permanecer na imagem — o que representa um risco de segurança. Em vez disso, coloque as etapas de gravação de credenciais em maintenance, onde os segredos são carregados novamente a cada sessão.
Quando precisar de etapas nomeadas, use o formato de lista. Etapas nomeadas tornam os logs de build mais fáceis de depurar — quando algo falhar, você verá em qual etapa ocorreu a falha em vez de apenas um número de linha.
Para definir variáveis de ambiente para as etapas seguintes, grave linhas KEY=VALUE no arquivo $ENVRC (como o $GITHUB_ENV do GitHub Actions). Todas as variáveis gravadas em $ENVRC são exportadas automaticamente para as etapas seguintes e para a sessão do Devin.
Use maintenance para manter as dependências atualizadas e gravar arquivos de configuração de credenciais.Ele é executado durante o build (após initialize) e no início de cada sessão, após puxar a versão mais recente do código. Como ele é executado no início de toda sessão, os comandos devem ser rápidos e incrementais.
Use npm install, não npm ci.npm ci exclui node_modules e reinstala tudo do zero a cada execução. npm install faz uma atualização incremental, que é muito mais rápida quando as dependências não mudaram.
Qualquer etapa que escreva segredos em arquivos de configuração (.npmrc, settings.xml, pip.conf) deve ficar em maintenance, não em initialize. Isso mantém as credenciais atualizadas no início de cada sessão.
knowledge — notas específicas do ambiente (opcional)
Use knowledge para pequenas informações de configuração de que o Devin precisa para realmente usar o ambiente que você acabou de criar — coisas como o comando de lint, o comando de teste ou como iniciar o servidor de desenvolvimento.
Isso não é a mesma coisa que o recurso principal Knowledge. Para a maioria das coisas que você quer que o Devin lembre — arquitetura, convenções, detalhes importantes, workflows da equipe — use o recurso independente Knowledge. Ele tem gatilhos mais avançados, é mais fácil de editar e é o lugar certo para o contexto geral do projeto.Use a seção knowledge em environment.yaml apenas para notas curtas diretamente ligadas à configuração do ambiente neste arquivo (por exemplo, “o comando de lint é npm run lint”). Esta seção é opcional, e a maioria dos ambientes não precisa dela.
As entradas são notas de referência — elas não são executadas. Mantenha-as curtas:
knowledge: - name: lint contents: | Run `npm run lint` to check for errors. Run `npm run lint:fix` to auto-fix. - name: test contents: | Run `npm test` for the full suite. Run `npm test -- --watch` during development. - name: startup contents: | Run `npm run dev` to start the dev server on port 3000.
O Devin oferece suporte a três níveis de configuração. Os comandos de cada nível são estritamente aditivos — eles são executados em sequência durante as builds, e os níveis inferiores não podem substituir nem modificar o que os níveis superiores configuram.
Nível
Onde configurar
O que colocar aqui
Exemplos
Em toda a conta (Enterprise)
Configurações do Enterprise > Environment
Infraestrutura de que todas as orgs precisam
certificados de CA, proxy corporativo, VPN, DNS
Nível da organização
Configurações > Environment > Configuração em toda a organização
Ferramentas e configuração compartilhadas em todos os repositórios
runtimes de linguagem (pnpm, uv), autenticação do Docker, ferramentas de CLI compartilhadas
Específico do repositório
Configurações > Environment > [repo]
Configuração e conhecimento específicos do projeto
npm install, comandos de lint/test/build, notas de arquitetura
Como decidir o que vai em cada lugar:
Se toda org no seu Enterprise precisar disso → em toda a conta
Se todo repositório na sua org precisar disso → nível da organização
Se apenas um repositório precisar disso → específico do repositório
Usuários do Enterprise: Para orientações detalhadas sobre configuração no nível do enterprise — permissões, build em cascata, gerenciamento de várias orgs e migração para o Enterprise — consulte a página Enterprise Environment Setup.
Sua organização tem uma imagem da máquina — um snapshot de uma VM com suas ferramentas, repositórios e dependências pré-instalados. Todos os repositórios configurados são clonados e configurados nessa única imagem. Cada sessão é iniciada a partir de uma cópia nova.
Uma build cria uma nova imagem da máquina na seguinte ordem:
1. Configuração Enterprise (executada em ~): a. initialize b. maintenance2. Configuração em nível da organização (executada em ~): a. initialize b. maintenance3. Clonar todos os repositórios (até 10 simultâneos)4. Para cada repo configurado, na ordem exibida em Configurações (executada em ~/repos/<repo-name>): a. initialize b. maintenance5. Verificação de integridade, e a imagem é salva
As camadas são aditivas: comandos específicos do repo podem usar ferramentas instaladas pela configuração em nível da organização ou do Enterprise. Níveis inferiores não podem sobrescrever o que um nível superior configurou.Os builds normalmente levam de 5 a 15 minutos. Comandos individuais expiram após 1 hora; o build inteiro expira após 2 horas.
Cada sessão inicializa uma nova cópia da imagem da máquina. Quando a sessão termina, todas as mudanças são descartadas.No início da sessão:
As execuções de maintenance do Enterprise e em nível da organização são executadas (em ~).
O código mais recente é obtido do(s) repositório(s) relevante(s).
O maintenance desse repositório é executado novamente para capturar mudanças nas dependências desde a última build.
As entradas de Knowledge desse repositório são carregadas no contexto do Devin.
Knowledge é por repositório. Se você tiver 5 repositórios configurados, o Devin verá apenas as entradas de Knowledge daquele em que estiver trabalhando.
Todas as etapas foram concluídas. A imagem da máquina está pronta.
Partial
Alguns repositórios falharam, mas a build principal foi bem-sucedida. As sessões funcionarão, mas alguns repositórios podem não estar totalmente configurados.
Failed
A build principal falhou (por exemplo, falha na clonagem ou na configuração de Enterprise/org).
Na interface de Configurações do ambiente, os repositórios aparecem em três estados:
Estado
Significado
Configurado
Tem configuração YAML com initialize/maintenance/knowledge. Totalmente configurado na imagem da máquina.
Incluído
Clonado na imagem da máquina, mas sem configuração personalizada. Devin pode acessar o código.
Disponível
Acessível à org, mas não adicionado ao ambiente. Não clonado.
Incluído vs. configurado: Um repo “incluído” é clonado para que Devin possa acessar o código, mas não tem comandos personalizados de configuração. Um repo “configurado” tem instruções explícitas de initialize/maintenance/knowledge.
Os segredos ficam disponíveis como variáveis de ambiente durante builds e sessões. O arquivo de segredos é removido antes que a imagem da máquina seja salva — mas, se um comando expandiu um valor secreto em um arquivo de configuração durante initialize, esse valor expandido pode persistir na imagem. Em vez disso, sempre grave as credenciais em maintenance, onde elas são recarregadas a cada sessão.Para saber mais sobre gerenciamento de segredos, consulte Segredos & Site Cookies.
Quando você configura vários repositórios, cada um recebe seu próprio YAML em Configurações. Durante um build, todos são configurados na mesma imagem — clonados em diretórios separados, com dependências instaladas de forma independente. Durante uma sessão, apenas a manutenção e o Knowledge do repositório ativo são relevantes.E se dois repositórios entrarem em conflito? Os comandos de cada repositório são executados em seu próprio diretório, então conflitos de dependências são raros. Se dois repositórios instalarem versões diferentes de uma ferramenta global ou modificarem arquivos compartilhados (como ~/.bashrc), prevalece o último a ser executado. Coloque as instalações de ferramentas compartilhadas na configuração em nível da organização para evitar isso.
Em um monorepo, você escreve um único YAML que abrange todos os subprojetos. Use subshells para executar comandos em subdiretórios sem alterar o diretório de trabalho das etapas subsequentes:
Os parênteses (cd ... && ...) são importantes — eles executam o comando em um subshell, fazendo com que o diretório de trabalho seja redefinido para a próxima etapa.Quando usar configuração multi-repo vs. monorepo: Se o código estiver em um único repositório Git, use um YAML com subshells. Se estiver distribuído em vários repositórios Git, configure cada repo separadamente em Configurações.
