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

Na primeira parte discutimos o porquê da necessidade do git e o benefício em relação aos demais, e finalizamos discutindo modelos de branch defendendo nossa escolha pelo git flow.

Na segunda parte iremos partir de que estamos alinhados do processo do git-flow. Uma vez que foi definido todo o ciclo de desenvolvimento no git, devemos nos preocupar com uma coisa bem importante, os logs dos commits:

Vamos evitar logs dessa natureza que tal?

Benefícios de log limpo e claro:

• Interligarmos com trabalhos mapeados em sistemas de chamados e de gestão ágil e conseguimos mensurar esforço;
• Conseguimos voltar versão com mais clareza e entendemos o que foi afetado nos commits.

Regras de ouro para organizar os textos de commits

Considerações do artigo anterior que irão afetar em um log de commit melhor:

• Uma feature por vez: não tente criar uma feature chamada "varias-correções" e corrija tudo de uma vez. Na hora vai ser uma delícia, ainda mais com aquele gerente não-tenho-a-mínima-idéia-do-que-está-fazendo- mas-tem-que-entregar no seu pé, mas vença a tentação, pois quando o log tiver confuso é ele que vai pegar no teu pé 😂;
• Mais commits e textos mais curtos: sabe aquele commit que você só manda no final do dia? ou quando teu chefe te manda? esqueça! Faça commits com textos mais curtos e mais frequentes, pensando lógica é igual save de jogo sinistro , onde cada save vale ouro. Além disso evita que tenha que escrever alterações que ocorram em mais de um arquivo;
• Um commit por arquivo sempre que possível: sempre que possível tente evitar commits que altere mais de um arquivo, exceto casos em que o contexto for bem curto para cada um dos arquivos, como refatoração de rotas, etc;
• Referencie o chamado no texto do commit: iremos ver mais a fundo mais abaixo, mas sempre que estamos trabalhando, estamos abaixo de algum sistema de gestão, sendo ele o próprio recurso de issues do GitHub. Você pode referenciar apenas pelo número ( exemplo : issue #12 ).

Textos de commits mais ricos usando smart commit

Em referência ao último item da lista acima, podemos criar um padrão de texto que contém muito mais informações e ações em relação ao que está realmente escrito, são os smart commits.

Using Smart Commits - Atlassian Documentation

No link acima temos o modelo de commit para sistemas de gestão do JIRA:

<ignored text> <ISSUE_KEY> <ignored text> #<COMMAND> <optional COMMAND_ARGUMENTS>

Onde podemos comentar da seguinte forma:

JRA-34 #comment corrected indent issue

Esse texto faz referencia ao chamado 34 do JIRA, onde vai ser possível do sistema de gestão ter um link ao código que foi alterado no chamado.

Vamos além um pouco:

JRA-123 JRA-234 JRA-345 #resolve

Esse texto faz com que os chamados 123, 234 e 345 fechem, assim que o código for para o código base.

No GitHub é possível controlar as issues através desse help

This closes #34, closes #23

Onde nesse comentário fechamos as issues 23 e 34, no Github fica bem claro a referência

Referência do commit no GitHub

Dica: as referências dos commits no GitHub, serão somente aplicadas quando o commit for para o branch que você considerou como padrão no GitHub, por exemplo, se nosso branch principal for develop, toda vez que o commit for para o develop finalizando uma feature, o GitHub irá integrar com seu comentário.

Aplicando validador de padrão de mensagem no seu código, a primeira parte de estado da arte

Nessa parte iremos focar mais no universo Javascript, mas isso não é impeditivo de achar solução para seu ecossistema. As ferramentas que utilizamos pode ser adaptadas para várias arquiteturas, vamos para os itens e como implantar em seu projeto:

Iremos usar esse artigo como base para explicar o comportamento de algumas partes do que será implantado.

Commitizen

O commitizen irá te ajudar a padronizar seus textos, tornar mais humano não somente para equipe de desenvolvimento que está diretamente ligado ao código, mas a sua equipe de gestão que irá ver com clareza todo o esforço que foi feito para demandar cada recurso.

O seu cli pode ser instalado pelo comando:

$npm i -g commitizen

Uma vez instalado você pode optar por usar o cli dele para preencher o commit, mas antes devemos entender o que significa os tipos de mudanças que ele enumera na primeira pergunta do diálogo:

• feat: Feature nova;
• fix: Correção de código;
• docs: Melhoria de comentário de código ou edição da parte de documentação da sua base de código;
• style: melhorias de formatação de texto, mudança de estilo de codificação;
• refactor: Uma vez trabalhando com boa cobertura de teste ou não ( o risco é seu 😂 ), esse commit é quando for apenas refatorar seu código;
• perf: Quase mesma pegada do refactor mas esse ajuste resulta em maior perfomance da solução;
• test: Inclusão ou manutenção de testes do software;
• chore: Se o que alterou não está associado a algum listado acima, utilize ele para classificar.

Alguns que ficaram de fora que são interessantes: (ci : para alterações no script de integração contínua).

Ainda podemos melhorar mais ainda essa estrutura usando outros modelos como o do jira:

commitizen/cz-jira-smart-commit

Controle de tempo gasto no chamado, status e tudo mais na hora do commit, só falta fazer o nosso café (expresso por favor)

Tomei liberdade de dar um fork o modelo do jira e criar um meu integrando com o taiga, que curto bastante usar:

claytonsilva/cz-taiga-smart-commit

Usando um recurso de smart commit do próprio taiga, posso usar o commit do GitHub para finalizar chamados do taiga, mas pra isso é necessário integrar o taiga com o GitHub como é ensinado nesse link aqui.

Para instalar e começar a usar é bem simples assim

O modelo standard que definimos por padrão, foi desenvolvido pelo time do angular, por isso alguns termos do diálogo como "escopo da alteração" podem parecer estranho nos exemplos que eles passam, mas no meu caso uso no backend para separar escopos em ( controller, router, model ), em casos mais simples cito o próprio arquivo no escopo da alteração.

Como queremos mais liberdade de gerar as mensagens de commit, podemos chegar a um ponto que queremos escrever a mensagem diretamente sem usar diálogo, pra isso teremos ajuda dos pacotes husky e validate-commit-message.

Wolf!

Na linha de comando na raiz de seu projeto utilize o comando:

instalando os pacotes de checagem do commit

Por fim vá no package.json e efetue as seguintes alterações:

Na primeira parte estamos colocando no bloco de scripts, o comando que irá executar ao rodar commit, ele será consumido pela ferramenta husky ao interceptar o envio do commit.

Na segunda parte, ela fica mais complexa, onde declaramos os tipos de alterações ( mesmo que utilizando um padrão de commitizen, eles trabalham em diferentes momentos, onde um setup não pode aproveitar do outro, portanto devemos repetir a lista de tipos que utilizamos no nosso commitizen ).

Definimos assim o modelo (nas configurações abaixo de type em ordem):

• Qualquer erro de sintaxe é erro;
• O título pode ter no máximo 100 caracteres;
• O título é livre para qualquer texto;
• O erro de preenchimento do título terá a mensagem "subject does not match subject pattern!";
• Não terá mensagem de help.

A linha que contém a propriedade "commitizen" foi criada quando demos init no mesmo.

Pronto, você pode escrever na mão contanto que respeite a estrutura:

<type>(<scope>): <subject>

Agora temos:

• Um padrão para redação de submissões de código via commit
• Um validador que garante respeito ao padrão utilizado
• Um diálogo personalizado para o seu modelo de trabalho que respeita o padrão de textos de commit, permitindo inclusive controlar sua gestão de atividades.

Estamos perto de dar o finish him…

Finish Him!

Enfim vamos dar uma finalidade pra esses commits bonitos que escrevi?

Com os logs do git em conformidade, teremos um log bem simples e fácil de acompanhar na linha de comando usando o comando "git log":

“git log — graph — oneline develop” mostrando os logs no branch develop

O conventional-changelog-cli irá sempre incrementar texto de log das atividades no caso citado pelo exemplo iremos:

• -p angular: utiliza o padrão de changelog criado pelo time do angular ( o mais utilizado )
• -i CHANGELOG.md: irá criar o arquivo CHANGELOG.md
• -s ( — same-file): sobrescreve em cima do arquivo citado no -i se já existe

O resultado será esse:

Criei um repositório brinquedo pra fazer esses testes, sinta-se a vontade pra fazer fork e dar um like 😀

Muito trabalhoso esse processo, como entra a automação e facilidade desse modo de trabalho no meu dia a dia?

Esse será assunto da parte final, no qual iremos colocar um script de release e pre-release automatizado de forma que vai gerar esse resultado abaixo:

lindão né!

E será com um arquivo que você irá colocar na raiz do seu projeto.