A montagem de uma Release até o Deploy em Produção utilizando GitFlow em um ambiente com metodologias ágeis e pipelines de CI/CD funciona como uma linha de montagem industrial.

Seguindo a estrutura do artigo / link:

GitFlow na Prática: Guia Definitivo para o Controle de Versão em Ambientes Profissionais

Onde develop é a integração, release/* dispara Staging, e main dispara Produção via Tags, veja o passo a passo prático de como essa montagem é feita na vida real.

1. Mapeamento de Branches e Ambientes Link para o cabeçalho

Branch Função no GitFlow Trigger do CI/CD (Ambiente)
feature/* Desenvolvimento individual da história Testes unitários/locais
develop Integração do trabalho da equipe Deploy em Dev / Sandbox
release/vX.Y.Z Congelamento e homologação da versão Deploy automático em Staging / QA
main Código estável idêntico ao de Produção Deploy automático em Produção (via Tag)

2. Passo a Passo Técnico da Montagem até o Deploy Link para o cabeçalho

Passo 1: O “Corte” da Release (Code Freeze) Link para o cabeçalho

No final da Sprint (ou ciclo ágil), as histórias de usuário aprovadas foram mescladas na develop através de PRs. Para dar início ao processo de publicação, o Tech Lead ou a equipe faz o congelamento para Homologação criando a branch de release:

# Garanta que a develop está atualizada
git checkout develop
git pull origin develop

# Cria a branch de release com o padrão de versionamento semântico (SemVer)
git checkout -b release/v1.1.0

# Publica a branch no repositório remoto
git push origin release/v1.1.0
  • O que acontece nos bastidores (CI/CD): A criação da branch release/v1.1.0 ativa o pipeline do CI/CD, que compila o código, executa os testes de integração e faz o deploy automático no ambiente de Staging (Homologação).

Passo 2: Testes em Staging e Ajustes de Bugs Link para o cabeçalho

O time de QA, Product Owners (PO) ou partes interessadas (stakeholders) realizam os testes finais de aceitação no ambiente de Staging.

  • Se um bug for encontrado: Ele NÃO é corrigido na develop e nem em uma nova feature/*. A correção é feita diretamente na branch de release por meio de uma PR dedicada de bugfix:
# Desenvolvedor corrige o bug na release
git checkout release/v1.1.0
git checkout -b bugfix/corrigir-layout-checkout

# (faz os commits do ajuste...)
git push origin bugfix/corrigir-layout-checkout
# Abre a PR direcionada para: release/v1.1.0

Uma vez aprovada e integrada na release/v1.1.0, o CI/CD atualiza o ambiente de Staging automaticamente.

Passo 3: Criação da PR para a main e Aprovação Link para o cabeçalho

Quando Staging é validado e o PO dá o “OK” para ir ao ar, a release está pronta para virar produção.

  1. É aberta uma Pull Request / Merge Request:
  • Branch Origem: release/v1.1.0
  • Branch Destino: main
  1. Revisão: Membros sêniores/Tech Lead fazem a revisão e aprovam o merge.

Passo 4: Merge na main e Tag de Versão Link para o cabeçalho

Após a aprovação da PR, a branch de release é mesclada na main. Em seguida, cria-se a Tag de Versão para registrar aquele estado do sistema no histórico:

git checkout main
git pull origin main

# Cria uma tag anotada para marcar o release oficial
git tag -a v1.1.0 -m "Release da versão 1.1.0 com novas funcionalidades de checkout"

# Envia a tag para o repositório remoto
git push origin v1.1.0

Passo 5: O Deploy em Produção (Automático pelo CI/CD) Link para o cabeçalho

Em arquiteturas profissionais modernas, a criação da Tag v1.1.0 aciona o Job de Produção no pipeline CI/CD.

① Build do Artefato / Imagem Docker
Empacotamento e Imutabilidade

O pipeline de CI lê a Tag v1.1.0, compila a aplicação e gera um pacote imutável (como uma imagem Docker meu-app:v1.1.0).

┆
┆

② Validação de Segurança e Análise Estática
DevSecOps

Executam-se scanners de vulnerabilidade na imagem Docker e testes de fumaça (smoke tests).

┆
┆

③ Deploy sem Interrupção (Zero-Downtime)
Estratégia de Deploy

O pipeline atualiza a infraestrutura de produção usando técnicas como Blue/Green Deployment ou Canary Deployment, redirecionando o tráfego dos usuários para a nova versão sem derrubar o sistema.

Passo 6: Sincronização Obrigatória (Backport para develop) Link para o cabeçalho

Este é o passo essencial do GitFlow para evitar a perda das correções feitas durante a fase de release:

# 1. Faz o merge da release de volta para a develop
git checkout develop
git pull origin develop
git merge release/v1.1.0

# 2. Envia para o servidor
git push origin develop

# 3. Remove a branch de release que já cumpriu seu papel
git branch -d release/v1.1.0
git push origin --delete release/v1.1.0

3. Resumo Visual do Fluxo Completo Link para o cabeçalho

(develop)  ----*---*---*------------*-------> (Continua desenvolvimento das próximas features)
                       \              /
   (release)            \---*---*----/          (Testes e correções em Staging)
                             \      /
   (main)     ----------------*----*-----------> (Produção)
                                  \
                                Tag v1.1.0 ---> [ Pipeline CI/CD ] ---> Deploy Produção

Exemplo de Pipeline CI/CD (deploy.yml) Link para o cabeçalho

name: Pipeline CI/CD - GitFlow

# Defines quando as ações do pipeline serão executadas
on:
  push:
    branches:
      - 'release/*'       # Dispara para branches de release (Staging)
    tags:
      - 'v*.*.*'          # Dispara quando uma tag de versão for publicada (Produção)

jobs:

  # -------------------------------------------------------------
  # JOB 1: DEPLOY EM STAGING (HOMOLOGAÇÃO)
  # -------------------------------------------------------------
  deploy-staging:
    name: Deploy em Staging
    # Roda apenas se o push for para uma branch do tipo release/*
    if: startsWith(github.ref, 'refs/heads/release/')
    runs-on: ubuntu-latest

    steps:
      - name: Baixar o código-fonte
        uses: actions/checkout@v4

      - name: Configurar Node.js (ou sua stack)
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Instalar Dependências e Executar Testes
        run: |
          npm ci
          npm test          

      - name: Build do Artefato para Staging
        run: npm run build -- --mode=staging

      - name: Executar Deploy no Ambiente de Staging
        env:
          STAGING_API_KEY: ${{ secrets.STAGING_API_KEY }}
        run: |
          echo "🚀 Realizando deploy no ambiente de STAGING..."
          # Exemplo: aws s3 sync, docker push, helm upgrade, etc.          

  # -------------------------------------------------------------
  # JOB 2: DEPLOY EM PRODUÇÃO
  # -------------------------------------------------------------
  deploy-production:
    name: Deploy em Produção
    # Roda apenas se for o push de uma TAG (ex: refs/tags/v1.1.0)
    if: startsWith(github.ref, 'refs/tags/v')
    runs-on: ubuntu-latest

    steps:
      - name: Baixar o código-fonte
        uses: actions/checkout@v4

      - name: Extrair o nome da Tag / Versão
        id: vars
        run: echo "TAG_NAME=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT

      - name: Configurar Docker Buildx (Exemplo com Containers)
        uses: docker/setup-buildx-action@v3

      - name: Login no Registry de Containers
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build e Push da Imagem Docker da Versão
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:${{ steps.vars.outputs.TAG_NAME }}
            ghcr.io/${{ github.repository }}:latest            

      - name: Executar Deploy em Produção (Zero-Downtime)
        env:
          PROD_API_KEY: ${{ secrets.PROD_API_KEY }}
        run: |
          echo "💥 ATENÇÃO: Executando deploy da versão ${{ steps.vars.outputs.TAG_NAME }} em PRODUÇÃO!"
          # Comando para atualizar seu Kubernetes, ECS, EC2, Vercel, etc.          

Como esse pipeline funciona na prática? Link para o cabeçalho

  1. Ao criar a branch release/v1.1.0:
  • O GitHub Actions identifica a regra branches: ['release/*'].
  • Ele ignora o job de produção e executa apenas o deploy-staging.
  • O sistema fica atualizado em Staging para o time de testes validar.
  1. Ao realizar ajustes de bugs na branch de release:
  • Cada novo push de correção na release/v1.1.0 re-executa a esteira de Staging automaticamente.
  1. Ao aprovar a PR na main e criar a Tag v1.1.0:
  • O comando git push origin v1.1.0 aciona a regra tags: ['v*.*.*'].
  • O job deploy-staging é pulado.
  • O job deploy-production entra em ação, constrói o artefato final imutável etiquetado como v1.1.0 e realiza o deploy no ambiente produtivo.