Your SlideShare is downloading. ×
Versionamento Ágil com Git
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Versionamento Ágil com Git

1,121
views

Published on

Como paramos de nos preocupar e …

Como paramos de nos preocupar e
aprendemos a amar versionamento ágil

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,121
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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? ?