Versionamento Ágil com Git Como paramos de nos preocupar e aprendemos a amar versionamento ágil Brazil Scrum Gathering São Paulo, 13 de Maio de 2009
Quem? Tiago M. Jorge Agile Coach, WebCo Internet Ronaldo M. Ferraz Gerente de R&D, WebCo Internet
Por quê? * Uma dificuldade básica em projetos ágeis é decidir quando e como integrar uma estória. Se você separar as estórias, pode ter problemas ao integrar depois. Se não separar, pode ter problemas em tirar uma estória que não possa entrar ao final do sprint. Em todo caso, você também quer velocidade máxima de desenvolvimento.
Por quê? Ferramentas tradicionais oferecem pouco suporte a cenários mais sofisticados de versionamento. Branching e merging geralmente são trabalhosos e pouco confiáveis. Como, então, suportar um processo ágil de desenvolvimento que, ao mesmo tempo, permita os benefícios de integração contínua e reduza conflitos?
Por quê? * Agile Manifesto diz: Individuals and interactions over processes and tools E também diz: That is, while there is value in the items on the right, we value the items on the left more. Em outras palavras, processos que apóiam agilidade podem, e devem, ser considerados.
Agenda * Como fazíamos versionamento O problema dos processos tradicionais Vantagens de branches separados por estórias Como o Git se encaixa no processo Como fazemos versionamento ágil Situacões encontradas Desvantagens do processo Melhorias futuras
Como fazíamos, fase 1 Merges Merges Release
Como fazíamos, fase 1 Subversion Desenvolvimento direto no trunk Conflitos diários, vence o primeiro que fizer o commit Branch estável usando tags Histórico linear mas sem especificidade
Como fazíamos, fase 2 Trunk RC Merges Stable Merges
Como fazíamos, fase 2 Git Um branch para o desenvolvimento primário Branches ocasionais para desenvolvimento secundário Dois branches estáveis (release candidate, stable) com maior controle Redução de conflitos Histórico linear com mais especificidade
Problemas com o tradicional * Processos Um branch único: Favorece conflitos repetidos e freqüentes quebras do build Atrapalha o desenvolvimento paralelo entre times Atrapalha o desenvolvimento paralelo de estórias Não suporta uma code base continuamente releasable
Problemas com o tradicional Ferramentas CVS não é realmente um RCS Subversion Branching é pesado (cópia do branch original) Merging é limitado e trabalhoso Comerciais Geralmente bem limitados (vide locking strategies, por exemplo)
Branches separados (prós) * Paralelismo no desenvolvimento Não temos uma equipe de seis pessoas, e sim três equipes de duas. Granularidade em releases (depende ativamente da granularidade das estórias) Histórico impoluto e correto de desenvolvimento Fácil identificação da proveniência de bugs
Como o Git se encaixa Branches são essencialmente grátis; trabalho em pequenas unidades Merging extremamente poderoso (por padrão, 3-way recursive; podendo resolver múltiplos branches simultaneamente) Versionamento distribuído (commits locais, todo desenvolvedor tem o repositório inteiro, desenvolvimento ubíquo)
Como fazemos atualmente Story #1 Story #2 Story #3 Master Merges QA Merges Stable
Como fazemos atualmente Git Um branch por estória, derivado do branch lógico mais próximo Um branch para integração contínua (master) e um branch stable, com a versão do código que está em produção Integração de estórias após o done do time Integração contínua síncrona para a estória e assíncrona para o branch master
Como fazemos atualmente Tags regulares para QA baseados no master Tags lineares para deploy Histórico absoluto de desenvolvimento e produção de features Controle granular do que é releasable
Situações encontradas * Positivas Branch permanente para aumento de testes Migração paralela para o Rails 2.3 Remoção de estórias incompletas Negativas Desenvolvimento de um feature distante do dia-a-dia depende de rebases constantes
Desvantagens do processo * Curva de aprendizado mais íngreme (tanto do processo quanto do Git) Depende de estórias pequenas Funciona melhor com estórias auto-contidas Integração final acontece menos vezes dentro do sprint
Melhorias futuras Deploy contínuo e automatizado em QA Uso de tags assinados para garantia de versões releasable
Questões??