Git, da necessidade a automação de sua release (parte 1)

Muitas vezes acompanhamos ciclos de desenvolvimento de softwares de grande porte, acompanhando releases sem idéia de como conseguir implantar naquele projeto no qual trabalhamos, como podemos ter um controle de alto nível em um ritmo que está cada vez mais ágil, esse artigo tem como finalidade levar desde o uso do git como controle de versão até a entrega em releases ricas de detalhes como nosso tão sonhado changelog automatizado.

Disclaimer: é necessário um conhecimento básico de git para que acompanhe o raciocínio e tenha entendimento do artigo. Caso queira quebrar o gelo recomendo esses artigos (tanks @woliveiras):

http://rogerdudler.github.io/git-guide/index.pt_BR.html

http://willianjusten.teachable.com/p/git-e-github-para-iniciantes

Porquê git

Partindo desse artigo, podemos definir os pontos fortes do git:

Pros:

• velocidade alta nas operações em relação SVN/CVS;
• operações de branch são mais fáceis de operar;
• acesso completo ao log offline;
• distribuído, utiliza o modelo ponto a ponto ( muito importante quando chegarmos no modelo git-flow ).

Contras:

• possui curva maior de aprendizado em relação aos demais softwares de controle de versão, use essa página como atalho pra aprender e fixar os comandos;
• não foi projetado para ser utilizado por um único desenvolvedor no projeto, ficando mais custoso seu uso no dia a dia;
• pouco suporte em ambiente windows .

Reforçando seu problema na curva de aprendizado:

The primary downside cited for Git is that it can be at times difficult to explain to others, and there is likely to be a slow down in production as programmers adapt to it. Once it is learned, however, the speed increases and better branch management will reclaim that time and more.

Ele é mais complexo na primeira visão, mas possui um modelo bem completo e uma vez que domina os seus comandos, você terá todo um controle sobre seu código, é como dizemos, com git não existe código perdido, você que não descobriu o comando exato pra fazer o que precisa!

Branches, forks e suas necessidades

Uma das maiores forças do git é sua facilidade de manipular branches, onde podemos quebrar, criar vários ramos de atividades e unificar, mantendo o código coerente com nossa linha de raciocínio.

As motivações para criar branches podem ser das mais diversas:

• separar por colaborador cada branch, usando o modelo de branch model
• separar funcionalidades e raciocínios em caso de refatoração
• separar ambientes (como desenvolvimento/homologação/produção)

Para casos de trabalho de equipe podemos ter dois modos de trabalho:

• desenvolvedores trabalhando no mesmo repositório usando branches diferentes e atualizando (iremos chamar de branch model)
• desenvolvedores trabalhando em repositórios diferentes (usando fork do projeto) e entregando através de pull request (iremos chamar de fork model)

modelo "fork model"

modelos de fluxo de desenvolvimento

Na figura acima podemos visualizar os modelos mais utilizados, onde da esquerda da direita, de cima pra baixo podemos citar:

• o modelo mais básico que é o centralizado, onde é uma delícia quando se trabalha sozinho, mas quando começa a trabalhar em equipe parece com nossa figura abaixo:

aquela entrega que você tem que fazer em 10 minutos e seu cliente já tá em cima

• uma evolução é o modelo feature branch, onde cada funcionalidade é desenvolvida isoladamente (cada branch tem um tempo de vida igual ao período de implementação da feature que está sendo desenvolvida nela)

criação de um branch para resolução de feature

Um modelo de ciclo completo de desenvolvimento de software: Git-Flow

Uma vez conhecendo os procedimentos acima, iremos escolher um modelo de fluxo de trabalho para desenvolvermos um software com uma ou mais equipes distintas contribuindo com mesmo software (ou base de código para ficar mais abrangente).

O mais difundido (não necessariamente o melhor porque quem vai definir o melhor é sua equipe de desenvolvimento) é o git-flow. todo seu manifesto é feito nesse artigo.

Fluxo do git-flow

O workflow utiliza duas branches fixas: develop e master.

Dica: estamos utilizando develop como branch principal para evitar problemas menores de push's indevidos

Os papéis dos branches são os seguintes:

• develop: versão que contém todas as novas features desenvolvidas (onde todo o ciclo de teste e validação foram feitos), não deve conter desenvolvimentos não aprovados e desenvolvimentos incompletos, ou seja, tudo que está preparado e aprovado para ir pra próxima release em produção. caso tenha algum hotfix, o conteúdo do hotfix também fica disponível em develop
• master: última versão estável, contém todos os recursos entregues em produção, caso tenha algum hotfix, o conteúdo do hotfix também fica disponível em master
• feature/xxxx: uma branch temporária que contém a implementação candidata na próxima release, onde seu ciclo de vida fica limitado à sua aprovação e validação, na sua finalização deve ir para o branch develop

• bugfix/xxxx: uma branch temporária que contém uma correção que não é emergencial e pode ser levada para a próxima release. seu ciclo de vida é semelhante ao feature, somente muda o nome por respeito à nomenclatura da classificação da implementação
• hotfix/xxxx: uma branch temporária que contém uma correção que é emergencial, devido à sua operação, deve ser definido por toda a equipe se a correção é uma hotfix. Seu ciclo de vida termina na validação da correção do erro e seu conteúdo deve ir para master e develop.

Todas as operações de junções de branches, devem ser feitas por merge --no-ffpara garantir histórico das operações no branch que foi apagado.

As principais operações possíveis estão disponíveis nesse cheatsheet.

Nem tudo são flores no git-flow

Como todo processo ele tem seus pontos altos e baixos, deve ser tomado a decisão de adotá-lo de acordo com a necessidade da equipe e projeção de onde a equipe pretende chegar com seu código fonte.

Prós:

• facilidade de integração com várias IDE's
• adoção com várias equipes o que permite trocar idéias e dúvidas com várias equipes
• facilidade de implantação uma vez que o processo é amplamente documentado e possui commandos disponíveis na internet que facilitam seu uso

Contra:

• processo que gera muitas operações no git, o que acaba "sujando" seu log;
• o merge poderia ser substituído por rebase;
• o processo não necessitava de dois branches, citados nos artigos abaixo, ele não necessitava de ter dois branches fixos, somente um daria conta do recado.

Artigos que são contrários ao uso do git-flow:

A succesful Git branching model considered harmful

GitFlow considered harmful

São opiniões de desenvolvedores e experiências negativas com seu uso, mas pode não refletir em sua experiência em si.

Git-Flow + Fork, considerações da escolha no trabalho em equipe

Não basta conhecer e trabalhar de imediato com git-flow, sua premissa é de trabalho é bem ampla baseado no descentralizado mas centralizado, como podemos ver no artigo manifesto citado no início do assunto:

Nesse modelo permite que façamos forks do projeto principal e reincorporamos no projeto através de pull-requests.

vários forks apontando para o mesmo projeto base

O modelo que considero mais saudável é o seguinte:

• Equipes internas e mantenedor do projeto: deve clonar o projeto e manter o fonte através de aceitação dos pull requests.
• Equipes externas e colaboradores fora do time principal: fork do projeto e enviar através de pull requests

Conclusões da parte 1 do artigo

Podemos considerar o git-flow como bastante evoluído, com processo bem definido, mas devemos considerar seus pontos fracos na decisão de seu uso ou não. ele tem facilitados muitas equipes a desenvolver. Particularmente apesar das perdas e aumento de logs, acredito no processo do git-flow e em seu poder de normalizar equipes para manter um fluxo uniforme de desenvolvimento, e pela riqueza que é o git, um pouco de organização no fluxo facilita bastante.

Essas conclusões finalizam a primeira parte, onde iremos para segunda parte tratar a partir do momento que estamos familiarizados com o fluxo do git-flow.

Agradecimentos

Agradeço a Daniel Ferraz e Rafael Ferreira Dos Santos pelas contribuições que permitiram a execução desse artigo. William Oliveira que me ajudou bem nas revisões.