Branch & Merge Claudio Leite

Sobre http://blog.lambda3.com.br/ @claudiobernardo

O que estratégias de Branch tentam resolver ? Agenda Conceitos Básicos O que estratégias de Branch tentam resolver ? Estratégias de Branch: Por Release Estratégias de Branch: Por Qualidade Estratégias de Branch: Por Feature Demonstração

Cenário “Uma empresa de médio porte está em franco crescimento, aproveitando oportunidades do mercado. Suas aplicações estão se tornando mais complexas e o time de desenvolvedores está crescendo. Nos últimos anos, a empresa tem sofrido com uma demanda crescente por suporte, devido constantes falhas no software em produção. A qualidade do software gerado pelos times é sofrível e essa percepção tem crescido no mercado. A empresa espera continuar crescendo, mas precisa corrigir e evitar novos problemas com a gestão de seu processo de desenvolvimento de software. Recentemente, a empresa ouviu falar sobre as novas tendências no desenvolvimento ágil e os benefícios da abordagem para Modern Apps.”

Conceitos Básicos

Controlador de Versão É um repositório que contém os arquivos necessários para o desenvolvimento do seu projeto Mantém Controle sobre quais mudanças ocorreram: Quem ? O que ? Quando ? Porque ? É um dos princípios básicos do ciclo de desenvolvimento de software e que ajuda para que os desenvolvedores trabalhem colaborativamente Usa conceitos básicos como check-out, check-in, get latest, labeling ...

Branch Branch permite que seja realizado desenvolvimento em paralelo Implementando features diferentes em branches diferentes com a mesma base de código Mantém diferentes releases em branches diferentes Branch == Isolar / Isolamento Estratégias Comuns: Branch por Release Branch por Feature Branch por Time Branch por Qualidade Regra Básica: NÃO CRIE BRANCH! Apenas quando necessário (KISS) Branch não é Label!

Merge Merge é uma operação de reconciliação de código. Possibilidade de Merge automático Merge permite que você passe as mudanças de um branch para o outro Forward Integration Reverse Integragion Main R1 R1.1 R2 R2.1 FI for Release

O que Branch tenta resolver ?

O que Branch Tenta Resolver ? Release Code When it is Ready Independent Construction of Features Suspension of Coding Know what code is Released Quando o código de Release está Pronto Construção Independente de Features Suspensão de Código – Code Freezen Saber Qual Código foi liberado para Release

Branch por release

Branch por Release (Staircase) Test Produção R2 C2 B Test Produção R3 Test

? ? Bugs R1 R2 R3 Test Produção Test Produção Test C1 B C3 RI C4 RI C6

Pros & Cons Pros : Modelo mais simples de ser usado Modelo mais simples para manter uma única versão Mesmo processo para hotfix ou acertos da release Menor gerência de Branches Cons : Não é muito flexível quanto os outros padrões Quanto mais release ativos, mais complicado realizar FI Necessidade de multiplos ambientes de testes Não suporta desenvolvimento em paralelo Necessidade de recriação de builds para cada release

Branch por qualidade

Branch por Qualidade (Basic Plan) Dev B QA B RI Prod

Branch por Qualidade (Safe Keeping) main B test B RI prod B B  Safe Keeping R1  Safe Keeping R2

Bugs no Branch de QA Prod QA HF dev Rx RI QA L1 L1 L2 B RI BUG B RI FI RI RI B HF FI dev FI Se vc não tiver sob uma politica de compliance, como a SOX por exemplo, você pode liberar o acesso do desenvolvedor no ambiente de QA e isso facilita muito a vida, mas se vc tem que seguir as regras da SOX, você tem que saber quem fez a requisição de promoção do código para QA, quem autorizou, quem fez a promoção para PROD entre várias outras regras. Então nesse modelo o melhor é criar um Branch de HOT-FIX e arrumar.

Bugs no Branch de Produção RI Bug RI B L-QA2 L-QA2 QA L-QA1 L-QA3 L-QA5 RI FI RI B RI FI RI FI FI FI B L-QA4 HF dev Release 1 Release 2 Release 3 RI

Pros & Cons Pros : Permite maior Flexibilidade Facilidade para trabalhar com multiplos Branches Cons : Dependendo da estrutura elaborada pode ser muito complexa Requer uma pessoa dedica para gerenciar sua estrutura e compilação Sem documentação, você pode ser perder e não saber mais onde está o seu código.

Branch por feature

Branch por Feature feature 4 feature 3 feature 2 feature1 main FI RI FI FI feature 2 RI FI FI feature1 RI FI main B Fazer uma compilação, após fazer uma FI de main

Bug feature 4 feature 3 feature 2 feature1 main FI RI FI FI feature 2 RI FI FI feature1 RI FI main B Bug Após fazer o merge da Feature 1 para Main e for achado um bug, esse bug tem que ser corrigido em main porque se você já jogou em DEV, está sendo considerado que essa feature será colocada na próxima release. Isso ocorre no caso de o bug não ter sido introduzido no ultimo check-in, pois fazer um rollback para versões antigas é complicado e você terá que saber quais features já integraram e levaram o bug junto.

Pros & Cons Pros : Separa o desenvolvimento das features Permite uma flexibilidade para escolher o que vai no seu release Facilita o debug (problema em uma feature não afeta outra) Ajuda no trabalho com features que dependem de um tempo maior de desenvolvimento Cons : Pode ficar muito complicado Os times responsáveis pelas features devem sempre lembrar de sincronizar com o Branch de DEV Pode complicar um pouco a vida de desenvolvedores que estão trabalhando em mais de uma feature Exige pelo menos um ambiente de testes por cada feature As vezes pode ser necessário mais de um Branch de Integração

Demonstração Branch por feature VS2012

Obrigado !