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.0ativa 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
develope nem em uma novafeature/*. 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.
- É aberta uma Pull Request / Merge Request:
- Branch Origem:
release/v1.1.0
- Branch Destino:
main
- 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 Dockermeu-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
- 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.
- Ao realizar ajustes de bugs na branch de release:
- Cada novo
pushde correção narelease/v1.1.0re-executa a esteira de Staging automaticamente.
- Ao aprovar a PR na
maine criar a Tagv1.1.0:
- O comando
git push origin v1.1.0aciona a regratags: ['v*.*.*'].
- O job
deploy-stagingé pulado.
- O job
deploy-productionentra em ação, constrói o artefato final imutável etiquetado comov1.1.0e realiza o deploy no ambiente produtivo.