Rollouts
O Rollouts monitora cada pull request, da revisão até a produção. Ele cria um plano de liberação quando o pull request é aberto, verifica a alteração com base na sua telemetria após o deploy e relata a integridade dela em cada ambiente.
Configure o Rollouts em Automações.
O Rollouts está disponível nos planos Teams e Enterprise.
Como funciona
Planos de liberação
Quando um pull request é aberto, o Rollouts analisa o diff e os sistemas afetados por ele e, em seguida, gera um plano de liberação. O plano lista os riscos encontrados pelo Rollouts, o efeito esperado da alteração, os sinais que ele vai verificar e eventuais lacunas de instrumentação que dificultariam a verificação da alteração. No GitHub, no GitLab.com e no Bitbucket Cloud, o Rollouts publica o plano como comentário no pull request. No Origin, o plano aparece na página da Pull Request.
Para alterar o plano, mencione o handle indicado no comentário do Rollouts em um comentário de pull request e diga o que deve ser monitorado ou ignorado. O Rollouts revisa o plano e responde. Somente pessoas com acesso de gravação ao repositório podem alterar o plano.
Rastreamento de deploys
O Rollouts é acionado por eventos de deploy do commit da alteração e executa o plano com base nos seus logs, métricas e traces. Ele rastreia cada ambiente separadamente, então uma alteração pode ser verificada em staging e, mesmo assim, ser sinalizada em produção.
O Rollouts verifica um deploy assim que ele acontece e depois de novo após 20 minutos, 1 hora, 1 dia e 3 dias.
Regressões
Quando o Rollouts detecta uma regressão, ele aponta a alteração suspeita, abre uma issue e notifica o autor. Na página da issue, selecione Fix para iniciar um agente em nuvem nela ou Close para fechá-la informando um motivo. O Rollouts não mergeia, não desfaz nem reverte alterações por conta própria.
Rastrear alterações
A página Rollouts agrupa as alterações em Attention, Monitoring, Pending e Verified. Cada ambiente em que uma alteração recebe deploy exibe o próprio status, como Deploying, Monitoring, Verified, Deploy failed ou Issues found.
Uma alteração fica em Attention enquanto tiver uma issue aberta ou um deploy com falha. Quando todas as issues da alteração são fechadas, ela passa a ser considerada Verified. Se uma issue for reaberta, a alteração volta para Attention.
Configurar Rollouts
Em Automações, selecione Enable no card Rollouts em From Cherri Code. A configuração tem quatro etapas:
Acesso aos repositórios monitorados
Escolha os repositórios que serão acompanhados. Cada pull request enviado para produção a partir desses repositórios ganha seu próprio acompanhamento, vinculado ao autor. O Rollouts acompanha repositórios no Origin, GitHub, GitLab.com e Bitbucket Cloud.
Enviar eventos de deploy para o Rollouts
Informe ao Rollouts quando cada deploy em produção começa e termina, usando uma chave de API do Cherri Code armazenada nos segredos do seu CI. Escolha Manually para adicionar você mesmo as chamadas ao seu pipeline. Escolha With an agent para que um agente de configuração abra um pull request que as adiciona e, em seguida, faça o merge dele para concluir a configuração.
Telemetria
Conecte suas ferramentas de observabilidade, como o Datadog, para que cada alteração seja verificada com base no que está acontecendo em produção. O Rollouts precisa de pelo menos uma ferramenta conectada. Sem isso, as alterações ficam pendentes e o Rollouts não consegue detectar problemas.
Notificações
Escolha como os autores de pull requests serão notificados sobre seus rollouts.
Configurações
As configurações do Rollouts têm quatro seções:
- Acesso ao código. Os repositórios que o Rollouts acompanha (até 200) e quais alterações monitorar.
- Eventos de deploy. Como seu pipeline informa o que foi implantado e onde.
- Fontes de dados. As conexões MCP que o Rollouts consulta para verificar as alterações implantadas e detectar regressões.
- Notificações. Como você é avisado sobre deploys e regressões nas suas alterações.
Escolha quais alterações monitorar
Em Which changes to monitor, descreva em linguagem natural quais pull requests o Rollouts deve ignorar. Por padrão, o Rollouts ignora alterações que não afetam o que é executado em um ambiente implantado: alterações apenas na documentação, correções de formatação, lint ou erros de digitação sem alteração de comportamento, e alterações apenas em testes. Apague o texto para monitorar todas as alterações nos repositórios observados.
Um pull request só é ignorado quando se encaixa claramente nos critérios. Quando o Rollouts ignora um pull request, ele explica o motivo em um comentário. Para monitorá-lo mesmo assim, mencione o handle indicado no comentário.
Notificações
Ative Send Slack notifications to me para receber notificações sobre suas alterações no Slack. Em Deliver to, escolha Direct message ou Channel. Para enviar a um canal, informe o nome ou o ID de um canal público, convide cada app listado abaixo do campo e salve. Canais do Slack Connect não são compatíveis.
Antes, um Admin da equipe precisa adicionar o Rollouts ao Slack. Somente Admins da equipe podem alterar os valores padrão de notificação da equipe. As notificações do Slack não ficam disponíveis no Privacy Mode.