Migrando o seu Enterprise

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.

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. 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: 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. 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. 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. 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. 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. 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.

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 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 é uma boa base.

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.

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. As coisas nem sempre saem como esperado. O sistema de rollout oferece suporte a rollback em todos os níveis. 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.

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. A página Rollout fornece um painel para acompanhar o progresso da migração em todo o Enterprise. 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

Abaixo dos KPIs, uma tabela detalhada mostra cada organização: 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)

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. 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.