Processo de gerenciamento de releases para entregas rápidas

Um processo de gerenciamento de releases é o conjunto de passos que leva uma mudança de “integrada” a “rodando em produção e explicada às pessoas que ela afeta”. Para uma equipe que entrega com frequência, resume-se a sete passos: planejar o escopo, isolar a mudança, compilar e testar, aprovar, fazer o deploy e verificar, comunicar e revisar. Cada passo precisa de um responsável nomeado e de um critério de saída, ou deixa de acontecer sem alarde.

Este guia pressupõe uma equipe de 5 a 50 engenheiros que fazem deploy toda semana ou todo dia e querem que o processo fique fora do caminho.

O que é o processo de gerenciamento de releases?

É o caminho repetível que uma mudança segue até chegar aos usuários: escopo, build, teste, aprovação, deploy, verificação, anúncio e retrospectiva. O objetivo de escrevê-lo é que toda release siga o mesmo caminho, de modo que alguém de férias, um novo contratado ou um engenheiro de plantão às 2 da manhã possa executá-lo sem perguntar a ninguém como funciona.

Quais são os diferentes tipos de gerenciamento de releases?

Há três tipos práticos: deploy contínuo, releases agendadas e gerenciamento de mudanças regulado. Eles diferem em quanto acontece antes de uma release e em quanto é automatizado. O deploy contínuo entrega cada mudança integrada, as releases agendadas agrupam mudanças em um trem e o gerenciamento de mudanças regulado acrescenta aprovação formal e trilha de auditoria.

A maioria das equipes é uma mistura. Um produto SaaS pode fazer deploy contínuo enquanto o app mobile sai em um trem semanal, e o único serviço de pagamentos que os auditores acompanham segue um registro formal de mudança. Escolha o tipo por serviço, não por empresa. Onde as mudanças são expostas aos poucos, a release e o anúncio viram eventos separados, caso tratado em release notes de feature flag.

Quais são as responsabilidades de um release manager?

Um release manager é dono do caminho que uma mudança percorre até a produção. Ele mantém o calendário de releases, decide se uma mudança está pronta, executa ou supervisiona o deploy, toma a decisão de rollback, garante que os usuários sejam avisados e conduz a revisão depois.

Antes da release, confirma o escopo e checa se toda mudança arriscada tem um caminho de rollback. Durante ela, executa o checklist de deploy, acompanha os primeiros minutos das métricas de produção e chama o rollback cedo. Depois, confirma que as notas saíram e registra o que corrigir no processo.

Em uma equipe pequena, revezem o papel toda semana e escrevam o checklist para que ninguém precise de conhecimento tribal. Um monorepo com muitos pacotes lançados de forma independente costuma precisar de um responsável por pacote, ou o papel vira um gargalo.

Quais são os principais KPIs de gerenciamento de releases?

Acompanhe as métricas de entrega de software da DORA e acrescente uma sua: quanto tempo leva até os usuários serem avisados. A pesquisa da DORA identifica cinco métricas, divididas em vazão (lead time de mudança, frequência de deploy, tempo de recuperação de deploy com falha) e instabilidade (taxa de falha de mudança, taxa de retrabalho de deploy).

O guia da DORA as define em termos simples (dora.dev, software delivery metrics):

Materiais mais antigos listam quatro métricas-chave e chamam a recuperação de “time to restore”. O guia atual usa as cinco acima.

O mesmo guia alerta contra tratá-las como metas. Definir um objetivo como “tudo faz deploy várias vezes por dia até o fim do ano” convida as equipes a manipular os números, e as métricas devem ser lidas por aplicação ou serviço, não misturadas na empresa toda. O conselho prático dele para melhorar todas é reduzir o tamanho de cada mudança, porque mudanças menores são mais fáceis de revisar, de levar pelo pipeline e de recuperar.

Como a comunicação da release se encaixa no processo de gerenciamento de releases?

É o passo seis, e tem responsável e critério de saída como todos os outros: notas publicadas onde os usuários leem e equipes internas avisadas. É o passo que as equipes mais pulam, porque a ferramenta de deploy reporta sucesso no instante em que o código está no ar.

O jeito mais barato de manter esse passo em dia é escrever a entrada quando a mudança é integrada, não quando a release sai. O pull request já contém o título, o autor, a issue ligada e o contexto. Um rascunho construído a partir dele é editado, não escrito de memória uma semana depois. Essa é a ideia por trás da automação de changelog: derivar um rascunho no merge, retê-lo para uma pessoa aprovar e depois publicá-lo em todo lugar a partir de uma única fonte. O Changeloop funciona assim, redigindo entradas a partir de pull requests integrados com IA e retendo-as para aprovação antes de publicar qualquer coisa.

Duas variações merecem planejamento prévio. Suporte e vendas precisam de uma nota diferente da dos clientes, e para isso servem as release notes internas. Uma release causada por um incidente não tem tempo para o ciclo normal de redação, então mantenham um template curto pronto, como descrito em release notes de emergência. O template de release notes dá uma forma inicial para a versão voltada ao cliente.

Como manter o processo leve?

Automatize todo critério de saída que uma máquina possa checar e reserve as pessoas para os julgamentos. Um pipeline verde, um marcador de deploy nos dashboards e um rascunho de entrada de changelog por pull request integrado são checáveis. Se um plano de rollback é crível, ou se as notas fazem sentido para um cliente, é coisa para uma pessoa.

Para testar o processo, escolha uma release do mês passado e pergunte se alguém de fora da equipe conseguiria dizer, só pelo registro escrito, o que foi entregue, quem aprovou, como foi verificado e quando os usuários foram avisados. Qualquer lacuna é a sua próxima melhoria.

FAQ

Qual é a diferença entre gerenciamento de releases e gerenciamento de mudanças? O gerenciamento de releases leva um conjunto de mudanças a ser compilado, testado, implantado e anunciado. O gerenciamento de mudanças, no sentido ITIL, é o processo de aprovação e de risco em torno de cada mudança. Equipes que entregam com frequência incorporam a aprovação ao code review e às checagens automáticas.

Com que frequência devemos fazer releases? Tão frequentemente quanto seus testes e seu caminho de rollback permitirem, o que para muitas equipes web é todo dia ou mais. A orientação da DORA é reduzir o tamanho de cada mudança, já que mudanças pequenas são mais fáceis de revisar e de recuperar.

Equipes pequenas precisam de um release manager? Precisam das responsabilidades, mas não necessariamente do título. Revezem o papel entre os engenheiros, deem à pessoa do rodízio um checklist escrito e garantam que alguém seja dono de cada um dos sete passos.

O que um checklist de release deve incluir? Escopo confirmado, pipeline verde no commit que vai ser entregue, caminho de rollback nomeado, aprovação registrada, smoke checks após o deploy, métricas comparadas com a linha de base, release notes publicadas, suporte avisado e uma revisão agendada. Mantenha em uma página.

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