> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrando para a configuração declarativa

> Passe da configuração clássica de ambiente para blueprints declarativos. O Devin pode cuidar de grande parte da migração para você.

A configuração declarativa (blueprints) é a nova geração da configuração de ambiente: com controle de versão, modular e atualizada automaticamente. Este guia orienta você na migração a partir do assistente interativo clássico.

<Warning>
  A configuração clássica de ambiente está sendo descontinuada. Há duas datas importantes que você precisa conhecer:

  * **30 de junho de 2026:** Todas as organizações passarão para a configuração declarativa (blueprints). Sua configuração clássica não será excluída, e você poderá reverter para ela.
  * **31 de julho de 2026:** Sua configuração clássica da máquina continuará disponível como referência até essa data, para que você possa consultá-la ou reverter para ela enquanto conclui a migração. Após 31 de julho, ela será removida.

  Faça a migração antes de 30 de junho de 2026 para evitar interrupções. Clientes Enterprise que precisarem de mais tempo devem entrar em contato com a equipe da conta.
</Warning>

<div id="why-migrate">
  ## Por que migrar?
</div>

Com o assistente de configuração clássico, o ambiente do Devin é um snapshot configurado manualmente que pode ficar defasado com o tempo. As dependências ficam desatualizadas, alterações de configuração exigem executar o assistente novamente, e não há histórico de versões. A configuração declarativa resolve isso:

* **Atualizações automáticas**: os blueprints são reconstruídos quando seu repositório muda, para que as dependências permaneçam atualizadas
* **Controle de versão**: a configuração do seu ambiente fica junto com seu código, com histórico completo
* **Combinável**: blueprints do Enterprise, da org e do repositório se combinam em camadas de forma organizada
* **Reproduzível**: cada build produz o mesmo resultado a partir do mesmo blueprint
* **Sessões mais rápidas**: snapshots são pré-construídos com repositórios clonados e dependências instaladas, para que as sessões já comecem prontas para uso

<Info>
  Sua configuração clássica continua funcionando até 30 de junho de 2026, depois permanece disponível para migração até 31 de julho de 2026, e você pode reverter sua organização para ela antes disso.
</Info>

<div id="before-you-start">
  ## Antes de começar
</div>

<AccordionGroup>
  <Accordion title="Verifique se sua org está qualificada">
    Procure um banner na página **Configuração da máquina** (a página clássica de configuração) com o texto **"Mudar para a configuração declarativa do ambiente"**. Se ele aparecer, sua organização está qualificada.

    Se você não vir o banner, a configuração declarativa ainda não foi ativada para sua organização. Ela está sendo liberada gradualmente. Entre em contato com o administrador do Enterprise ou acione o suporte.
  </Accordion>

  <Accordion title="Quem pode migrar">
    A migração exige permissões de **administrador da org** (`ManageOrgSettings`). Se você não for um administrador da org, verá a mensagem "Acesso de administrador necessário" na página de migração.
  </Accordion>

  <Accordion title="Isso é reversível?">
    Sim, até 31 de julho de 2026. Seu snapshot atual é preservado, então você pode reverter antes dessa data para fazer sua organização voltar a ele. Após 30 de junho, todas as organizações estarão na configuração declarativa, embora sua configuração clássica da máquina continue disponível para reversão até 31 de julho de 2026.
  </Accordion>
</AccordionGroup>

<div id="migration-steps">
  ## Etapas da migração
</div>

<div id="1-go-to-the-migration-page">
  ### 1. Acesse a página de migração
</div>

Navegue até **Configurações > migração de ambiente** ou clique em **Começar** no banner exibido na página de **Configuração da máquina**.

<div id="2-enable-declarative-configuration">
  ### 2. Ative a configuração declarativa
</div>

Clique em **Ativar para a organização**. Isso faz com que sua org use snapshots baseados em blueprints nas novas sessões.

<Info>Isso não afeta seu snapshot existente. Ele é preservado caso você precise reverter.</Info>

<div id="3-let-devin-generate-your-blueprints">
  ### 3. Deixe o Devin gerar seus blueprints
</div>

**Devin faz o trabalho para você.**

Clique em **Start migration** e selecione os repositórios que você quer migrar primeiro. Você não precisa migrar tudo de uma vez. Comece pelos repositórios que você mais usa.

Quando você inicia a migração, Devin cria **duas sessões**:

* Uma **sessão principal** em execução no novo ambiente declarativo, que gera os blueprints
* Uma **sessão auxiliar** em execução no seu snapshot existente, que Devin usa para inspecionar o que está instalado no momento (versões de linguagem, pacotes do sistema, serviços em execução etc.)

Devin examina seu snapshot existente, identifica quais ferramentas e dependências estão instaladas e gera a configuração de blueprint equivalente. Os resultados aparecem na sua página de **Configurações > Ambiente > Blueprints**.

<Tip>
  Seu snapshot existente é uma "caixa-preta" de tudo o que você configurou ao longo do tempo. Devin inspeciona esse snapshot, cataloga o que está instalado e registra tudo automaticamente em um blueprint reproduzível.
</Tip>

<div id="4-review-and-adjust">
  ### 4. Revisar e ajustar
</div>

Depois que Devin gerar os blueprints:

1. Vá para **Configurações > Ambiente > Blueprints** para revisar o que foi gerado
2. Verifique o status do build. Procure por **Success**.
3. Inicie uma sessão de teste para confirmar que tudo funciona:
   * Confirme se os repositórios foram clonados e se as dependências foram instaladas
   * Tente executar seus comandos de lint, teste e build
   * Verifique se as ferramentas ou runtimes personalizados estão disponíveis

Se algo estiver faltando, edite o blueprint diretamente. Você pode adicionar etapas de `initialize`, comandos de `maintenance` ou entradas de `knowledge`.

<div id="rolling-back">
  ## Reversão
</div>

Se algo não estiver funcionando, você pode reverter antes de 31 de julho de 2026:

1. Acesse **Configurações > Migração de ambiente**
2. Clique em **Reverter para o clássico**
3. Sua organização volta imediatamente a usar o snapshot anterior

Seu snapshot existente é totalmente preservado. Nada é perdido. Você pode tentar a migração novamente quando estiver pronto.

<Info>
  Após 30 de junho de 2026, todas as organizações passarão a usar configuração declarativa, mas sua configuração clássica da máquina continuará disponível para reversão até 31 de julho de 2026, quando será removida. Clientes Enterprise que precisarem de mais tempo devem entrar em contato com a equipe responsável pela conta.
</Info>

<div id="mapping-classic-setup-steps-to-blueprints">
  ## Mapeando etapas clássicas de configuração para blueprints
</div>

Se você preferir escrever seu blueprint manualmente (ou quiser entender o mapeamento), veja como as etapas do assistente clássico correspondem:

| Etapa clássica de configuração | Equivalente em blueprint           | Observações                                                                                            |
| ------------------------------ | ---------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Git pull                       | *Automático*                       | Os blueprints fazem `git clone` e `git pull` automaticamente                                           |
| Secrets                        | Aba Secrets no editor de blueprint | Configure na aba **Secrets** em cada editor de blueprint                                               |
| Instalar dependências          | `initialize`                       | Configuração única: runtimes de linguagem, pacotes do sistema e ferramentas globais                    |
| Manter dependências            | `maintenance`                      | Comandos de dependência apresentados ao agente no início da sessão: `npm install`, `pip install`, etc. |
| Lint                           | `knowledge` (`name: lint`)         | Apenas para referência, não é executado durante as builds                                              |
| Test                           | `knowledge` (`name: test`)         | Apenas para referência, não é executado durante as builds                                              |
| Executar o app                 | `knowledge` (`name: dev-server`)   | Apenas para referência, não é executado durante as builds                                              |
| Observações adicionais         | `knowledge`                        | Entradas livres para o Devin                                                                           |

<div id="example">
  ### Exemplo
</div>

**Configuração clássica:**

* Instale as dependências: `nvm use 20 && npm install`
* Mantenha as dependências atualizadas: `npm install`
* Lint: `npm run lint`
* Teste: `npm test`
* Execute o app: `npm run dev`

**Blueprint equivalente:**

```yaml theme={null}
initialize: |
  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  source ~/.bashrc
  nvm install 20

maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: dev-server
    contents: npm run dev
```

<div id="troubleshooting">
  ## Solução de problemas
</div>

<AccordionGroup>
  <Accordion title="Falha na build">
    Verifique os logs da build para identificar o erro específico. Causas comuns:

    * Um comando que funcionava no terminal de configuração clássico não funciona no contexto da build (por exemplo, prompts interativos que exigem flags `-y`)
    * Segredos ausentes (verifique se os segredos estão configurados na aba **Secrets** dentro do editor de blueprint)
    * Compare os comandos do blueprint com os comandos originais para identificar diferenças
  </Accordion>

  <Accordion title="Dependências ausentes nas sessões">
    Verifique se a seção `maintenance` inclui os mesmos comandos de instalação de dependências da etapa clássica **Maintain Dependencies**. Comandos como `npm install` ou `pip install -r requirements.txt`
    devem ficar em `maintenance`, não em `initialize`.
  </Accordion>

  <Accordion title="Devin não sabe como executar lint ou testes">
    Verifique se a seção `knowledge` contém itens chamados `lint` e `test` com os comandos corretos. Devin procura esses nomes ao verificar o próprio trabalho.
  </Accordion>

  <Accordion title="Alterações personalizadas no perfil do shell não são aplicadas">
    Se a configuração clássica modificava `~/.bashrc`, `~/.profile` ou outra configuração do shell, mova isso para `initialize`:

    ```yaml theme={null}
    initialize: |
      echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
      echo 'export NODE_ENV=development' >> ~/.bashrc
    ```
  </Accordion>

  <Accordion title="Git pull não está funcionando">
    Blueprints fazem o clone do git automaticamente durante as builds. Se os repositórios não estiverem sendo clonados, verifique se eles foram adicionados na página **Configurações > Ambiente > Blueprints** e se o Devin tem acesso por meio da sua integração com Git.
  </Accordion>
</AccordionGroup>

<div id="related-pages">
  ## Páginas relacionadas
</div>

* [Configuração declarativa de ambiente](/pt-BR/onboard-devin/environment/blueprints)
* [Referência de blueprint](/pt-BR/onboard-devin/environment/blueprint-reference)
* [Biblioteca de templates](/pt-BR/onboard-devin/environment/templates)
