Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Branches-Intro

362 views

Published on

  • Be the first to comment

Branches-Intro

  1. 1. Uso de Branches no Sistema de Controle de Versão (Em Busca do Modelo Ideal para a sua empresa) (2012/03/22) Marcio Marchini marcio@BetterDeveloper.net
  2. 2. Branches 1.  A criação de um branch representa uma mudança na política de codificação. (Nova versão? Novo cliente? Etc) 2.  Modelos de branching distintos servem melhor para situaçãoes distintas (times/empresas/produtos distintos)
  3. 3. Bibliografia Usada / Nomenclatura & Classificação 1.  “Continuous Delivery” (livro Amazon). Especialmente o Capítulo 14 (e 13). 2.  "Advanced SCM Branching Strategies" http://www.vance.com/steve/perforce/ Branching_Strategies.html 3.  "Streamed Lines: Branching Patterns for Parallel Software Development"http:// www.cmcrossroads.com/bradapp/acme/branching/ 4.  "Version Control for Multiple Agile Teams" http://www.infoq.com/articles/agile- version-control 5.  "Feature Branch" http://martinfowler.com/bliki/FeatureBranch.html 6.  "The Importance of Branching Models in SCM” http://framework.zend.com/ wiki/download/attachments/1129/SCMBranchingModels.pdf?version=1 7.  "A successful Git branching model” http://nvie.com/posts/a-successful-git- branching-model/ , http://github.com/downloads/nvie/gitflow/Git-branching- model.pdf 8.  “TFS Branching Guide” http://vsarbranchingguide.codeplex.com/releases/ view/38849
  4. 4. Principais modelos de Branches 1.  Branch para (fechar o) Release (ao congelar para a release) 2.  Branch por (inicio de) Release (ao se iniciar o trabalho da release) 3.  Branch por Componente 4.  Branch por Feature 5.  Branch por Time 6.  Branch (quase) Nunca 7.  Branch como Essência, Sempre 8.  Modelos Mistos
  5. 5. Branch para (congelar pra) Release – Visão Geral 1.  Descrição •  Imediatamente antes de empacotar (para um RC – Release Candidate) •  Trunk é o mainline (baseline) •  Branch quando se congela o Release Candidate. Vira “manutenção”. Branches = Pequenos apêndices numa coluna vertebral •  Bug fixes importantes são corrigidos no branch (apêndice cresce ligeiramente) e é dado merge de volta no trunk 2.0 (RC)1.0 (RC) 3.0 (RC) Time já começando na 2.0 Correções/ajustes/patches
  6. 6. Branch para (congelar pra) Release – Pros e Cons 1.  Pros •  Branches têm vida curta. Baixo overhead (não custoso) •  Amigável a Continuous Delivery (trunk tem continuidade, trends ok no jenkins etc) •  Não bloqueia novo desenvolvimento (paraleliza com manutenção / ajustes) •  Fácil de dar manutenção a versões antigas em campo (commit no mini-branch / apêndice, merge no trunk se necessário) 2.  Contras / Ressalvas / Dicas •  Times diferentes têm velocidades diferentes, não conseguem entregar simultaneamente. Use Branch por Componente nesse caso. •  Trunk/mainline tem alto risco de se tornar quebrado sempre. Necessita Continuous Integration para prevenir. Ou: esconder/desabilitar features incompletas (mais detalhes no livro Continuous Delivery). •  Impossível escolher seletivamente features a incorporar (ex: Linux Kernel / Linus). Nesse caso, veja Branch por Feature. •  Necessidade de aplicar um patch em N branches de releases em campo (e.g. bug na 12.0 tem que ser corrigido na 13.0, 14.0, 15.0 e trunk)
  7. 7. Branch por Componente 1.  Descrição •  Arquitetura modular, cada componente macro em um branch 2.  Pros •  Lida bem com times diferentes com velocidades diferentes •  Possibilita times dispersos geograficamente 3.  Contras / Ressalvas / Dicas •  Se você possui um time por componente, isso se torna Branch por Time. •  Idealmente as entregas deveriam ser de binários (LIB, DLL, JAR)
  8. 8. Branch por (início de) Release – Visão Geral 1.  Descrição •  Criado no início do desenvolvimento da Release •  Estrutura em escada (branch de branch de branch…) ou 1 degrau que precisa dar merge de volta sempre. •  Cada novo release começa com um branch/degrau a partir da anterior Des 1.0 Des. 2.0 Des. 3.0 Forma 1: Sem mainline. Má utilização do VCS (mas não precisa merge de volta em trunk) Des. 2.0 Forma 2: Com mainline. Requer merges completos. Mas como fica o patch da 2.0 após 3.0 começar? Des. 3.0 Era assim na Ch*****c, por exemplo. 1.0 2.0 3.0 Correções/ ajustes/ patches Correções/ ajustes/ patches
  9. 9. Branch por (início de) Release – Pros e Contras 1.  Pros •  Suporta patch de versões antigas em campo (no degrau correspondente da escada) 2.  Contras / Ressalvas / Dicas •  Na forma #1 Não existe o conceito de mainline - Impossível ver/obter trends etc no Build Contínuo. Na forma #2 esse problema é aliviado (às custas do mega merge necessário ao fim de cada versão) mas existem saltos grandes de trend no trunk (pois parte do histórico está em outro branch) •  Difícil ver que código é comum entre releases •  Trabalhoso fazer patch de versão antiga – precisa propagar em todos os degraus subsequentes. •  Trabalhoso demais se os Releases são frequentes •  Não promove desenvolvimento em paralelo
  10. 10. Branch por Feature – Visão Geral 1.  Descrição •  Explicado bem em http://bit.ly/bBjxbS •  Cada User Story / Use Case é um Branch que precisa ter um Aceite •  Líder técnico etc deveria revisar e aceitar/recusar no mainline
  11. 11. Branch por Feature – Pros e Cons 1.  Pros •  Promove mainline sempre estável enquanto times trabalham em features distintas •  Trabalho incompleto não afeta outros membros (pois é localizado no branch) •  Histórico no controle de versão semanticamente mais rico (cada branch & merge no trunk é um bug fix completo ou User Story Completa) •  Mapeia diretamente com atividade Kanban •  Fácil de fazer em um DVCS como Git. Modelo promovido pelo GitHub (“fork”) 2.  Contras / Ressalvas / Dicas •  Mudanças no mainline devem ser mergeadas em todas as branches diariamente. •  Branches precisam ser de curta duração (1 sprint) •  Nenhum novo branch até que a User Story anterior seja considerada DONE •  Refactorings divergem. Refatorações devem ser mergeadas imediatamente. •  Pra Build Contínuo é preciso emular um “candidato total” com trunk + merge de todos os branches (trunk’) •  Requer times pequenos e experts •  Relativamente fácil no CVS e GIT mas bastante trabalhoso no SVN •  Requer avalanche de integrações. Criticado pelo Fowler http://bit.ly/bBjxbS
  12. 12. Branch por Time – Visão Geral 1.  Descrição •  Detalhes em http://bit.ly/ctlRvc por Henrik Kniberg •  Testes unitários e de aceitação rodam em cada commit em cada branch / trunk •  Cada branch tem um owner que define as políticas •  Mainline (trunk/head) sempre estável para Release
  13. 13. Branch por Time – Pros e Cons 1.  Pros •  Habilita times grandes a trabalharem em streams múltiplos. •  Mainline (head/trunk) sempre estável para release •  Habilita times pequenos em sub-áreas do sistema •  Menos branches do que Branch by Feature 2.  Contras / Ressalvas / Dicas •  Todo merge em todo branch deveria ser trazido para todo outro branch imediatamente. Merges diários (mas teoricamente não muito problemáticos) •  Instabilidade de trunk/mainline ainda existe, mas em “trunks de time” •  Cada branch precisa de um pipeline de deploy (build próprio etc) •  Não se pode dar merge de 1 mudança no trunk – tem que ser todo o branch •  Branches divergem mais rapidamente (muitas pessoas comitando) •  Merging mais complexo do que Branch por Feature.
  14. 14. Branch (quase) Nunca 1.  Descrição •  Detalhes em Continuous Delivery, capítulo 14 •  Ter um trunk e tentar esconder as features em tempo de execução, até estarem prontas •  Modelo ok para times extremamente pequenos ou softwares bem pequenos, mas inviável no nosso escopo, então não expandirei aqui •  Essência da filosofia: Branch = dor, evite a dor. Pelo menos minimize ao máximo.
  15. 15. Branch como Essência, Sempre 1.  Descrição •  (Veja Diagrama maior no próximo slide) •  Utilizado em um sistema de controle de versão onde o conceito de branch é o cerne do modelo •  Casa bem com Git, onde a metáfora é de grafo com nodos e arestas, e a pessoa pode pegar/contribuir novas arestas&nodos nesse grafo •  Permite a integrantes combinarem partes de terceiros, escolherem o que entra e o que não entra •  Permite um modelo misto dos anteriores, evitando overhead •  Popularizado com http://nvie.com/posts/a-successful-git-branching-model/ •  Utilização de várias “pistas paralelas”, cada qual com um modelo: branch por features, uma branch por release, etc. Veja imagem.
  16. 16. Branch como Essência, Sempre (imagem maior)
  17. 17. FIM. Piloto? FIM. Vamos começar um piloto?

×