Pular para o conteúdo principal
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

O Enterprise tem três estados principais que controlam como os blueprints ficam disponíveis para as organizações:
EstadoO que significaEfeito nas organizações
DesativadoOs blueprints não estão ativados para o EnterpriseNenhuma org vê as páginas de ambiente. Todas as org usam a configuração clássica.
Padrão desativadoOs blueprints estão disponíveis, mas não são o padrãoO admin do Enterprise pode ativar org individualmente. Novas org começam na configuração clássica.
Padrão ativadoOs blueprints são o padrão para todas as orgTodas as org usam blueprints, a menos que sejam explicitamente revertidas para a configuração clássica. Novas org começam com blueprints.
As transições acontecem em ordem: Desativado → Padrão desativado → Padrão ativado. Você também pode voltar (Padrão ativado → Padrão desativado) para desacelerar o rollout.

​
Detalhes de padrão desativado

No estado padrão desativado, 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. Há um controle adicional: Mostrar aviso de migração para todas as organizações. Quando ativado, 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 para aderir. Isso é útil para gerar conscientização antes de começar a migrar orgs. Quando esse controle está desativado, orgs que não foram explicitamente incluídas não veem nada novo. A experiência delas permanece inalterada.

​
Overrides por org

Os admin do Enterprise podem substituir o estado de rollout de organizações individuais na página Rollout:
  • In padrão desativado: Inclua orgs específicas nos blueprints. Essas orgs passam da configuração clássica para a configuração declarativa imediatamente.
  • In padrão ativado: 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 no estado do Enterprise. Se você incluir uma org nos blueprints durante a fase padrão desativado, ela continuará nos blueprints quando fizer a transição para padrão ativado.

​
Overrides automáticos do clássico

Ao passar de Padrão desativado para Padrão ativado, 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 (padrão desativado)

Comece com o Enterprise no modo padrão desativado. As org não podem aderir por conta própria, então você tem controle total.
  1. Ative os blueprints no nível Enterprise, mudando de Desativado para padrão desativado.
  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

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. Ative o incentivo à migração: habilite o controle “Show migration nudge to all organizations” para que admins da org na configuração clássica vejam 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.

​
Fase 3: Expandir e limpar

  1. Faça a transição para padrão ativado quando a maioria das orgs estiver usando blueprints. 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 instantaneamente qualquer org para a configuração clássica na página Rollout.

​
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 em todo o Enterprise

Os admins do Enterprise podem fazer a transição de padrão ativado de volta para padrão desativado:
  • orgs que tinham overrides explícitos de blueprint as mantêm. Elas continuam usando blueprints.
  • orgs que usavam blueprints por padrão (sem override) retornam à configuração clássica.
  • Esta é uma operação segura. Nenhum dado de configuração é perdido em nenhum dos sentidos.
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 eles 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:
ColunaDescrição
OrganizaçãoNome da org
EstadoModo atual: Blueprints ou Classic
OverrideSe o estado da org é uma override explícita em vez do padrão do Enterprise
Repos clássicosNúmero de repos com configuração clássica
Repos com blueprintsNúmero de repos com blueprints
Build mais recenteStatus 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 de estado do Enterprise (Desativado → padrão desativado, padrão desativado → padrão ativado 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.