> ## 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 o seu Enterprise > Implantação progressiva da configuração declarativa de ambiente em todo o seu Enterprise: estados de implantação, substituições por org, playbook de migração em fases e monitoramento. Migrar o Enterprise da configuração clássica de ambiente para a configuração declarativa é uma mudança significativa. A página Rollout dá aos admins do Enterprise controle granular sobre essa transição. Você pode ativar blueprints para algumas orgs piloto, expandir no seu próprio ritmo e reverter instantaneamente se algo der errado.
## Estados de rollout no Enterprise
A página de Rollout apresenta um seletor de **modo de rollout** que controla como os blueprints ficam disponíveis para as organizações. Há três modos, além de um estado inicial antes de os ambientes declarativos serem ativados: | Estado | O que significa | Efeito nas organizações | | ---------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Não ativado** | Os ambientes declarativos ainda não foram ativados para o Enterprise | Nenhuma org vê as páginas de ambiente. Todas as orgs usam a configuração clássica. Entre em contato com seu administrador da Cognition para ativar. | | **Testing** | Apenas organizações ativadas manualmente usam ambientes declarativos | O administrador do Enterprise inclui orgs específicas pela página de Rollout. Todas as outras orgs permanecem na configuração clássica e não veem nenhuma mudança. | | **Disponível** | Os administradores da org veem um prompt de migração e podem fazer a mudança por conta própria | Os administradores da org que estão na configuração clássica veem um aviso de migração na página Configuração da máquina. Eles podem migrar por conta própria, sem intervenção do administrador do Enterprise. | | **Ativado por padrão** | Novas organizações passam a usar ambientes declarativos por padrão | Todas as novas orgs começam com blueprints. As orgs existentes que estavam na configuração clássica com repos recebem overrides clássicos automáticos. | A progressão é: **Testing → Disponível → Ativado por padrão**. Você pode alternar livremente entre **Testing** e **Disponível** usando o menu suspenso do modo de rollout. No entanto, **Ativado por padrão** é uma ação permanente que não pode ser desfeita sem um administrador da Cognition. **Ativado por padrão é permanente.** Depois que você ativar esse modo, não será possível revertê-lo para Testing ou Disponível sem entrar em contato com seu administrador da Cognition. Certifique-se de que seu enterprise blueprint esteja totalmente validado e de que a maioria das orgs já esteja usando blueprints antes de ativar esse modo.
### Detalhes do modo de teste
No modo de teste, as organizações que ainda não aderiram continuam usando a configuração clássica e não veem nenhuma mudança na experiência. O admin do Enterprise pode incluir orgs individuais pela página de Rollout. Apenas essas orgs passam para a configuração declarativa. Este é o modo base quando ambientes declarativos são ativados pela primeira vez para um Enterprise.
### Detalhes do modo disponível
O modo disponível adiciona um aviso de migração: admins de org que ainda usam a configuração clássica veem um aviso na página de Machine Configuration incentivando a migração para a configuração declarativa. Isso não altera a configuração nem dá acesso às páginas completas de configuração do ambiente. Apenas informa que os blueprints estão disponíveis e oferece um caminho de autoatendimento para aderir. Isso é útil para gerar conscientização e permitir que admins de org façam a migração no próprio ritmo.
## Overrides por org
Os admin do Enterprise podem substituir o estado de rollout de organizações individuais diretamente na tabela por org na página Rollout: * **No modo Testing ou Available**: **Inclua** orgs específicas nos blueprints. Essas orgs passam da configuração clássica para a configuração declarativa imediatamente. * **No modo Enabled by default**: **Retire** orgs específicas dos blueprints para que voltem à configuração clássica. Essas orgs continuam usando a configuração clássica. Os overrides são persistentes. Eles permanecem mesmo com mudanças de modo. Se você incluir uma org nos blueprints durante o modo Testing, ela continuará nos blueprints quando fizer a transição para Available ou Enabled by default.
### Overrides automáticos do clássico
Ao ativar **Ativado por padrão**, um mecanismo de segurança evita interrupções: qualquer org que esteja atualmente na configuração clássica **e tenha repositórios configurados** recebe automaticamente um override explícito para o modo clássico. Isso significa que a transição não muda nada para orgs que estão usando ativamente a configuração clássica. Elas continuam como estão até que você as migre explicitamente. Orgs sem repositórios (ou orgs que já estejam em blueprints) não são afetadas por essa proteção. A melhor abordagem é fazer o build e validar sua configuração de forma isolada antes de disponibilizá-la aos admins da org. Evite uma migração de uma só vez. Comece de forma controlada, verifique e depois expanda.
### Fase 1: Criar e verificar em isolamento (Teste)
Comece com o Enterprise no modo **Teste**. As org não podem aderir por conta própria, então você tem controle total. 1. **Ative os ambientes declarativos** para o Enterprise. Seu administrador da Cognition ativa o recurso, o que coloca o Enterprise no modo Teste. 2. **Crie uma org de teste dedicada** para testar a configuração do ambiente. Essa org existe exclusivamente para validar seus blueprints. 3. **Ative a configuração declarativa** somente para essa org de teste (por meio de um override por org na página Rollout). 4. **Configure o blueprint do seu Enterprise**: instale todos os runtimes de linguagem compartilhados, ferramentas de segurança, certificados corporativos, CLIs internos, configurações de proxy e autenticação de registro. Essa é a camada base que todas as org herdarão. 5. **Configure um blueprint de org** para a org de teste com quaisquer ferramentas no nível da org ou configuração de registro. 6. **Adicione blueprints de repositório** para um conjunto representativo de repositórios. Escolha repos que cubram suas stacks de tecnologia mais comuns. 7. **Verifique de ponta a ponta**: inicie sessões do Devin nesses repos e confirme que tudo funciona. Os repos devem ser clonados, as dependências instaladas, os comandos de lint/test/build executados corretamente e todas as ferramentas devem estar nas versões esperadas. Não verifique apenas se os builds foram bem-sucedidos. Um build verde nem sempre significa um ambiente funcional. Uma entrada PATH ausente, uma versão incorreta de ferramenta ou autenticação de registro ausente podem passar despercebidas. Sempre verifique executando uma sessão real do Devin.
### Fase 2: Ativar a adesão opcional para admins da org (Available)
Depois de confirmar que sua pilha de blueprints Enterprise → org → repo funciona corretamente em conjunto e produz ambientes funcionais: 1. **Comunique internamente** aos admins da org que a configuração declarativa está disponível e pronta para uso. 2. **Alterne para o modo Available**: mude o menu suspenso "Rollout mode" de "Testing" para "Available". Admins da org na configuração clássica agora veem um aviso incentivando a migração. 3. **Os admins da org agora podem migrar** suas próprias organizações. Como o blueprint Enterprise já fornece a camada base (runtimes, ferramentas, certificados, registros), os admins da org só precisam configurar o que é específico para sua equipe e seus repos. Cada admin da org pode usar o **assistente de migração** para facilitar esse processo. Devin pode inspecionar o snapshot atual da org e gerar automaticamente uma configuração de blueprint equivalente. Consulte [Migrando para configuração declarativa](/pt-BR/onboard-devin/environment/migration) para ver o fluxo passo a passo. Monte uma biblioteca de blueprints de template para suas stacks de tecnologia mais comuns (Node.js, Python, Java, Go, monorepos multilíngues) e compartilhe-a internamente para que os admins da org não partam do zero. A [Biblioteca de templates](/pt-BR/onboard-devin/environment/templates) é uma boa base.
### Fase 3: Expandir e limpar (Ativado por padrão)
1. **Ative Ativado por padrão** quando a maioria das orgs estiver usando blueprints. Esta é uma ação permanente — as orgs que estavam na configuração clássica com repos recebem overrides clássicos automáticos, então nada muda para elas. 2. **Novas orgs** criadas a partir deste ponto começam com blueprints por padrão. 3. **Monitore a página Rollout** para acompanhar a saúde das builds em todas as orgs. Filtre por "Classic" para ver quem ainda não migrou. 4. **Trabalhe com os admins das orgs restantes** para migrar as que ainda faltam. O assistente de migração torna isso simples. 5. **Remova os overrides clássicos** quando todas as orgs já tiverem sido verificadas em blueprints. A configuração clássica é sempre preservada. Nada é excluído quando uma org muda para blueprints. Se algo der errado, os admin do Enterprise podem reverter qualquer org para a configuração clássica na página Rollout usando overrides por org.
### Estratégia de migração acelerada
Para empresas que querem avançar rapidamente, aqui está uma abordagem que minimiza o esforço de migração por org: 1. **Comece no modo Testing** (assim, cada org pode aderir individualmente). 2. **Configure primeiro o enterprise blueprint.** Peça aos admins que configurem o enterprise blueprint com runtimes, ferramentas, certificados e configuração de registro compartilhados. Essa é a camada base que todas as org vão herdar. 3. **Mude para o modo Available.** Isso ativa o aviso de migração para que os admins das org vejam um destaque na página Configuração da máquina e possam fazer a migração por conta própria. 4. **Divulgue amplamente a documentação** pelos canais internos disponíveis (Slack, e-mail, wiki) e incentive os admins das org a aderirem por conta própria. O assistente de migração permite que os admins das org façam isso por autoatendimento. 5. **Ative automaticamente para org com 0 repositórios configurados no momento.** Essas org não têm nada para migrar — não há risco em mudá-las para blueprints, já que não têm uma configuração clássica existente para preservar. 6. **Migre progressivamente as org restantes, uma por uma.** Com o enterprise blueprint já configurado, cada migração de org só precisa adicionar configuração específica da org e do repo por cima. Isso é muito mais simples do que migrar do zero. 7. **Ative Enabled by default** quando a maioria das org já tiver migrado. As novas organizations criadas depois desse ponto já começam com blueprints ativados. Essa abordagem concentra primeiro a configuração do enterprise blueprint (o trabalho de maior impacto) e depois permite que cada org migre no próprio ritmo com esforço mínimo.
## Rollback
As coisas nem sempre saem como esperado. O sistema de rollout oferece suporte a rollback em todos os níveis.
### Rollback por org
Admins do Enterprise podem reverter qualquer org individual para a configuração clássica na página Rollout: * A org **reverte imediatamente** para usar seu snapshot da configuração clássica. * A configuração clássica é **preservada**. Nada é perdido quando uma org muda para blueprints, então a reversão é segura. * As sessões ativas não são afetadas. A mudança entra em vigor na próxima sessão.
### Rollback do modo
Os admins do Enterprise podem alternar livremente entre **Teste** e **Disponível** usando o menu suspenso de modo de rollout. Isso é útil se você quiser pausar a migração por autoatendimento enquanto investiga um problema. **Ativado por padrão não pode ser revertido** pelo admin do Enterprise. Se precisar reverter de Ativado por padrão, entre em contato com seu administrador da Cognition. Overrides por org ainda podem ser usados para fazer orgs individuais voltarem à configuração clássica a qualquer momento. O rollback não exclui blueprints nem configurações clássicas. Ambos são preservados independentemente do modo ativo, para que você possa alternar entre **Teste** e **Disponível** sem perder trabalho.
## Monitorar a integridade do rollout
A página Rollout fornece um painel para acompanhar o progresso da migração em todo o Enterprise.
### Linha de KPIs
No topo da página, métricas resumidas oferecem uma visão rápida do status do rollout: * **Orgs com blueprint**: Número de orgs atualmente em blueprints * **Percentual de rollout**: Percentual de orgs em blueprints em relação ao total * **Saúde da build**: Status agregado das builds nas orgs com blueprint
### Tabela por org
Abaixo dos KPIs, uma tabela detalhada mostra cada organização: | Coluna | Descrição | | ------------------------ | -------------------------------------------------------------------------- | | **Organização** | Nome da org | | **Estado** | Modo atual: Blueprints ou Classic | | **Override** | Se o estado da org é uma override explícita em vez do padrão do Enterprise | | **Repos clássicos** | Número de repos com configuração clássica | | **Repos com blueprints** | Número de repos com blueprints | | **Build mais recente** | Status da build mais recente (Sucesso, Parcial, Falha etc.) |
### Filtragem
Filtre a tabela por: * **All**: Todas as orgs na Enterprise * **Blueprints**: Orgs atualmente em blueprints * **Classic**: Orgs atualmente na configuração clássica * **Overrides**: Orgs com substituições explícitas de estado (em qualquer direção)
## Segurança contra concorrência
As transições de estado são protegidas contra alterações simultâneas. Se outro admin alterar o estado do Enterprise entre o momento em que você carregou a página e o envio da sua alteração, a requisição será rejeitada com um erro de conflito. Isso evita sobrescritas acidentais quando vários admins do Enterprise agem ao mesmo tempo. Se sua alteração for rejeitada, atualize a página para ver o estado atual e envie a alteração novamente, se ainda for apropriado.
## Registro de auditoria
Todas as transições de estado do rollout são registradas em logs de auditoria: * Alterações no modo Enterprise (Teste → Disponível, ativação de Ativado por padrão etc.) * Alterações de override por org (org aderiu, org recusou, override removido) * Qual admin fez a alteração e quando Esses logs estão disponíveis na interface padrão de logs de auditoria do seu Enterprise.