Lançamentos Pequenos

XP defende lançamentos pequenos e frequentes. Isso era radical em 1999, quando lançamentos anuais eram normais. Ainda é radical em muitas organizações.

Benefícios de lançamentos pequenos:

Feedback mais rápido: Os clientes veem software real mais cedo. Eles podem dizer o que está errado antes que você tenha construído muito da coisa errada.

Risco reduzido: Cada lançamento é uma pequena aposta. Se falhar, você perdeu semanas, não meses. Você pode corrigir o rumo rapidamente.

Entrega de valor mais rápida: Funcionalidades que estão prontas são usadas. Uma funcionalidade lançada hoje é melhor que uma funcionalidade esperando por um grande lançamento em seis meses.

Moral melhorado: A equipe vê seu trabalho sendo usado. Entregar é satisfatório. Ciclos de lançamento longos drenam a motivação.

Melhor qualidade: Lançamentos menores significam mudanças menores. Mudanças menores são mais fáceis de testar, mais fáceis de depurar e menos propensas a causar problemas.

A frequência de lançamento certa depende do contexto, mas busque lançamentos menores e mais frequentes do que parece confortável.

Exemplos de frequência:

• Diária (implantação contínua): Cada commit vai para produção
• Semanal: Lançamento no final de cada iteração
• Quinzenal: Lançamento após cada duas iterações
• Mensal: Ciclo de lançamento mensal

Cada passo menor é melhor, até o ponto em que a sobrecarga de lançamento domina. Se lançar leva um dia inteiro de trabalho manual, lançar diariamente é impraticável. Corrija o processo de lançamento primeiro.

Sinais de que você está lançando com pouca frequência:

• Lançamentos são assustadores (muita coisa mudou)
• Problemas de integração são comuns (lotes grandes)
• Clientes esperam meses por correções
• A equipe tem "semanas de merge"

Lançamentos pequenos exigem investimento técnico:

Testes automatizados: Você não pode lançar frequentemente se os testes levam semanas. Testes automatizados rápidos e abrangentes são essenciais.

Integração contínua: O código deve integrar suavemente. Branches de longa duração são incompatíveis com lançamentos frequentes.

Automação de implantação: Lançamentos devem ser com um clique. Etapas manuais de implantação te atrasam e introduzem erros.

Feature flags: Funcionalidades incompletas podem ser mescladas mas escondidas dos usuários. Isso permite lançamentos pequenos mesmo quando funcionalidades abrangem múltiplas iterações.

Estratégia de migração de banco de dados: Mudanças de esquema devem ser implantáveis sem quebrar o código existente. Geralmente isso significa migrações compatíveis com versões anteriores.

Monitoramento e rollback: Quando algo dá errado, você precisa saber imediatamente. E você precisa conseguir reverter rapidamente.

Essas não são práticas XP em si—são práticas modernas de DevOps que habilitam a visão original de XP de entrega contínua.

O extremo lógico de lançamentos pequenos é implantação contínua: cada commit que passa nos testes vai diretamente para produção.

Isso parece aterrorizante. Mas com as práticas certas, é na verdade mais seguro que grandes lançamentos:

• Cada mudança é minúscula e fácil de entender
• Se algo quebra, você sabe exatamente o que causou
• Rollback é trivial (o último deploy foi há minutos)
• Sem estresse de "dia de lançamento" ou pushes fora do horário

Implantação contínua requer:

• Cobertura de testes muito alta
• Builds muito rápidos (10 minutos no máximo)
• Feature flags robustos
• Monitoramento excelente
• Uma cultura de qualidade (sem atalhos)

Nem toda equipe está pronta para isso. Mas toda equipe pode caminhar em direção a lançamentos menores e mais frequentes. Comece lançando duas vezes mais frequentemente. Depois duas vezes mais frequentemente de novo. Veja até onde você pode ir.