Trunk Based Development – TBD

Neste micro artigo, irei explicar de forma resumida uma alternativa para desenvolvimento baseado em Trunk Based Development (TBD) em termos de layout de branch.

Trunk Based Deployment:

Trunk Based Deployment é um modele de controle de versão, onde os desenvolvedores colaboram com o código em uma única branch, podendo ser chamada de “Trunk”.

Este modelo tem como objetivo resistir a pressão para criar novas branch’s ao longo do projeto.

O desenvolvimento baseado em TBD tem como função acelerar a Integração Contínua / Entrega Contínua.

  • Integração contínua é uma prática de desenvolvimento de software em que os desenvolvedores, com frequência, juntam suas alterações de código em um repositório central.
  • Entrega contínua é uma prática de engenharia de software em que as equipes produzem em ciclos curtos, garantindo que os softwares possam ser lançados a qualquer momento e de forma confiável.

Em ambiente com grandes equipes atuando no mesmo projeto, geralmente projetos que não foram convertidos para micros serviços (MS), utilizam o TBD para agilizar todo o ciclo de Integração Contínua e Entrega Contínua.

Os membros dos projetos são responsáveis por transferir suas alterações a cada 24 horas.

Isso facilita que os códigos estejam sempre atualizados sob demanda, tornando a mais rápido a entrega do Software/Projeto.

Vejamos abaixo o fluxograma de um projeto que utiliza TBD.

Fluxograma de um TBD:

Todos os desenvolvedores trabalham no Trunk (commits em cinza). Pouco antes de um lançamento a branch é “fechada” por alguém que possui “poderes” dentro do projeto, garantindo que mais ninguém possa comprometê-lo.

Somente após o lançamento “corte da release” a branch é liberada novamente para seguir o seu fluxo diário.

E como ficam os Bugs Fix?

O Bug é encontrado após o lançamento. De fato, o Trunk (que não tinha nenhum tipo de congelamento de código) já passou da versão anterior.

Então …

A organização em questão não deseja lançar uma nova versão do produto com os commits mais recentes no trunk, Neste caso, passa ser necessário liberar o FIX de uma release preexistente.

Quando um bug é encontrado após o commit na branch, antes mesmo do corte da release, basta gerar a release FIX e em seguida gerar o commit na branch.

Novamente a branch será “fechada” e após validação Quality Assurance (QA) um corte é definido gerando a release final daquele Sprint.

Ressalvas:

Dependendo do tamanho da equipe, é necessário que o tempo entre os commits sejam mais curtos, ou seja, quanto mais tivermos os commits na branch, melhor será a taxa de verificação da Integração Contínua.

Desta forma, os desenvolvedores se engajaram na análise de contribuições no código, antes mesmo que o seu código seja integrado no Trunk.

Dependendo da cadência de lançamento pretendido, poderá haver “cortes” do Trunk em uma base just-in-time, deixando a branch travada antes de uma nova liberação para novos commits.

As equipes devem tornar-se adeptas a branch, relacionado pela técnica de abstração e pelo tempo da mudanças, além de utilizar também sinalizadores de recursos no desenvolvimento do dia-a-dia, permitindo a proteção na ordem de lançamentos.

É extremamente importante que tenha na equipe um responsável por controlar todo o fluxo dentro do projeto durante o seu tempo de vida.

Pontos importantes:

  • Evita perder tempo com criação e merges de branches;
  • Permite manter sempre o código atualizado;
  • Recomendado para automatizar processos de deploy;
  • Difícil de ser implementado;

Contexto na cultura DevOps:

Uma vez que a equipe tenha feito alguns commits adotando o TBD corretamente, o fluxo passará a ser facilitado, como na figura abaixo:

Minha opinião:

 

 

O Trunk Based Development (TBD) pode ser uma boa alternativa para implantação da Integração Contínua e da Entrega Continua em projetos grandes e com diversos colaboradores.

Enfim… espero que este pequeno artigo tenha sido útil. Em breve retornarei com este assunto de forma mais prática.

Até a próxima!

Fonte: https://trunkbaseddevelopment.com/

Trunk Based Development – TBD
Tagged on:

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: