Na gestão de software, versões de lançamento são cruciais para manter a rastreabilidade, garantir a qualidade e facilitar a colaboração entre as equipes. Para desenvolvedores que ainda não estão familiarizados com práticas de DevOps, termos como Git Tag, Release e Semantic Versioning podem parecer complexos. Este artigo tem como objetivo desmistificar esses conceitos e mostrar como eles se relacionam na prática.
Todo exemplo usado neste artigo estará disponível neste projeto público aqui: https://github.com/toolbox-playground/terraform-exemplo-gcp
Git Tag: marcos de código
O conceito de tag no Git é fundamental para marcar pontos específicos no histórico de commits de um repositório, como se fosse uma ‘conquista’. Como boa prática, sempre devemos criar esses marcos a partir da branch mais estável e que represente o código em produção (normalmente usamos a branch main para isso). Uma tag no Git é essencialmente um rótulo fixo que você pode atribuir a um commit específico no seu repositório. Diferente dos branches, que continuam a evoluir conforme novos commits são adicionados, uma tag aponta para um commit específico e permanece imutável. Isso é particularmente útil para marcar releases de software, versões específicas ou conquistas importantes.
Vamos imaginar que você esteja prestes a lançar uma nova versão estável do seu software. Após a conclusão do desenvolvimento e os testes finais, você decide criar uma tag para marcar esse momento no histórico do seu repositório Git. Isso pode ser feito da seguinte forma:
git tag -a v1.4 -m "my version 1.4"
git push --follow-tags origin main
Release: Formalizando e publicando versões de software
Numa fábrica de qualquer produto, toda matéria prima se torna um produto final, numa pipeline de softwares não é diferente. Uma Release é uma entrega formal de uma versão do software que foi preparada para distribuição. Geralmente, essa entrega está associada a uma tag e inclui:
- Versão do software: definida através do Semantic Versioning.
- Release Notes: um resumo das principais mudanças, melhorias, novos recursos e correções de bugs incluídos na versão. Essas notas são cruciais para informar ao público usuários e desenvolvedores sobre o que esperar da nova versão.
- Artefatos: em alguns casos, especialmente para projetos em linguagens compiladas, o release pode incluir binários ou outros arquivos necessários para a execução do software.
Na prática, podemos considerar qualquer biblioteca disponível para download ou software como um exemplo real de um Release na prática. Abaixo, temos o exemplo da própria ferramenta Git.
Cada Release gera um documento oficial, conforme abaixo, em que vemos uma das releases do Git:
Semantic Versioning
Semantic Versioning (SemVer) é uma convenção de versionamento para softwares que segue um padrão específico para nomear versões. Esse padrão é composto por três números separados por pontos: MAJOR.MINOR.PATCH. Cada um desses números tem um significado específico e uma regra de incremento baseada nas mudanças feitas no software.
- MAJOR: incrementado quando há mudanças incompatíveis na API (breaking changes);
- MINOR: incrementado quando funcionalidades são adicionadas de maneira compatível com versões anteriores;
- PATCH: incrementado quando correções de bugs são feitas de maneira compatível com versões anteriores.
Por exemplo, a versão 2.1.3 pode indicar:
- 2: segunda versão maior do software, possivelmente com mudanças significativas e incompatíveis com a versão 1.x.x;
- 1: primeira atualização menor, adicionando funcionalidades novas, mas mantendo compatibilidade com a versão maior;
- 3: terceira correção de bugs desde a última atualização menor.
Há várias formas de decidir o momento em que sua empresa ou time irão atualizar a versão do software e o fator maturidade do time pode contar muito no momento de desenhar essa lógica. Há situações em que o software efetua a troca de versão por “tipo de mensagem” no commit, como o padrão commit–zen apresenta. Há softwares que geram novas versões por tempo de projeto, como o SQL Server, que lançava sempre uma versão a cada dois anos: SQL Server 2012, SQL Server 2014, SQL Server 2016. Não há certo ou errado ao assumir qualquer estratégia e lembre-se sempre de adequar uma estratégia que faça sentido para o momento e a senioridade do seu time.
Acelere a sua carreira conosco!
A Mentoria DevOps é um programa de mentoria de 12 meses com encontros semanais ao vivo, com um grupo seleto e restrito, onde estaremos do seu lado para mantê-lo relevante e atualizado no mercado de tecnologia, aprendendo e implementando as melhores práticas e ferramentas de DevOps.
Clique aqui para entrar na prioridade pela melhor oferta de lançamento
Conclusão
Todos esses conceitos, quando bem aplicados, garantem o que chamamos de rastreabilidade de software, permitindo que desenvolvedores, operadores e usuários finais saibam exatamente o que esperar de cada versão e até mesmo retornem para uma versão anterior se tiverem necessidade.
A partir de agora, com base no conteúdo que vimos neste artigo, você pode adotar essas práticas em seus projetos ou mesmo fomentar seu uso no seu time e empresa.