A equipe concluiu uma funcionalidade. Os testes passaram, o código foi revisado e o deploy está pronto. Mesmo assim, alguém pergunta: “Podemos esperar até segunda-feira para liberar?”

Quando publicar código significa expor imediatamente toda novidade a todos os clientes, cada deploy vira também um lançamento. É possível separar essas decisões: deploy é colocar uma versão em produção; release é disponibilizar uma funcionalidade aos usuários.

Menos mudanças por vez, mais capacidade de aprender

Imagine um SaaS pequeno substituindo seu serviço de notificações. Liberar a nova implementação para toda a base aumenta a exposição a falhas. Deixá-la semanas em uma branch isolada também custa caro: conflitos, testes tardios e pouco feedback.

O DORA recomenda trabalhar em lotes pequenos e integrar mudanças frequentemente. O objetivo é reduzir a complexidade de cada alteração e acelerar a descoberta de problemas, não fazer deploy apenas para melhorar números.

Feature flags: código publicado, comportamento controlado

Uma feature flag permite escolher qual comportamento executar sem exigir novo deploy para cada alteração. Pode ser um simples ligado/desligado ou uma regra que expõe a novidade a um grupo específico.

Para o serviço de notificações, um caminho seria publicar o código com a flag desligada, testar com contas internas, liberar para clientes piloto e ampliar a exposição após observar erros e latência. Se houver problema, o time volta ao comportamento anterior, desde que esse caminho ainda funcione.

O que mudou em 2026?

Em 12 de agosto de 2026, o OpenFeature anunciou a especificação 0.9.0 e a adoção do padrão por seis grandes plataformas. Uma API aberta e providers podem reduzir dependência de fornecedores, mas a compatibilidade entre SDKs ainda precisa ser verificada.

Fonte: OpenFeature — Mid-2026 Update.

Flag não substitui qualidade

Controlar exposição não elimina a necessidade de testes, integração contínua e monitoramento. Desligar uma flag não desfaz uma migração destrutiva de banco. Esconder um botão não substitui autorização no servidor. A equipe precisa acompanhar erros, latência e experiência do cliente antes de ampliar a liberação.

O comportamento padrão deve ser seguro quando a avaliação falhar. Também é importante evitar enviar dados pessoais desnecessários ao serviço de segmentação.

O custo oculto das flags esquecidas

Cada flag temporária cria mais caminhos para entender e testar. Por isso, uma flag de lançamento deve nascer com responsável, propósito e condição de remoção. Controles operacionais permanentes são diferentes de flags de transição e merecem outra política.

Um primeiro experimento

1. Escolha uma mudança de risco moderado e defina o comportamento seguro.
2. Decida quem pode ativar, desativar e ampliar a exposição.
3. Teste os dois caminhos e a possibilidade de reversão.
4. Defina sinais de avanço ou interrupção antes do lançamento.
5. Combine quando remover a flag e o código antigo.

Na Agileeze, essa visão conecta consultoria e desenvolvimento de software sob medida: melhorar o fluxo, reduzir risco e construir produtos simples de evoluir, sem adicionar processo por adicionar.

Uma boa entrega não exige coragem para apertar o botão. Exige risco compreendido, limitado e acompanhado.