O que acontece depois do deploy

Existe uma visão confortável sobre deploy.

O código foi aprovado.

O pipeline passou.

A nova versão chegou em produção.

Fim.

Só que, na prática, colocar uma mudança no ar raramente encerra o trabalho.

Na maioria das vezes, é justamente quando a parte mais imprevisível começa.

Porque até aquele momento estávamos trabalhando com expectativa.

Esperávamos que a feature funcionasse.

Esperávamos que os fluxos estivessem corretos.

Esperávamos que os usuários entendessem.

Esperávamos que a performance se mantivesse.

Esperávamos que nada importante quebrasse.

Depois do deploy, a expectativa encontra a realidade.

E é aí que o produto começa a responder de verdade.

Produção é outro tipo de ambiente

Durante o desenvolvimento, conseguimos controlar muita coisa.

Dados.

Cenários.

Usuários.

Sequência de ações.

Ambientes.

Até mesmo as falhas que queremos reproduzir.

Produção não oferece esse conforto.

Existem usuários em versões diferentes.

Sessões antigas.

Dados que cresceram durante meses.

Integrações externas instáveis.

Conexões lentas.

Comportamentos inesperados.

Combinações que nunca apareceram durante os testes.

Isso significa que passar pelo pipeline é importante.

Mas não é prova de que a mudança está saudável.

O pipeline consegue validar aquilo que fomos capazes de prever.

Produção revela aquilo que não previmos.

Deploy não deveria ser um ato de fé

Existe uma diferença grande entre publicar uma versão e ter confiança para publicar uma versão.

Quando o processo é frágil, cada deploy carrega tensão.

Será que algo vai quebrar?

Se quebrar, vamos perceber?

Se percebermos, conseguimos voltar rapidamente?

Se voltarmos, os dados continuam consistentes?

Essa insegurança faz com que times naturalmente reduzam a frequência de entrega.

Mudanças começam a ser agrupadas.

Releases ficam maiores.

A janela de risco cresce.

E, ironicamente, quanto maior o deploy, mais difícil fica descobrir qual mudança causou um problema.

Um processo saudável tenta fazer o contrário.

Mudanças menores.

Mais frequentes.

Mais observáveis.

Mais fáceis de reverter.

O objetivo não é fazer deploy por fazer.

É reduzir o custo de mudar o sistema.

Rollback também faz parte da entrega

Quando pensamos em uma nova versão, quase sempre planejamos como ela vai entrar.

Nem sempre pensamos com o mesmo cuidado em como ela sairia.

Só que reversibilidade muda bastante a qualidade de uma decisão.

Imagine que acabamos de publicar uma alteração importante.

Minutos depois, erros começam a aparecer.

Nesse momento, talvez existam duas opções.

A primeira é investigar o problema enquanto a versão continua afetando usuários.

A segunda é retornar para um estado conhecido e investigar com mais calma.

Quando rollback é simples e confiável, essa segunda opção pode ser extremamente valiosa.

Mas nem toda mudança é fácil de desfazer.

Migrações de banco.

Alterações de contrato.

Processamento assíncrono.

Dados já transformados.

Integrações externas.

Por isso, rollback não deveria ser pensado apenas quando algo dá errado.

Ele faz parte da própria estratégia de mudança.

Uma entrega fica mais segura quando sabemos qual é o caminho de volta.

Nem tudo precisa chegar para todo mundo ao mesmo tempo

Outra forma de reduzir risco é separar deploy de disponibilidade.

Colocar o código em produção não precisa significar que todos os usuários terão acesso imediatamente.

Feature flags são úteis justamente porque criam essa separação.

A funcionalidade pode existir.

Mas ficar desabilitada.

Pode ser liberada internamente.

Depois para um pequeno grupo.

Depois para uma porcentagem maior.

Até chegar a todos.

Isso cria uma margem importante para observar comportamento antes de ampliar impacto.

Também permite desligar rapidamente algo problemático sem necessariamente fazer um novo deploy.

Mas feature flag não é solução gratuita.

Flags acumulam.

Regras ficam difíceis de entender.

Código antigo permanece escondido atrás de condições.

Depois de algum tempo, ninguém sabe quais flags ainda fazem sentido.

Então elas também exigem disciplina.

Criar é fácil.

Remover é parte do trabalho.

Publicar é o começo da observação

Nos artigos anteriores desta série, falamos sobre analytics e monitoramento.

É depois do deploy que essas duas coisas encontram seu momento mais importante.

Uma nova versão entrou.

O que mudou?

A taxa de erro aumentou?

A performance piorou?

O fluxo continua sendo concluído?

A funcionalidade está sendo utilizada?

Existe algum comportamento inesperado?

Essas perguntas não precisam ser respondidas apenas quando algo parece errado.

Acompanhamento pós-release serve justamente para descobrir problemas antes que eles se tornem óbvios.

Isso pode ser simples.

Olhar alguns dashboards.

Verificar eventos principais.

Acompanhar erros relacionados à versão.

Observar métricas críticas.

Conversar com suporte.

O importante é existir algum mecanismo de feedback.

Porque publicar uma mudança e simplesmente seguir para a próxima tarefa cria uma lacuna perigosa.

Você sabe o que entregou.

Mas não sabe o que aconteceu depois.

O pipeline verde não conhece o usuário

CI ajuda muito.

Testes automatizados também.

Checks de qualidade.

Type checking.

Lint.

Testes de integração.

End-to-end.

Tudo isso reduz risco.

Mas ainda existe uma diferença importante entre validar comportamento técnico e validar comportamento humano.

O teste pode confirmar que o botão funciona.

Não que alguém vai encontrá-lo.

Pode confirmar que a requisição acontece.

Não que o tempo de espera parece aceitável.

Pode confirmar que o formulário aceita os dados corretos.

Não que a mensagem de erro ajuda alguém a corrigir os dados errados.

Pode confirmar que a feature foi liberada.

Não que ela está resolvendo alguma coisa.

Automação aumenta confiança técnica.

Uso real adiciona contexto.

Precisamos dos dois.

Release também é comunicação

Nem toda mudança precisa de anúncio.

Mas mudanças relevantes geralmente precisam de algum tipo de comunicação.

Para usuários.

Para suporte.

Para vendas.

Para outras pessoas do time.

Isso é especialmente importante quando o comportamento do produto muda.

Imagine alterar um fluxo que clientes utilizam todos os dias.

Tecnicamente, a mudança pode estar perfeita.

Mas se alguém descobrir sozinho que uma ação mudou de lugar ou que determinado processo agora funciona de outra forma, existe um custo.

Esse custo pode virar ticket.

Confusão.

Retrabalho.

Frustração.

Release notes, mensagens internas, changelogs e comunicações dentro do próprio produto podem reduzir essa distância.

A entrega técnica e a percepção da mudança não acontecem necessariamente ao mesmo tempo.

Comunicação ajuda a conectá-las.

Suporte também é observabilidade

Existe um tipo de informação que nenhum dashboard consegue capturar completamente.

O que as pessoas estão dizendo.

Um aumento súbito de tickets sobre determinado fluxo pode indicar um problema.

Várias dúvidas sobre a mesma mudança podem revelar que a interface não está clara.

Uma pergunta recorrente pode mostrar que alguma expectativa criada pelo produto não corresponde ao comportamento real.

Suporte não é apenas uma área que recebe problemas depois que engenharia termina.

Também é uma fonte de observação.

Existe informação valiosa no tipo de dificuldade que chega até ali.

E isso conecta diretamente operação e produto.

O monitoramento mostra que algo está quebrando.

Analytics mostra que um fluxo está sendo abandonado.

Suporte pode explicar como esse problema está sendo percebido.

Nenhuma fonte conta a história inteira sozinha.

Nem toda regressão gera erro

Esse ponto vale reforçar.

Uma nova versão pode piorar o produto sem criar nenhum erro técnico.

Uma tela pode passar a exigir mais cliques.

Um carregamento pode ficar mais lento.

Uma mensagem pode ficar menos clara.

Uma ação importante pode perder destaque.

Um novo fluxo pode reduzir conversão.

Do ponto de vista da aplicação, tudo funciona.

Do ponto de vista do produto, houve regressão.

É por isso que acompanhar release apenas por logs de erro deixa parte importante da história de fora.

Qualidade não é ausência de exception.

É comportamento saudável dentro do contexto esperado.

O tamanho da entrega muda o risco

Quanto mais mudanças entram juntas, mais difícil fica entender o que aconteceu.

Imagine um release com vinte features, dez correções e mudanças estruturais importantes.

Depois dele, uma métrica piora.

Qual alteração foi responsável?

Talvez nenhuma isoladamente.

Talvez exista interação entre duas.

Talvez uma mudança pequena tenha produzido um efeito inesperado.

Releases menores reduzem esse espaço de investigação.

Não eliminam risco.

Mas diminuem a quantidade de variáveis envolvidas.

Isso é uma das razões pelas quais entrega contínua não deveria ser vista apenas como automação de deploy.

Ela também melhora a capacidade de aprender.

Mudanças menores produzem feedback mais específico.

Velocidade de entrega não é velocidade de desenvolvimento

Times muitas vezes tentam aumentar velocidade fazendo mais coisas ao mesmo tempo.

Mais features.

Mais branches.

Mais mudanças acumuladas.

Só que velocidade real aparece quando o caminho entre decisão e aprendizado fica menor.

Construir.

Entregar.

Observar.

Aprender.

Ajustar.

Se uma feature leva uma semana para ser desenvolvida, mas depois fica um mês esperando uma janela de release, existe atraso.

Se é publicada rapidamente, mas ninguém acompanha o resultado, também existe atraso.

Porque o aprendizado ficou para depois.

Velocidade de produto não é apenas escrever código rápido.

É reduzir o tempo necessário para descobrir se uma decisão estava certa.

O feedback deveria voltar para o próximo ciclo

Uma release não deveria produzir apenas uma versão nova.

Deveria produzir informação.

Descobrimos que determinado fluxo é pouco utilizado.

Que uma mensagem gera dúvida.

Que o desempenho piorou em alguns dispositivos.

Que uma etapa adicional reduziu conclusão.

Que determinado erro acontece mais do que imaginávamos.

Tudo isso deveria influenciar o que fazemos em seguida.

Caso contrário, estamos coletando observações sem alterar decisões.

O ciclo só fecha quando o aprendizado retorna para a construção.

É aí que produto deixa de ser uma sequência linear:

ideia → design → desenvolvimento → deploy.

E passa a funcionar como sistema:

criação → entrega → observação → aprendizado → nova criação.

O último passo se conecta novamente ao primeiro.

Existe trabalho em remover também

Uma das consequências naturais de operar produtos por tempo suficiente é o acúmulo.

Flags antigas.

Experimentos encerrados.

Código de compatibilidade.

Métricas que ninguém consulta.

Dashboards abandonados.

Funcionalidades pouco utilizadas.

Configurações criadas para situações que já não existem.

Tudo isso continua dentro do sistema.

É fácil associar evolução àquilo que adicionamos.

Mas produtos saudáveis também precisam remover.

Depois que uma mudança prova seu valor, talvez possamos remover a versão anterior.

Depois que um rollout termina, a flag pode desaparecer.

Depois que um experimento acaba, o código experimental não deveria ficar para sempre.

Depois que uma métrica perde relevância, talvez não faça sentido continuar coletando.

Manutenção também é saber fechar ciclos.

Pronto é um estado temporário

Talvez essa seja uma das ideias que mais mudam quando começamos a construir produtos por períodos mais longos.

“Pronto” existe.

Mas dura pouco.

Uma feature pode estar pronta para lançamento.

Uma versão pode estar pronta para produção.

Um fluxo pode estar pronto para determinado estágio do produto.

Depois chegam novos usuários.

Novas necessidades.

Novas restrições.

Novas decisões.

O contexto muda.

E algo que estava perfeitamente adequado pode deixar de estar.

Isso não significa que precisamos viver em uma refatoração infinita.

Significa apenas que software em uso continua em movimento.

Por isso, conclusão em produto quase sempre é contextual.

Está pronto para agora.

E isso pode ser suficiente.

Indo além da criação

Ao longo desta série, começamos com uma ideia simples:

construir é só o começo.

Passamos pelo design e pelos estados que existem fora do cenário ideal.

Pela copy que ajuda alguém a entender o produto.

Pelos dados que mostram se aquilo que criamos está sendo utilizado.

Pela observabilidade que revela quando alguma coisa falha.

Pela performance que nasce das decisões acumuladas.

Pela acessibilidade que define para quem a experiência realmente funciona.

Todas essas discussões chegam ao mesmo lugar.

Criar um produto não é apenas decidir como ele vai existir.

É construir condições para que ele possa continuar existindo depois da primeira entrega.

Ser atualizado.

Observado.

Corrigido.

Questionado.

Simplificado.

E, quando necessário, removido.

Talvez esse seja o ponto em que a relação com software muda.

Você deixa de olhar para o deploy como uma linha de chegada.

Porque percebe que o que entrou em produção ainda precisa enfrentar aquilo que nenhum ambiente de desenvolvimento consegue reproduzir completamente:

a realidade.

O deploy encerra a construção de uma versão.

O produto continua.