Revisão e automação

Ambientes persistentes e CI Review

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 19 de junho de 2026

Ambientes persistentes e CI Review 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. Environments é dono dos tempos de execução compartilhados e seus candidatos; CI & Review é 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 Environments e selecione Create environment. O Console abre um assistente de quatro etapas com um trilho de etapas no topo: Source, Runtime, Policy e Review. 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. Source. 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. Runtime. 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. Policy. 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. Review. 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 Create environment.

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.

Qualquer pessoa que possa ver um ambiente pode renomeá-lo. Use o controle de edição de nome com ícone de lápis no cartão do ambiente para alterar o nome de exibição. A renomeação afeta apenas o nome de exibição: ela não altera a chave do ambiente, o cliente, o repositório, o provisionador ou qualquer outra configuração. Mudanças estruturais ainda precisam de acesso de administrador ou de gerenciamento.

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. Request environment update. 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. Start environment update. 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 & Review e selecione Create CI profile (é Create CI/profile na barra de ações superior). O Console abre um assistente de quatro etapas com o mesmo formato de trilho de etapas: Source, Runtime, Policy e Review, exibidas na área de trabalho como Source route, Workspace runtime, Run policy e Review and create.

1. Source route. 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. Workspace runtime. 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. Run policy. 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. Review and create. Confirme o perfil da rota na grade de revisão e, em seguida, selecione Create CI profile.

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 & Review

A área de trabalho de CI & Review é 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: Intake, Review, QA, Target QA 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 Target QA é 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 Provider handoff 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 Rotate credential quando um token expira ou é substituído. Execute uma verificação de conexão em seguida.
• Revogar a credencial. Use Revoke credential 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 Install webhook para que as atualizações de eventos de merge cheguem ao Console, Reconcile webhook para reparar um hook desviado e Remove webhook para parar os eventos. Salve ou selecione uma rota antes de instalar o webhook.
• Verificar a conexão. Use Check connection 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 & Review.
2. Escolha o evento de merge na aba Merge events.
3. Abra Review in 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 Start review & QA quando a rota estiver pronta.
6. Observe a faixa de fluxo de trabalho: Intake, Review, QA, Target QA 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 Console Bots para ver como os bots de revisão e QA do ArchiBot são configurados.

Se uma execução precisar parar, use Cancel run na execução na aba Evidence and 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 Merge in 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 Promote candidate em Environments 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 & Review e Environments mantêm o histórico de eventos no Console. Use a linha do tempo da execução na aba Evidence and 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 Save to 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.