Entregar / Mostrar / Perguntar: uma estratégia moderna para lidar com seus branches
Atenção: este texto foi traduzido, editado e adaptado por @nawarian. Você encontra o texto original em inglês no blog do MartinFowler através deste link.
Entregar/Mostrar/Perguntar é uma estratégia de ramificação (branching) que combina as funcionalidades de Pull Requests com a habilidade de entregar alterações de software continuamente. As mudanças são categorizadas como Entregar (fazer merge imediatamente sem revisão), Mostrar (abrir um pull request para revisão mas fazer um merge imediatamente) ou Perguntar (abrir um pull request para discussão antes de fazer o merge).
Conteúdo do post
Como fazer integração contínua sem Pull Requests?
Pull Requests foram adotados por muitos times de desenvolvimento de software. Algumas pessoas os amam, e outras desejam alcançar a tão sonhada Integração Contínua - onde você nunca cria branches e seu time integra suas mudanças o tempo todo.
Em vários aspectos, Pull Requests são ferramentas fantásticas. Ferramentas de versionamento oferecem funcionalidades de revisão de código maravilhosas. Há vários provedores SaaS que oferecem serviços que podem rodar em seus pull requests - desde rodar testes e verificar qualidade de código até fazer o deploy de ambientes de homologação.
Mas a adoção de Pull Requests como a principal forma de contribuir com código criou alguns problemas. Nós perdemos um pouco da mentalidade "Pronto pra lançar" que tínhamos quando fazíamos Integração Contínua. Funcionalidades em desenvolvimento ficam fora de cena até ficarem prontas para integração, e assim caímos nas armadilhas da integração de baixa frequência que a Integração Contínua procura resolver.
As vezes Pull Requests ficam parados, ou nós mesmos ficamos sem muita ideia de o que fazer enquanto esperamos por uma revisão. As vezes eles ficam inchados por mudanças não relacionadas e pequenas melhorias que a gente faz pensando "ah, já que eu tô aqui mesmo..."
Nós também ficamos cansados com o número de Pull Requests que precisamos revisar, e paramos de falar sobre código. Nós paramos de prestar atenção e clicamos em "Aprovar" ou mandamos o famoso LGTM sem muito senso crítico.
Introduzindo o Entregar / Mostrar / Perguntar
Existe uma abordagem de ramificação (branching) que eu utilizei com meus times. Funcionou muito bem, então eu gostaria de compartilhar contigo.
Toda vez que você fizer uma alteração, você precisa escolher três opções: Entregar, Mostrar ou Perguntar.
Entregar
Esta estratégia se assemelha muito com Integração Contínua: se você quer fazer uma alteração, faz diretamente no seu branch principal. Ao fazer isto você não precisa esperar alguém fazer o deploy das suas alterações para o ambiente de produção e nem pede revisão de código. Tudo sem muito alarde: faça a alteração utilizando todas as técnicas de Integração Contínua que tornam este procedimento seguro.
Isto funciona muito bem quando:
- Eu adiciono uma funcionalidade utilizando uma técnica bem estabelecida
- Eu corrijo um bug simples / pequeno
- Eu atualizo documentação
- Eu fiz alguma melhoria no meu código baseado em feedback
Mostrar
Aqui é onde nós adotamos a mentalidade de Integração Contínua e ao mesmo tempo aproveitamos as coisas boas que Pull Requests nos dão. Você faz a mudança num branch, abre um Pull Request e faz um merge sem esperar ninguém. Você só espera pelos testes automatizados (testes, cobertura de código, ambiente de homologação, etc.), mas não espera pelo feedback de ninguém para prosseguir com o deploy da sua alteração.
Desta forma você entrega as suas alterações rapidamente enquanto cria o espaço para feedback e conversa. O seu time recebe notificações dos Pull Requests e podem revisar o que você fez. Eles podem então dar feedback na sua abordagem ou código, fazer perguntas e aprender através das suas alterações.
Isto funciona bem quando:
- Eu quero feedback sobre como este código poderia ser melhor
- Eu gostaria de mostrar uma nova abordagem ou padrão que utilizei
- Eu refatorei X e quero que meu time fique ciente desta alteração
- Eu quero compartilhar com meu time a solução para um bug interessante
Perguntar
Esta é a estratégia que muitos de vocês já estão acostumados. Nós fazemos nossas alterações num branch, abrimos um Pull Request e esperamos pelo feedback dos colegas antes de fazer o merge. Talvez não tenhamos certeza de que utilizamos a abordagem correta. Talvez tenha algo no código que não gostamos muito mas não sabemos como melhorar. Talvez você tenha experimentado algo novo e gostaria de ver o que seus colegas acham.
Ferramentas de revisão de código modernas dão espaço para este tipo de conversa e você pode até colocar o time inteiro para revisar e discutir um Pull Request juntos.
Isto funciona bem quando:
- Eu não tenho certeza de que minhas mudanças vão funcionar
- Eu quero saber como meus colegas se sentem sobre esta nova abordagem
- Eu preciso de ajuda pra melhorar meu código
- Eu já encerrei o expediente hoje e vou fazer o merge amanhã
Regras
- Revisão de código ou "Aprovação" não devem ser requisitos para um Pull Request ser integrado no branch principal
- Autores fazem o merge de seus próprios Pull Requests. Desta forma, estas pessoas controlam se as alterações são do tipo Mostrar ou Perguntar, e decidem quando as mudanças vão para produção
- É possível utilizar todas as técnicas de Integração Contínua e Entrega Contínua que ajudam a manter o branch principal pronto para ser lançado para produção. Feature Toggles são um exemplo.
- Ramificações (branches) não devem existir por muito tempo, e devemos fazer um rebase com o branch principal com frequência
Conversa
Enquanto Pull Requests podem ser uma forma muito útil de falar sobre alterações de código, eles trazem consigo algumas armadilhas. A armadilha mais sedutora é a ideia de que eles podem substituir outras formas de discussão.
Um problema comum com ramificações é que autores decidem utilizar uma abordagem sem a discutir com ninguém. Quando o Pull Request finalmente é aberto, o tempo já foi investido numa implementação que pode não ser a melhor. Revisores são influenciados pela solução já adotada e têm dificuldade em sugerir abordagens diferentes. Quanto mais mudanças e mais velho for o branch, maior o problema. Converse com seu time antes de começar, para que você colete mais e melhores ideias e possa previnir retrabalho.
Lembre-se de que Pull Requests não são a única forma de Mostrar ou Perguntar. Faça uma ligação ou vá até a mesa de alguém. Mostre seu trabalho o quanto antes e frequentemente. Peça ajuda e feedback o quanto antes e frequentemente. Trabalhe nas tarefas em conjunto com seus colegas.
Não abrir um Pull Request não é uma boa razão para evitar conversar sobre o código. É importante que seus colegas mantenham uma boa cultura de feedback e conversem entre si sobre o que acham e aprendem.
Equilíbrio
Dadas essas três opções, quais eu deveria escolher com maior frequência?
Depende. Eu acho que cada time tem seu equilíbrio em cada momento.
Quando você está entregando funcionalidades utilizando uma abordagem já consolidada, você vai Entregar mais. Quando você confia no time e todos compartilham dos mesmos padrões de qualidade, você também fará mais Entregas.
Mas se vocês ainda estiverem se conhecendo ou fazendo algo completamente novo, então a necessidade de conversa é maior. Vocês irão Mostrar e Perguntar com mais frequência. Um iniciante talvez Mostre e Pergunte mais, enquanto um sênior Entrega muito mais, mas de vez em quando Mostra uma nova técnica ou uma refatoração que todo mundo deveria tentar.
Alguns times não têm muita flexibilidade. Algumas indústrias são altamente reguladas e o processo de aprovação ou revisão de código são obrigatórios para cada alteração de código. Há várias formas de implementar isso - com ou sem ramificações - que eu não vou comentar aqui.
Meu time deve adotar esta abordagem?
Vocês já adotaram.
Pense bem em como seu time funciona e você vai reparar que você já está lidando com Entregar/Mostrar/Perguntar. A maioria dos times normalmente cai em Entregar na maioria das vezes ou Perguntar na maioria das vezes.
Se você entrega na maioria das vezes
Se você raramente cria um branch e todos os commits vão direto para o branch principal, você Entrega na maioria das vezes. Se este é o seu caso, pense como Mostrar um pouco mais pode te ajudar.
Um grande motivo pelo qual os modelos de Pull Request se tornaram tão populares é que eles dão suporte a times que trabalham de forma remota e assíncrona. Mostrar explicitamente as partes interessantes do seu trabalho aos outros pode ajudá-los a aprender e sentirem-se parte da conversa, especialmente quando se trabalha de forma remota e em fuso horários diferentes.
Eu também notei (especialmente em times que não conversam o suficiente [1]) que fazer sempre o merge para o branch principal pode significar que algumas mudanças problemáticas podem passar desapercebidas por algumas semanas. Quando isto acontece é difícil ter uma conversa útil sobre elas porque os detalhes e contextos já se perderam no tempo. Encorajar colegas a Mostrar significa que vocês vão conversar mais sobre o código comumente.
Se você pergunta na maioria das vezes
Se seu time abre Pull Requests para a maioria das alterações, vocês Perguntam na maioria das vezes. Se por um lado Pull Requests são uma ferramenta útil para qualidade e feedback, por outro lado eles podem criar um problema de escalabilidade. O inevitável sobre pedir aprovação é que isso leva tempo. Se muitas mudanças estão na fila do feedback, a qualidade do feedback diminui ou a velocidade diminui. Tente Mostrar com mais frequência para que você tire proveito do melhor dos dois mundos.
O motivo pelo qual vocês dependem muito de Perguntar pode ser falta de confiança. "Todas mudanças precisam ser aprovadas" ou "Todo Pull Request precisa de 2 revisores" são práticas comuns, mas demonstram falta de confiança no time de desenvolvimento.
Isto é problemático porque a aprovação é apenas um band-aid - ela não vai corrigir seu problema de confiança. Mostre um pouco mais para tirar um pouco da pressão do ciclo de desenvolvimento e dê maior atenção a atividades que aumentam a confiança no time como treinamentos, discussões em time ou programação em pares. Toda vez que uma pessoa Mostra em vez de Perguntar é uma oportunidade para elas construírem confiança com o time.
Outro motivo para depender muito de aprovação pode ser que seu time não se sinta seguro em enviar mudanças diretamente para o branch principal. Neste caso o que você precisa é aprender sobre como implementar técnicas que mantenham o seu branch principal sempre pronto para lançamento. Enquanto isso, Mostrar mais pode ajudar a diminuir a barreira para lançar mudanças de forma segura para produção. Reduzir esta barreira vai servir de incentivo para seus colegas - se você encontrar formas de tornar suas alterações mais seguras, elas podem ir para produção mais cedo.
Conclusão
Então o que é Entregar/Mostrar/Perguntar? Em suma, são duas coisas:
Primeiro – um truque para te ajudar a obter o melhor de dois mundos - fazer o merge do seu próprio pull request sem aguardar feedback e dar atenção ao feedback quando este chegar.
Segundo – uma forma mais inclusiva e dinâmica de lidar com estratégias de ramificação. Entregar/Mostrar/Perguntar nos lembra que a abordagem de cada time normalmente fica em algum lugar entre Entregar sempre e Perguntar sempre. Isto nos encoraja a pensar sobre cada alteração independentemente e nos perguntar-mos: eu deveria Entregar, Mostrar ou Perguntar?
Agradecimentos
Obrigado a todos que ajudaram com feedback detalhado na preparação deste texto: Martin Fowler, Brian Gunthrie, Federico Blancato, Stephen Creswell e Paul Hammant.
Agradeço também ao Matthew Harward, Kief Morris, Giuseppe Pereira, Marcos Vinícius da Silva, Birgitta Böckeler, Prashanth R, Premanand Chandrasekaran, João Paulo Moraes e Mark Taylor, que discutiram o rascunho deste texto numa mailing list interna da ThoughtWorks.
Notas de rodapé
1: Pair Programming ou programação em pares é uma técnica efetiva para encorajar comunicação contínua num time
Comentários