Release candidate (RC): o que significa e como conduzir

Um release candidate (RC) é uma build que o time acredita estar pronta para ser lançada. Ela está completa em funcionalidades, passou pelos testes planejados e vira a release final sem alterações, a menos que alguém encontre um bug grave o bastante para bloqueá-la. O rótulo é uma promessa sobre a build: nenhuma funcionalidade nova, apenas correções de bloqueios. Se uma correção for necessária, o time gera um novo candidato e o relógio recomeça.

O que é um release candidate em software?

É o último estágio de pré-lançamento antes da disponibilidade geral. A ideia é que a build seja candidata à versão final, e a release acontece promovendo essa mesma build em vez de fazer uma nova. O artigo da Wikipédia sobre o ciclo de vida de lançamento de software descreve a mesma sequência de alfa, beta, release candidate e release, e os termos são amplamente entendidos em projetos de código aberto e entre fornecedores.

Qual é a diferença entre beta e release candidate?

Um beta ainda pode mudar. Funcionalidades podem ser ajustadas, interfaces podem se mover, e o objetivo é descobrir o que falta ou está errado. Um release candidate deixou de mudar dessas formas, e o objetivo é confirmar que nada bloqueia o lançamento. O teste prático é o que o time faz com um relato de bug. Em um beta, um relato pode levar a uma mudança de design. Em um RC, um relato leva a uma correção só se o bug bloquear o lançamento, e o resto entra na fila da próxima versão.

Como versionar um release candidate?

Use um sufixo de pré-lançamento na versão que você está prestes a lançar. No Semantic Versioning, um hífen seguido de identificadores separados por ponto marca um pré-lançamento, então o primeiro candidato para a 2.4.0 é 2.4.0-rc.1, o seguinte é 2.4.0-rc.2, e a release é simplesmente 2.4.0.

A precedência segue a especificação: 2.4.0-rc.1 vem abaixo de 2.4.0-rc.2, e qualquer pré-lançamento vem abaixo da release. Como os identificadores são comparados um a um e os números são comparados numericamente, rc.10 fica acima de rc.9. Os nomes alpha, beta e rc também se ordenam alfabeticamente na ordem certa, parte do motivo de as equipes os usarem. Marque cada candidato com uma tag no git, como descrito em tags do git e releases, para que o commit exato fique registrado.

Quais são os critérios de saída de um release candidate?

Escreva-os antes de gerar o primeiro RC. Um conjunto viável:

• A suíte de testes automatizados passa no commit exato que foi compilado.
• O caminho de atualização a partir da release anterior foi testado com dados realistas.
• Os problemas conhecidos foram triados, e nenhum é classificado como bloqueio.
• Desempenho e taxas de erro correspondem aos da release anterior dentro de uma margem acordada.
• As release notes estão redigidas e revisadas contra a lista final de mudanças.
• Existe um caminho de rollback e alguém o leu.

Quando todas as linhas são verdadeiras para um candidato, esse candidato é a release. Se alguma linha falhar, a correção gera um novo candidato e as verificações recomeçam. A versão em sete passos desse fluxo, com responsáveis por cada etapa, está em processo de gerenciamento de releases.

O que fazer com a build quando um RC passa?

Promova o mesmo artefato. Não recompile a partir da tag, porque uma recompilação pode trazer uma dependência diferente ou uma saída de compilador diferente, e os testes que você fez valeram para a build original. Muitas equipes renomeiam o candidato refazendo a tag ou apontando de novo um rótulo do registry, para que os bytes que foram testados sejam os bytes que os usuários baixam.

Para pacotes, publique os candidatos em um canal separado para que usuários comuns não os recebam por engano. No npm, npm publish --tag rc mantém a tag padrão latest onde estava, e só quem pedir @rc recebe o candidato. Imagens de contêiner e builds mobile têm a mesma ideia com outros nomes: uma tag de pré-lançamento, um rollout em etapas ou uma trilha no estilo TestFlight.

Como escrever as release notes de um release candidate?

Comece as notas no primeiro RC e mantenha-as em sincronia com os candidatos. Os testadores precisam saber o que mudou, o que verificar e o que se sabe que está quebrado, e redigir cedo encontra as entradas de que ninguém se lembra no fim. Marque a página ou a release do GitHub como pré-lançamento para que ninguém a confunda com a versão final, e mova o texto pronto para a release GA quando ela sair. O formato e o conteúdo estão em release notes de software, e o lado do GitHub está em release notes do GitHub.

Times de SaaS precisam de release candidates?

Times que fazem deploy contínuo raramente precisam, porque o deploy em produção é o teste e uma feature flag controla quem vê uma mudança. Release candidates se justificam quando os usuários instalam o software por conta própria e não dá para reverter com um deploy: bibliotecas, apps desktop e mobile, produtos self-hosted e APIs com clientes de vida longa. Para um produto hospedado que expõe as mudanças aos poucos, o equivalente é um rollout em etapas, que o artigo sobre release notes de feature flag cobre do ponto de vista da comunicação.

FAQ

O que significa RC em software? RC é a sigla de release candidate. É uma build que o time pretende lançar como versão final, a menos que os testes encontrem um bug bloqueante. Vem depois dos estágios alfa e beta e antes da disponibilidade geral.

Um release candidate é estável o bastante para produção? Em geral sim para testes em staging ou em produção limitada, e ele carrega um risco que a release final não tem, porque os testes podem não ter terminado. Trate-o como código com qualidade de produção ainda em período de prova.

Quantos release candidates uma release deve ter? Quantos forem necessários, e a maioria das releases precisa de um a três. Uma longa sequência de candidatos geralmente significa que o congelamento foi declarado cedo demais ou que a cobertura de testes está pegando as coisas tarde.

Um release candidate pode virar a release final sem mudanças? Sim, e esse é o resultado pretendido. A release final deve ser a mesma build do último candidato, apenas renomeada ou re-rotulada como GA.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Modelo de notas de versão