Versionamento Ágil com GitComo paramos de nos preocupar e aprendemos a amar versionamento ágil

Brazil Scrum GatheringSã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

Changes Merges

ChangesMerges

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

Stable

Changes Changes

Changes Changes

Merges Merges

Changes

Changes

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 atualmenteStory #1

Changes Changes

Story #2

Master

Changes Changes

Story #3

Changes Changes

Merges

Stable

QA

Merges

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?

?