DEV Community

Cover image for Versionamento Profissional: Automatizando Tags, Releases e Changelog (Parte 3)
Erick Gabriel dos Santos Alves
Erick Gabriel dos Santos Alves

Posted on

Versionamento Profissional: Automatizando Tags, Releases e Changelog (Parte 3)

#githubactions #devops #angular #tutorial

Se você acompanhou as partes anteriores desta série, seu projeto Full-Stack (Angular + .NET) já está sendo testado e compilado automaticamente em um Self-Hosted Runner gratuito. A infraestrutura está perfeita.

Mas e a organização do código?

Imagine a seguinte situação: você trabalha com mais três desenvolvedores. Vocês abrem PRs, fazem merge na branch main e o deploy acontece. Chega sexta-feira e o cliente pergunta: "O que exatamente entrou na versão 1.2.0 que acabou de ir pro ar?"

Se você responde revirando um histórico de commits cheio de "fix bug", "ajuste no layout", ou "wip", nós temos um problema.

Nesta Parte 3, vamos transformar seu repositório bagunçado em uma máquina de versionamento profissional. Vamos padronizar os commits, gerar o CHANGELOG.md magicamente e usar o GitHub Actions para criar Releases visuais.

Passo 1: O Fim do "Commit Bagunça"

A automação de versões depende de previsibilidade. O robô não sabe ler mentes, mas ele sabe ler padrões. É aqui que entra o Conventional Commits.

Em vez de escrever o que vier à cabeça, você passa a iniciar seus commits com prefixos específicos:

  • feat: adiciona dark mode no dashboard (Uma nova funcionalidade - vai gerar uma nova minor version ex: 1.1.0 -> 1.2.0)
  • fix: corrige erro no grid do canvas (Uma correção de bug - vai gerar um patch ex: 1.2.0 -> 1.2.1)
  • chore: atualiza dependências do Angular (Tarefas de manutenção que não afetam o usuário final)

Se você tem dificuldade de lembrar as regras, recomendo usar a biblioteca Commitizen. Ela transforma o comando git commit em um questionário interativo no seu terminal, forçando o padrão correto.

Passo 2: Gerando a Versão Magicamente

Agora que seus commits estão organizados no projeto, vamos usar uma ferramenta maravilhosa chamada commit-and-tag-version (um fork moderno do antigo standard-version).

Como nosso frontend é em Angular, podemos instalar isso facilmente na pasta do projeto usando o NPM:

cd frontend
npm i -D commit-and-tag-version
Enter fullscreen mode Exit fullscreen mode

Agora, abra o seu package.json e adicione este script:

"scripts": {
  "release": "commit-and-tag-version"
}
Enter fullscreen mode Exit fullscreen mode

O que esse comando faz? Quando você rodar npm run release, a ferramenta vai:

  1. Ler todo o seu histórico de commits desde a última versão.
  2. Descobrir automaticamente qual é a próxima versão (baseado nos seus feat: e fix:).
  3. Atualizar o número da versão dentro do package.json.
  4. Criar ou atualizar um arquivo CHANGELOG.md com um resumo lindíssimo de tudo que foi feito.
  5. Fazer um commit automático com esses arquivos.
  6. Criar uma Git Tag (ex: v1.2.0).

Passo 3: O Workflow de Release no GitHub

O nosso repositório local já está tagueado e o changelog foi gerado. Agora precisamos que o GitHub Actions perceba isso e crie uma aba de "Release" oficial lá no site do GitHub, para que qualquer pessoa possa baixar os binários ou ver as notas de atualização.

Vamos criar um novo arquivo de workflow. Crie .github/workflows/release.yml:

name: Generate GitHub Release

# Esse robô NÃO roda no push convencional. Ele só acorda quando uma Tag é enviada.
on:
  push:
    tags:
      - 'v*' # Aciona quando a tag começa com "v", ex: v1.0.0

jobs:
  create-release:
    name: Create Official Release
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Essencial: baixa o histórico completo para ler as tags anteriores

      - name: Create GitHub Release
        # Uma action super popular para gerar a interface visual de Release no GitHub
        uses: softprops/action-gh-release@v2
        with:
          generate_release_notes: true # O próprio GitHub ajuda a agrupar as PRs na tela
          # files: se quiser, pode anexar um .zip do backend compilado aqui!
Enter fullscreen mode Exit fullscreen mode

O Fluxo de Trabalho Completo (Dia a Dia)

Parece muita coisa, mas olha como a sua vida e da sua equipe fica simples no dia a dia:

  1. Você trabalha no seu código normalmente.
  2. Faz o commit usando o padrão: git commit -m "feat: integra API C# com o kanjidex"
  3. Quando a equipe decide que é hora de ir para produção, você roda: npm run release
  4. A ferramenta processa tudo, cria a tag e o CHANGELOG.md localmente.
  5. Você envia tudo para o GitHub com um comando especial que empurra as tags junto com o código: git push --follow-tags

Pronto! O seu workflow principal da Parte 1 vai fazer o deploy da aplicação, e o nosso novo workflow da Parte 3 vai criar uma Release oficial no repositório. Documentação em dia sem você precisar escrever uma única linha de relatório.

Resumo e Próximos Passos

Temos integração contínua (CI), entrega contínua (CD), servidores gratuitos e versionamento semântico automatizado. É uma arquitetura de DevOps invejável!

Contudo, conforme o repositório fica gigante, as execuções começam a demorar. Ficar baixando a pasta node_modules e os pacotes NuGet do zero a cada execução não faz o menor sentido e atrasa a esteira.

Na Parte 4 (O Grande Final), vamos turbinar a performance do nosso pipeline implementando Caches inteligentes e explorando as Matrix Builds para testar múltiplos ambientes de uma só vez.

Top comments (0)