Beta vs Release Candidate (RC)

Uma versão beta, também conhecida como prévia, é uma versão pré-lançamento de um software disponibilizada para um grupo seleto de usuários para testes.

Permite aos desenvolvedores coletar feedback, identificar e corrigir bugs, e assegurar a estabilidade e funcionalidade do software antes de seu lançamento oficial ao público.

Um Release Candidate (RC) e uma versao de software que esta potencialmente pronta para lancamento ao publico, pendente de verificacao final. O RC representa o ultimo estagio antes do lancamento oficial — se nenhum bug critico for encontrado durante os testes finais, esta versao se torna a versao de producao.

O termo "candidate" (candidato) e proposital: esta versao e uma candidata a se tornar a versao final. Assim como um candidato a emprego precisa passar por uma entrevista final, o RC precisa passar pelos testes finais antes de ser aprovado.

Segundo o DORA Report (2023), organizacoes que adotam praticas rigorosas de RC e testes pre-lancamento experimentam 45% menos incidentes em producao e 60% menor MTTR (Mean Time to Recovery).

O desenvolvimento de software segue uma progressao tipica de estagios antes do lancamento:

Alpha (Alfa)

Caracteristicas do Alpha:

• Muitas funcionalidades incompletas
• Crashes e bugs frequentes
• Performance nao otimizada
• Interface pode estar incompleta
• Dados podem ser perdidos entre versoes

Beta

Tipos de Beta:

• Beta Fechado (Closed Beta): Acesso limitado por convite
• Beta Aberto (Open Beta): Qualquer pessoa pode participar
• Early Access: Versao beta disponivel para compra/uso antecipado

Release Candidate (RC)

Caracteristicas do RC:

• Feature freeze — nenhuma nova funcionalidade adicionada
• Code freeze — apenas correcoes de bugs criticos
• Todos os bugs conhecidos classificados como nao-criticos ou corrigidos
• Documentacao completa
• Notas de versao preparadas

RTM (Release to Manufacturing/Marketing)

GA (General Availability)

A versao se torna disponivel para todos os usuarios. Pode coincidir com o RTM ou ter um lancamento faseado.

Pre-Alpha → Alpha → Beta Fechado → Beta Aberto → RC1 → RC2 (se necessario) → RTM → GA

Convencao de nomenclatura

Os Release Candidates sao numerados sequencialmente:

• v3.0-RC1 — Primeiro candidato a lancamento
• v3.0-RC2 — Segundo candidato (correcoes do RC1)
• v3.0-RC3 — Terceiro candidato (se necessario)
• v3.0 — Versao final (sem sufixo RC)

Outras convencoes comuns:

• 3.0.0-rc.1 (SemVer)
• 3.0 Release Candidate 1
• 3.0 RC1

Tipos de testes no RC

Criterios de aprovacao do RC

Um RC e aprovado para lancamento quando:

1. Zero bugs criticos (P1) — nenhum bug que impeca o uso
2. Todos os testes de regressao passam — sem regressoes
3. Performance aceitavel — dentro dos SLAs definidos
4. Seguranca validada — sem vulnerabilidades conhecidas
5. Documentacao completa — guias de usuario, notas de versao
6. Stakeholders aprovam — UAT concluido com sucesso

Quando criar um novo RC?

Um novo RC (RC2, RC3...) e necessario quando:

• Um bug critico e encontrado e corrigido
• Uma vulnerabilidade de seguranca e descoberta
• Um problema de performance significativo e identificado
• O build anterior tinha um defeito de empacotamento

Regra: Cada novo RC reinicia o ciclo de testes completo.

Pipeline de RC

No contexto de CI/CD:

Feature Branch → Merge → Build CI → Testes Automatizados → Ambiente Staging → Testes Manuais → RC Tag → Testes RC → Aprovacao → Deploy Producao

Feature Flags e RC

Feature flags permitem uma abordagem alternativa ao RC tradicional:

• Funcionalidades novas sao deployadas em producao desativadas
• O RC testa a ativacao gradual das features
• Se um problema e encontrado, a feature e desativada sem necessidade de novo RC

Release Strategies

1. Feature freeze rigoroso — nenhuma funcionalidade nova apos o RC
2. Apenas correcoes criticas — code freeze para tudo que nao e bug fix
3. Ambiente identico a producao — testar no ambiente mais proximo possivel
4. Testes automatizados completos — regressao, performance, seguranca
5. Checklist de lancamento — lista detalhada de verificacoes
6. Rollback plan — plano de contingencia caso algo de errado
7. Comunicacao clara — todos os stakeholders informados do status
8. Notas de versao — documentacao de todas as mudancas

• Organizacoes com praticas RC rigorosas tem 45% menos incidentes (DORA, 2023)
• O numero medio de RCs antes de um lancamento e 1,8 (GitHub Octoverse, 2023)
• 82% das empresas de software utilizam alguma forma de estagio RC (Puppet State of DevOps, 2023)
• O tempo medio de teste de um RC e 3–7 dias para software enterprise
• Empresas que automatizam testes de RC reduzem o tempo de lancamento em 60% (Forrester, 2022)

Quantos RCs sao normais antes de um lancamento?

Tipicamente 1–3 RCs. Se voce esta criando mais de 3, pode haver problemas no processo de QA anterior. O objetivo e que o RC1 ja esteja muito proximo da versao final.

Qual a diferenca entre RC e Beta?

O Beta ainda pode ter bugs conhecidos e funcionalidades incompletas. O RC e considerado completo — so sera rejeitado se um bug critico for encontrado. O Beta busca feedback; o RC busca validacao final.

O que e "Go/No-Go" decision?

E a decisao formal de lancar ou nao o RC como versao final. Geralmente envolve stakeholders de engenharia, QA, produto e negocio. Criterios claros devem ser definidos antes do inicio dos testes.

RC faz sentido com Continuous Deployment?

Com Continuous Deployment, cada commit que passa nos testes vai automaticamente para producao. Nesse modelo, o conceito tradicional de RC e menos relevante, pois cada build e potencialmente um "RC". As feature flags substituem a funcao do RC.

O que acontece se um bug critico e encontrado apos o lancamento?

Se um bug critico e encontrado apos o GA, a equipe deve lancar um hotfix ou patch release (ex: v3.0.1). Em casos graves, pode ser necessario um rollback para a versao anterior.

• CI/CD
• DevOps
• Blue-Green Deployment
• Canary Release
• Feature Flag
• Beta
• Build
• UAT — User Acceptance Testing