SlideShare a Scribd company logo
1 of 17
Download to read offline
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
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)
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
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
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
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)
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)
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
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
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
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
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
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.
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.
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.
Branch como Essência, Sempre (imagem maior)
FIM. Piloto?
FIM. Vamos começar um piloto?

More Related Content

Viewers also liked

Sistema de Controle de Versão - CVS, SVN e GIT
Sistema de Controle de Versão - CVS, SVN e GITSistema de Controle de Versão - CVS, SVN e GIT
Sistema de Controle de Versão - CVS, SVN e GITGabriel Rubens
 
Gb2011 roberto martinsconceição_dupont brasil
Gb2011 roberto martinsconceição_dupont brasilGb2011 roberto martinsconceição_dupont brasil
Gb2011 roberto martinsconceição_dupont brasilGalvabrasil
 
Dojo com Arduino e Program-ME
Dojo com Arduino e Program-MEDojo com Arduino e Program-ME
Dojo com Arduino e Program-MEDr. Spock
 
SVN - Subversion: Guia de sobrevivência do usuário
SVN - Subversion: Guia de sobrevivência  do usuárioSVN - Subversion: Guia de sobrevivência  do usuário
SVN - Subversion: Guia de sobrevivência do usuárioFabrício Campos
 
Carta proprosta de prestacao de servicos de consultoria gerencial
Carta proprosta de prestacao de servicos de consultoria gerencialCarta proprosta de prestacao de servicos de consultoria gerencial
Carta proprosta de prestacao de servicos de consultoria gerencialVitor Albuquerque
 

Viewers also liked (8)

Sistema de Controle de Versão - CVS, SVN e GIT
Sistema de Controle de Versão - CVS, SVN e GITSistema de Controle de Versão - CVS, SVN e GIT
Sistema de Controle de Versão - CVS, SVN e GIT
 
Gb2011 roberto martinsconceição_dupont brasil
Gb2011 roberto martinsconceição_dupont brasilGb2011 roberto martinsconceição_dupont brasil
Gb2011 roberto martinsconceição_dupont brasil
 
Aula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de RequisitosAula3 TEES UFS: Engenharia de Requisitos
Aula3 TEES UFS: Engenharia de Requisitos
 
Dojo com Arduino e Program-ME
Dojo com Arduino e Program-MEDojo com Arduino e Program-ME
Dojo com Arduino e Program-ME
 
SVN - Subversion: Guia de sobrevivência do usuário
SVN - Subversion: Guia de sobrevivência  do usuárioSVN - Subversion: Guia de sobrevivência  do usuário
SVN - Subversion: Guia de sobrevivência do usuário
 
Jboss tutorial
Jboss tutorialJboss tutorial
Jboss tutorial
 
Modelagem de Sistemas de Informação 04
Modelagem de Sistemas de Informação 04Modelagem de Sistemas de Informação 04
Modelagem de Sistemas de Informação 04
 
Carta proprosta de prestacao de servicos de consultoria gerencial
Carta proprosta de prestacao de servicos de consultoria gerencialCarta proprosta de prestacao de servicos de consultoria gerencial
Carta proprosta de prestacao de servicos de consultoria gerencial
 

Similar to Modelos de Branching no Controle de Versão

Versionamento Ágil com Git
Versionamento Ágil com GitVersionamento Ágil com Git
Versionamento Ágil com Gitelliando dias
 
Rogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJRogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJNathália Cruz de Oliveira
 
Rogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJRogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJNathália Cruz de Oliveira
 
Usando Git na Unity - Gaming For All 2021
Usando Git na Unity - Gaming For All 2021Usando Git na Unity - Gaming For All 2021
Usando Git na Unity - Gaming For All 2021Erik Cruz
 
Quintas da TI - Novidades do Exchange Server 2016
Quintas da TI - Novidades do Exchange Server 2016Quintas da TI - Novidades do Exchange Server 2016
Quintas da TI - Novidades do Exchange Server 2016Bruno Lopes
 
Gerência de configuração ágil
Gerência de configuração ágilGerência de configuração ágil
Gerência de configuração ágilClaudia Melo
 
Git workshop
Git workshopGit workshop
Git workshopYuri Reis
 
Porque todo programador deve utilizar Sistema de Controle de Versão?
Porque todo programador deve utilizar Sistema de Controle de Versão?Porque todo programador deve utilizar Sistema de Controle de Versão?
Porque todo programador deve utilizar Sistema de Controle de Versão?Marco Rosner
 
Vantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservicesVantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservicesFábio Rosato
 
Replicacao Object Sistemas
Replicacao Object SistemasReplicacao Object Sistemas
Replicacao Object Sistemastaniamaciel
 
Controle de Versão Distribuído com Git básico
Controle de Versão Distribuído com Git básicoControle de Versão Distribuído com Git básico
Controle de Versão Distribuído com Git básicoFabricio Nogueira
 
Boas práticas na configuração de jobs no Kubernetes
Boas práticas na configuração de jobs no KubernetesBoas práticas na configuração de jobs no Kubernetes
Boas práticas na configuração de jobs no KubernetesGraziella Bonizi
 
Web Training Aula 04: Introduction to Git
Web Training Aula 04: Introduction to GitWeb Training Aula 04: Introduction to Git
Web Training Aula 04: Introduction to GitMozDevz
 
vantagens e desvantagens do ciclo de vida de software
vantagens e desvantagens do ciclo de vida de softwarevantagens e desvantagens do ciclo de vida de software
vantagens e desvantagens do ciclo de vida de softwarejwniezzy
 
Intervalo técnico Git/SVN
Intervalo técnico Git/SVNIntervalo técnico Git/SVN
Intervalo técnico Git/SVNLuciano Lima
 

Similar to Modelos de Branching no Controle de Versão (20)

Versionamento Ágil com Git
Versionamento Ágil com GitVersionamento Ágil com Git
Versionamento Ágil com Git
 
Rogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJRogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJ
 
Rogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJRogue Snail Talk - Usando Git na Game Jam - WGJ
Rogue Snail Talk - Usando Git na Game Jam - WGJ
 
Usando Git na Unity - Gaming For All 2021
Usando Git na Unity - Gaming For All 2021Usando Git na Unity - Gaming For All 2021
Usando Git na Unity - Gaming For All 2021
 
Quintas da TI - Novidades do Exchange Server 2016
Quintas da TI - Novidades do Exchange Server 2016Quintas da TI - Novidades do Exchange Server 2016
Quintas da TI - Novidades do Exchange Server 2016
 
Gerência de configuração ágil
Gerência de configuração ágilGerência de configuração ágil
Gerência de configuração ágil
 
Git workshop
Git workshopGit workshop
Git workshop
 
Porque todo programador deve utilizar Sistema de Controle de Versão?
Porque todo programador deve utilizar Sistema de Controle de Versão?Porque todo programador deve utilizar Sistema de Controle de Versão?
Porque todo programador deve utilizar Sistema de Controle de Versão?
 
Git 101
Git 101Git 101
Git 101
 
Vantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservicesVantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservices
 
Replicacao Object Sistemas
Replicacao Object SistemasReplicacao Object Sistemas
Replicacao Object Sistemas
 
Monolith - An epic journey
Monolith - An epic journeyMonolith - An epic journey
Monolith - An epic journey
 
Controle de Versão Distribuído com Git básico
Controle de Versão Distribuído com Git básicoControle de Versão Distribuído com Git básico
Controle de Versão Distribuído com Git básico
 
Introdução ao Git
Introdução ao GitIntrodução ao Git
Introdução ao Git
 
Boas práticas na configuração de jobs no Kubernetes
Boas práticas na configuração de jobs no KubernetesBoas práticas na configuração de jobs no Kubernetes
Boas práticas na configuração de jobs no Kubernetes
 
Web Training Aula 04: Introduction to Git
Web Training Aula 04: Introduction to GitWeb Training Aula 04: Introduction to Git
Web Training Aula 04: Introduction to Git
 
Git hub and Laravel
Git hub and Laravel Git hub and Laravel
Git hub and Laravel
 
vantagens e desvantagens do ciclo de vida de software
vantagens e desvantagens do ciclo de vida de softwarevantagens e desvantagens do ciclo de vida de software
vantagens e desvantagens do ciclo de vida de software
 
Escalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLIDEscalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLID
 
Intervalo técnico Git/SVN
Intervalo técnico Git/SVNIntervalo técnico Git/SVN
Intervalo técnico Git/SVN
 

More from Marcio Marchini

More from Marcio Marchini (9)

Critérios de Aceite de Código Para Times Internos ou Terceirizados
Critérios de Aceite de Código Para Times Internos ou TerceirizadosCritérios de Aceite de Código Para Times Internos ou Terceirizados
Critérios de Aceite de Código Para Times Internos ou Terceirizados
 
É Pythonico, mas... é macarrônico
É Pythonico, mas... é macarrônicoÉ Pythonico, mas... é macarrônico
É Pythonico, mas... é macarrônico
 
Whitepaper-Custos
Whitepaper-CustosWhitepaper-Custos
Whitepaper-Custos
 
01-a-Intro-BetterDev
01-a-Intro-BetterDev01-a-Intro-BetterDev
01-a-Intro-BetterDev
 
OmbrosDeGigantes-TDC2014
OmbrosDeGigantes-TDC2014OmbrosDeGigantes-TDC2014
OmbrosDeGigantes-TDC2014
 
BDD-NamoroOn
BDD-NamoroOnBDD-NamoroOn
BDD-NamoroOn
 
01-b-Ping
01-b-Ping01-b-Ping
01-b-Ping
 
gae
gaegae
gae
 
mqm-Agile
mqm-Agilemqm-Agile
mqm-Agile
 

Modelos de Branching no Controle de Versão

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Branch como Essência, Sempre (imagem maior)
  • 17. FIM. Piloto? FIM. Vamos começar um piloto?