Revisão e automação

Ambientes persistentes e revisão de CI

Crie ambientes persistentes compartilhados com o assistente de quatro etapas, configure perfis de espaço de trabalho de CI, revise eventos de merge nas cinco abas de CI e promova candidatos validados a partir do Console.

Administradores de clienteOperadores de plataforma

Última atualização 18 de junho de 2026

Ambientes persistentes e revisão de CI são fluxos de trabalho de propriedade do Console para validação compartilhada. Use-os quando um cliente precisar de um tempo de execução de longa duração para QA, UAT, demonstração, staging ou revisão de cliente e quiser que as mudanças passem pela revisão de código e QA antes de serem promovidas.

Esses fluxos de trabalho são diferentes dos espaços de trabalho pessoais de desenvolvedores. Um ambiente persistente é um tempo de execução compartilhado do cliente com política, faturamento, suporte e histórico de eventos. Um perfil de espaço de trabalho de CI é um perfil de tempo de execução de revisão ou QA de propriedade de uma rota, que o Console usa quando um evento de merge precisa de verificações de navegador, banco de dados, inteligência de código ou ambiente de destino.

Ambas as superfícies ficam no painel esquerdo do Console. Ambientes é dono dos tempos de execução compartilhados e seus candidatos; CI e revisão é dono das rotas, eventos de merge, execuções e transferência ao provedor. As duas se vinculam entre si, então você pode se mover entre um ambiente e seu histórico de revisão sem perder o contexto.

Antes de começar

• Você precisa de uma função de administrador de cliente ou operador de plataforma para criar ambientes e perfis de CI.
• O repositório e a branch que você planeja validar devem estar acessíveis por meio de um provedor Git conectado. Consulte Configuração do administrador de cliente para a conexão do provedor e Backups e fontes de restauração para sementes de banco de dados.
• Decida se a rota é apenas da branch de origem ou tem como alvo um ambiente persistente, pois essa escolha muda quais verificações são executadas.

Criar um ambiente persistente

Abra Ambientes e selecione Criar ambiente. O Console abre um assistente de quatro etapas com um trilho de etapas no topo: Origem, Tempo de execução, Política e Revisão. Um painel de lançamento ao vivo à direita mostra as seleções atuais e lista os itens obrigatórios que ainda estão bloqueando.

1. Origem. Escolha o escopo do cliente, nomeie o ambiente e confirme a URL do repositório e a branch de origem. O Console verifica o acesso do provedor aqui. Quando uma mudança depende de mais de um repositório, habilite a pilha de repositórios para que um repositório de tempo de execução e um repositório de produto sejam clonados em ordem.
2. Tempo de execução. Escolha o perfil de ambiente persistente, a família de templates, o alvo do espaço de trabalho e o tamanho do tempo de execução. O perfil define as suposições de versão do WebCentral, incluindo o pacote esperado de Java, Gradle, Tomcat e licença para o espaço de trabalho de apoio.
3. Política. Defina a fonte de semente (backup de banco de dados), a exposição e o mecanismo de migração de banco de dados. Escolha o mecanismo de migração que corresponde ao destino: Flyway, ARCHIBUS DUW ou migrações desabilitadas.
4. Revisão. Confirme o plano de lançamento. A grade de revisão resume o perfil, o modo de repositório, o tamanho e o backup de banco de dados. Quando tudo o que é obrigatório está presente, selecione Criar ambiente.

Quando a criação começa, o Console cria o registro do ambiente e inicia o espaço de trabalho de apoio quando o alvo selecionado o suporta. O cartão do ambiente então mostra o espaço de trabalho persistente, as versões candidata e atual, o estado de atualização do ambiente, os atalhos de tempo de execução e o histórico de eventos.

Ambientes persistentes são feitos para permanecer ativos por mais tempo do que os espaços de trabalho de desenvolvimento pessoais. Escolha o tamanho do tempo de execução e o prazo de faturamento de forma deliberada, e use o histórico de eventos para confirmar quando o espaço de trabalho de apoio, a rota do Tomcat, a semente do banco de dados e o estado de promoção estão prontos.

Use o perfil de versão do WebCentral que corresponde ao repositório de origem ou WAR, especialmente para versões mais antigas do WebCentral que precisam do Tomcat 8.5 ou Tomcat 9 em vez do padrão atual. Consulte Predefinições de espaço de trabalho para ver como esses perfis se mapeiam para as configurações de tempo de execução.

Abrir os atalhos de tempo de execução do ambiente

Depois que o espaço de trabalho persistente existir, use as ações do cartão do ambiente:

Não cole logs brutos em tickets de suporte. Em vez disso, compartilhe o status visível, o ID da execução, o nome do espaço de trabalho, o carimbo de data/hora e o texto de erro sanitizado.

Atualizar um tempo de execução de ambiente em duas etapas

Quando uma versão candidata está pronta para aterrissar no tempo de execução persistente, o Console usa uma atualização deliberada em duas etapas para que um ambiente compartilhado nunca seja reiniciado por acidente.

1. Solicitar atualização do ambiente. Isso aprova a atualização para o espaço de trabalho persistente e a marca como solicitada. O Console mostra que a atualização está pronta para iniciar, mas ainda não tocou no ambiente em execução.
2. Iniciar atualização do ambiente. Isso inicia a atualização do espaço de trabalho persistente e aguarda o resultado do tempo de execução. O Console move o estado para em execução e, em seguida, para aplicado, assim que o tempo de execução persistente estiver na versão promovida.

O cartão do ambiente mostra o estado de atualização atual e uma breve descrição para cada etapa, além de linhas de evidência de tempo de execução para que você possa confirmar o que mudou.

Criar um perfil de espaço de trabalho de CI

Abra CI e revisão e selecione Criar perfil de CI (é Criar CI/perfil na barra de ações superior). O Console abre um assistente de quatro etapas com o mesmo formato de trilho de etapas: Origem, Tempo de execução, Política e Revisão, exibidas na área de trabalho como Rota de origem, Tempo de execução do espaço de trabalho, Política de execução e Revisar e criar.

1. Rota de origem. Escolha o cliente, o provedor, o repositório, a branch e um ambiente de destino opcional. Selecionar um ambiente de destino é o que ativa a verificação de destino mais tarde. Aplique um perfil de pilha de repositórios quando a mudança precisar de um repositório de tempo de execução mais um repositório de produto ou de dependência.
2. Tempo de execução do espaço de trabalho. Escolha o formato do espaço de trabalho: revisão, QA, revisão mais QA ou QA de destino. Selecione o template de CI, o alvo do espaço de trabalho e o tamanho.
3. Política de execução. Defina a retenção, os artefatos, quais etapas são executadas, o escopo do QA e o mecanismo de migração de banco de dados. Selecione o perfil de versão do WebCentral e o backup de banco de dados. A revisão geralmente usa raciocínio alto; o QA geralmente usa raciocínio baixo depois que as verificações determinísticas reuniram evidências.
4. Revisar e criar. Confirme o perfil da rota na grade de revisão e, em seguida, selecione Criar perfil de CI.

Salvar um perfil de espaço de trabalho de CI não cria um espaço de trabalho de desenvolvedor pessoal. Ele cria os metadados da rota que o Console usa quando um evento de merge ou uma execução de teste precisa de um espaço de trabalho de revisão ou QA. Execuções leves ainda podem usar o executor do Console sem um espaço de trabalho quando ferramentas de navegador, banco de dados e inteligência de código não são necessárias.

Se a rota não tiver um ambiente de destino persistente, o Console ainda pode executar QA na branch de origem. A revisão de código começa a partir de um evento de merge do Console, uma pull request do provedor ou um diff explícito para que os revisores vejam o conjunto real de mudanças e o gate de merge. A verificação do ambiente de destino é ignorada porque não há configuração de ambiente para validar.

As cinco abas de CI e revisão

A área de trabalho de CI e revisão é organizada em cinco abas acima do painel principal, cada uma com uma contagem ao vivo:

Acima das abas, uma faixa de fluxo de trabalho mostra o pipeline de etapas para o evento de merge selecionado: Entrada, Revisão, QA, QA de destino e Merge. Cada etapa mostra seu próprio status, como aberta, aguardando, ignorada ou aguardando verificações.

Apenas branch de origem versus ambiente de destino

Rotas apenas de branch de origem executam revisão de código e QA do executor sem um ambiente persistente selecionado. Nesse modo, o Console ignora intencionalmente a verificação do ambiente de destino, e a etapa QA de destino é exibida como ignorada.

Rotas com um ambiente persistente selecionado adicionam uma verificação de ambiente de destino. Depois que a revisão de código e o QA do executor passam, o Console valida o candidato em relação aos padrões do ambiente selecionado antes que o merge ou a promoção possa prosseguir.

A verificação do ambiente de destino usa os padrões de ambiente que importam após a promoção, incluindo tipo de banco de dados, backup de banco de dados, mecanismo de migração, alvo do espaço de trabalho, template, cadeia de ferramentas, parâmetros do espaço de trabalho e substituição de licença quando configurada.

Quando uma rota usa uma versão mais antiga do WebCentral, mantenha o mesmo perfil de versão no ambiente persistente, no perfil de QA de origem e no perfil de QA de destino. Isso faz com que as evidências de revisão, os testes de fumaça do navegador e a verificação final de promoção sejam executados sob as mesmas suposições de tempo de execução.

Configurar a transferência ao provedor

Abra a aba Transferência ao provedor e carregue uma rota para registrar ou verificar a conexão do provedor gerenciado. O Console é dono da camada de revisão; a conexão do provedor permite que ele publique comentários de revisão e QA, envie feedback de status e receba eventos de merge.

A partir desta aba, você pode:

• Salvar uma conexão gerenciada. Registre o aplicativo do provedor, o service hook ou uma referência de credencial aprovada como token://..., k8s://secret/key, ou uma referência OpenBao/Vault. O Console também pode aceitar um token de provedor de uso único ou uma senha de aplicativo e armazená-lo no armazenamento de tokens do Console, em um Kubernetes Secret ou no OpenBao/Vault. Após salvar, o Console mostra apenas uma prévia da credencial.
• Rotacionar a credencial. Use Rotacionar credencial quando um token expira ou é substituído. Execute uma verificação de conexão em seguida.
• Revogar a credencial. Use Revogar credencial para manter o registro de conexão, mas parar a publicação até que uma nova referência de credencial seja adicionada.
• Instalar ou reconciliar um webhook. Use Instalar webhook para que as atualizações de eventos de merge cheguem ao Console, Reconciliar webhook para reparar um hook desviado e Remover webhook para parar os eventos. Salve ou selecione uma rota antes de instalar o webhook.
• Verificar a conexão. Use Verificar conexão para confirmar a integridade antes de confiar na rota para revisão, status ou publicação de comentários.

Um painel de prontidão percorre os metadados da rota, o serviço do provedor, o alvo de instalação, a fonte da credencial, as ações permitidas, o registro do Console e a integridade do provedor, para que você possa ver qual etapa ainda está faltando.

Não coloque tokens de provedor, payloads de credenciais brutas ou segredos de implantação privados em nomes de rotas, descrições, notas de QA ou instruções de rota.

Revisar um evento de merge

Eventos de merge são a unidade de revisão normal no Console. Um evento de merge pode vir de um webhook do provedor, uma transferência de espaço de trabalho ou um registro manual no Console.

1. Abra CI e revisão.
2. Escolha o evento de merge na aba Eventos de merge.
3. Abra Revisão no Console para ver a branch de origem, a branch de destino, o link do provedor, os itens de recurso, a lista de revisores e as mudanças empilhadas.
4. Atribua revisores ou adicione um revisor personalizado e atualize as notas do revisor.
5. Selecione Iniciar revisão e QA quando a rota estiver pronta.
6. Observe a faixa de fluxo de trabalho: Entrada, Revisão, QA, QA de destino e Merge.

Quando mudanças empilhadas são detectadas, o Console mostra a prévia de pilha delimitada e o contexto por arquivo que ele pode exibir com segurança. Use os links do provedor apenas para contexto secundário.

A revisão do Archibot e o QA do executor podem ser executados separadamente ou juntos. A revisão foca no código, no contexto de diff empilhado, em testes ausentes, em caminhos arriscados e no impacto na documentação. O QA foca em evidências de execução, como testes de fumaça do navegador, verificações de banco de dados, comandos de teste selecionados, validação da cadeia de ferramentas e logs do espaço de trabalho. Consulte Bots do Console para ver como os bots de revisão e QA do Archibot são configurados.

Se uma execução precisar parar, use Cancelar execução na execução na aba Evidências e logs. O Console marca a execução como cancelada.

Fazer merge e promover

O Console mantém o merge humano como padrão.

Antes que Fazer merge no Console esteja disponível:

• Uma aprovação de revisor deve ser registrada.
• A etapa de revisão de código solicitada deve passar.
• A etapa de QA do executor solicitada deve passar.
• Se um ambiente de destino estiver selecionado, a verificação do ambiente de destino deve passar.

Após o merge ser concluído, o candidato validado pode se tornar um candidato à promoção para o ambiente persistente selecionado. Use Promover candidato em Ambientes somente quando a última execução de CI e a verificação do ambiente de destino corresponderem à versão candidata. Uma vez promovido, use a atualização de ambiente em duas etapas descrita acima para aterrissá-lo no tempo de execução em funcionamento.

Logs, evidências e Shared Drive

CI e revisão e Ambientes mantêm o histórico de eventos no Console. Use a linha do tempo da execução na aba Evidências e logs para ver as mudanças de etapa, os nomes de jobs, o status do ambiente de destino e as linhas de log sanitizadas.

Use Salvar no Shared Drive quando o suporte precisar que as evidências sobrevivam à janela normal de retenção de logs de execução. A conta precisa de uma unidade gravável para isso. Mantenha as evidências de longa duração sanitizadas e aprovadas pelo cliente. Consulte Archibot do espaço de trabalho e Shared Drive para ver como o acesso à unidade com escopo funciona.

Os revisores devem ser capazes de responder a três perguntas no Console antes de fazer o merge:

• O que mudou, incluindo quaisquer diffs empilhados?
• Quais verificações de revisão, QA e destino foram executadas?
• Onde estão as evidências sanitizadas se a execução precisar de revisão de suporte mais tarde?

Não compartilhe:

• Chaves de API, tokens de provedor, segredos de webhook, cookies ou links de convite.
• Kubernetes Secrets, variáveis de ambiente de pod, kubeconfigs ou tokens do Coder.
• URLs de banco de dados brutas, conteúdos de backup brutos ou arquivos de licença.
• Transcrições privadas ou despejos de dados de clientes.

Bloqueios comuns

Transferência ao suporte

Para o suporte, inclua:

• A conta do cliente e o nome do ambiente.
• O ID do evento de merge ou o ID da execução de CI.
• A branch de origem, a branch de destino e o número da merge request do provedor quando visível.
• A etapa que está bloqueada.
• O erro sanitizado do Console ou o resumo do log.

Não inclua credenciais brutas, logs completos com segredos, dados privados de banco de dados ou links de uso único. Consulte Transferência ao suporte para a lista de verificação completa de evidências.