O documento discute o uso do versionamento ágil com Git para apoiar um processo ágil de desenvolvimento. Ele descreve como o Git permite branches separados por estória, permitindo paralelismo no desenvolvimento e histórico de desenvolvimento preciso, ao mesmo tempo em que facilita integração contínua e reduz conflitos. O processo atual envolve um branch por estória derivado do branch lógico mais próximo e branches separados para integração e versão estável.

1. 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

2. Quem?
Tiago M. Jorge
Agile Coach, WebCo Internet
Ronaldo M. Ferraz
Gerente de R&D, WebCo Internet

3. 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.

4. 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?

5. 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.

6. 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

7. Como fazíamos, fase 1
Changes Merges
Merges Changes
Release

8. 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

9. Como fazíamos, fase 2
Trunk
Changes Changes Changes
Changes Changes Changes
RC
Merges Merges
Stable

10. 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

11. 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

12. 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)

13. 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

14. 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)

15. Como fazemos atualmente
Story #1
Changes Changes
Story #2
Changes Changes
Story #3
Changes Changes
Master
Merges
QA
Merges
Stable

16. 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

17. 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

18. 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

19. 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

20. Melhorias futuras
Deploy contínuo e automatizado em QA
Uso de tags assinados para garantia de versões
releasable

21. Questões?
?