No mundo do desenvolvimento de software as pessoas precisam utilizar um Version Control System (VCS), também conhecidos como ferramentas de Source Code Management (SCM) ou Revision Control System (RCS). Controlar suas versões é a prática de rastrear e gerenciar alterações no código do software, os sistemas de controle de versão são ferramentas de software que ajudam as equipes de software a gerenciar alterações no código-fonte ao longo do tempo. Quem não usa nenhuma ferramenta de gestão de código está fazendo errado #ficadica 😉

Existem muitas ferramentas de gestão de código tais como: SVN, CVS, Mercurial eu tive pouco contato com essas ferramentas, nos últimos anos tenho tido mais contato com o Git. Eu e o mundo gostamos do Git, dentre todas as guerras santas que existem no mundo das tecnologias eu nunca vi ninguém falar, “o Git é ruim”, “eu não consigo fazer isso ou aquilo no git”. O Git é uma das poucas unanimidades que eu conheço neste universo de tecnologia. Só vejo gente detestando o Git quando caem em um “merge hell”, aí sim você vai ter muitos motivos para odiar o Git, mas no final (isso se você chegar lá), vai descobrir que o erro foi seu. 😉

No mundo do desenvolvimento de software, especialmente no universo DevOps, um dos grandes aliados na hora de organizar e gerenciar nosso código é marcar o código com uma TAG. Essa técnica é uma das várias funcionalidades que o Git oferece, uma das mais úteis para quem trabalha com DevOps. Mas, o que exatamente TAG, tagueamento, o que é isso? E quais são as melhores estratégias para usar tags no seu fluxo de trabalho? E sobre isso que vamos falar….

TAGs

Tagueamento no Git é equivalente a colocar um marcador, um “post-it”, em um ponto específico no histórico do seu repositório. Esse marcador pode ter várias finalidades, mas geralmente é usado para marcar versões importantes do seu software. Por exemplo, a cada versão estável do seu código. Você pode criar uma tag chamada v1.0.0 nesse ponto específico do código. Assim, no futuro, se precisar revisar essa versão, é só ir direto na tag.

Estratégias de TAGs

Se taguear é equivalente a colocar um “post-it”, eu te pergunto, mas qual tipo de “post-it” que se deve utilizar???!! Existem vários formatos!! 🤔 Saber qual “post-it” utilizar chama-se estratégia de Tagueamento e isso é muito importante para todo o seu ciclo de desenvolvimento, deploy e rollback das suas aplicações.

Versionamento Semântico

Versionamento Semântico é uma das técnicas mais populares, ele segue o formato MAJOR.MINOR.PATCH, onde:

• MAJOR: Mudanças incompatíveis com versões anteriores (breaking changes).
• MINOR: Novas funcionalidades que são compatíveis com versões anteriores.
• PATCH: Correções de bugs compatíveis com versões anteriores.

Neste formato as tags tem o seguinte formato v1.0.0, v1.1.0, v1.1.2. Esse formatos traz clareza e previsibilidade, fica fácil para as pessoas entenderem o impacto de uma nova versão. Facilita a comunicação entre times, especialmente em projetos maiores. Entretanto, pode ser um pouco mais trabalhoso manter a consistência, especialmente em times menos disciplinados. Exige um certo nível de maturidade no gerenciamento das tags se não forem gerenciadas de forma automática.

Recomendo utilizar a lib Python chamada Semver para fazer todo o trabalho de mudanças e incrementos das versões.

Versionamento baseado em datas

Essa técnica usa a data como identificador de versão seguindo o modelo AAAA.MM.DD. É especialmente útil para lançamentos frequentes e contínuos, as tags ficam assim: 2024.06.01, 2024.06.02. É um formato bem simples, não precisa pensar muito sobre como versionar, é só usar a data, facilita a rastreabilidade temporal das versões. Eu não curto muito esse modelo pois o próprio formato impõem uma limitação de uma versão por dia 🙁. Eu ficaria mais satisfeito com o formato que AAAA.MM.DD.HH.MM.SS isso resolve a limitação diária mas mesmo assim não é um formato que me agrada muito.

Tags Baseadas em Hash

A cada commit no Git gera um identificador único tipo: b8aa0fe, 37bbc49, 20c3602. Para mim de longe esse é o formato mais prático de se usar pois garante a reprodutibilidade da release, identifica o estado exato do código e é útil para releases que precisam ser reproduzidas em ambientes específicos. Entretanto, é o mais difícil para interações com nós humanos, é bem difícil se orientar por um hash de sete dígitos, falo isso por mim, eu não consigo gravar a placa do meu carro imagine gravar um hash que muda a cada commit, i-m-p-o-s-s-í-v-e-l, mas sem dúvida é um modelo que funciona bem com sistemas de CI/ CD que se orientam pelo histórico e APIs do Git.

1  git log --pretty=format:"%h - %an, %ar : %s"

Tags Baseadas em Customização

Esse é um modelo que dá uma certa flexibilidade para atender às necessidades específicas do projeto. Permite incluir informações adicionais relevantes nas tags tipo: “1.0.0”, “1.1.0-rc.1”, “2.1.0-beta-rc”, “1.4.0-beta”, “3.10.0-prebuild” para as equipes envolvidas. Embora seja flexível, requer uma boa dose de documentação e comunicação clara entre as equipes para garantir a compreensão por todos os envolvidos. Pode ser complexa para implementar e manter se não for automatizada.

Usando as TAGs no Git

Listando suas tags

1  git tag

Versionamento Semântico

1  export TAG="v.1.3.4"
2  git tag $TAG
3  git push origin $TAG

Tags Baseadas em Customização

1  export TAG="1.1.0-rc.1"
2  git tag $TAG
3  git push origin $TAG
4
5  export TAG="1.1.0-prebuild"
6  git tag $TAG
7  git push origin $TAG

Versionamento baseado em datas

1  export TAG=$(date +%Y%m%d%H%M%S)
2  git tag $TAG
3  git push origin $TAG

Resumo

Tagueamento no Git é uma técnica poderosa que pode facilitar muito a gestão de versões no desenvolvimento de software. Cada estratégia de tagueamento tem suas próprias vantagens e desvantagens, e a escolha da melhor abordagem depende das necessidades específicas do seu projeto e da maturidade de uma equipe confor diz o livro Entrega Contínua.

Com uma boa estratégia de tagueamento e integração com os pipelines de CI/CD, você terá um fluxo de trabalho mais organizado e eficiente, o que resultará em deploys e rollbacks mais rápidos.

Uma última coisa, independente da técnica escolhida é crucial a integração com os pipelines de CI/CD, não deixe a estratégia “flutuando” em um acordo verbal de entre os membros do time, o modelo escolhido deve ser codificado nos pipelines e as tags devem ser aplicadas com base nas regras especificadas permitindo implantação de versões tagueadas nos ambientes de testes e de produção.

Abraços!

Vida longa e próspera a todos!!

Referências

• Entrega Contínua: Como Entregar Software de Forma Rápida e Confiável
• https://semver.org/
• https://git-scm.com/
• https://pypi.org/project/semver/
• https://www.atlassian.com/git/tutorials/what-is-version-control
• https://cvs.nongnu.org/
• https://subversion.apache.org/
• https://www.mercurial-scm.org/

MENTORIA

Curtiu o blog? Quer trocar uma ideia comigo sobre algum post?

Marca Aqui! É um papo gratuito oferecido para quem é leitor do blog, podemos falar de temas como: DevOps, SRE e carreira em TI.

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.