🌿 CAPÍTULO 19: GERÊNCIA DE CONFIGURAÇÃO (SCM) E GIT
🎯 1. Objetivos de Aprendizagem & Competências
Estimativa de Dedicação: 2 horas de estudo autoguiado.
Ao final deste capítulo, você será capaz de:
- 🔹 Dominar os fundamentos de Software Configuration Management (SCM), Linhas de Base (Baselines), Itens de Configuração (CIs) e Auditoria de Configuração (IEEE 828).
- 🔹 Aplicar estratégias avançadas de ramificação com Git (GitFlow:
main,develop,feature/*,release/*,hotfix/*). - 🔹 Padronizar o histórico de commits utilizando o padrão da indústria Conventional Commits (
feat:,fix:,refactor:,test:). - 🔹 Estruturar releases segundo o Versionamento Semântico (SemVer:
MAJOR.MINOR.PATCH).
🏢 2. Cenário Corporativo & Estudo de Caso (TecProExpress)
Na TecProExpress, mais de 40 desenvolvedores atuam simultaneamente no repositório do sistema de fretes. Sem regras de governança, alterações incompletas eram enviadas diretamente para a branch main, quebrando o ambiente de homologação e sobrescrevendo códigos de outros colegas de time.
O Desafio: Como Engenheiro de Release e SCM, você deve instituir a política de governança de código: proteção de branch
main, fluxo GitFlow estrito, Conventional Commits e pipelines de validação com pre-commit hooks que bloqueiam código sem formatação ou com testes quebrados.
🧠 3. Fundamentação Teórica & Modelos Visuais
3.1. O Fluxo de Trabalho GitFlow
Estratégia consolidada de isolamento de branches para times multidisciplinares:
gitGraph
commit id: "v1.0.0" tag: "v1.0.0"
branch develop
checkout develop
commit id: "Setup Inicial"
branch feature/checkout
checkout feature/checkout
commit id: "feat: add pix"
commit id: "test: pix handler"
checkout develop
merge feature/checkout id: "Merge feature"
branch release/1.1.0
checkout release/1.1.0
commit id: "docs: changelog"
checkout main
merge release/1.1.0 id: "Merge release" tag: "v1.1.0"
checkout develop
merge release/1.1.0 id: "Sync develop"
3.2. Versionamento Semântico 2.0.0 (SemVer)
O formato MAJOR.MINOR.PATCH comunica a compatibilidade das atualizações:
flowchart TD
subgraph SEMVER ["VERSIONAMENTO SEMÂNTICO (SemVer)"]
M["🔴 MAJOR (ex: 2.0.0)<br>Alterações incompatíveis com versões anteriores (Breaking Changes)"]
MI["🟡 MINOR (ex: 1.2.0)<br>Adição de novas funcionalidades mantendo total compatibilidade regressiva"]
P["🟢 PATCH (ex: 1.1.3)<br>Correções de bugs e patches de segurança sem alteração de API"]
end
style M fill:#fee2e2,stroke:#ef4444
style MI fill:#fef3c7,stroke:#d97706
style P fill:#dcfce7,stroke:#16a34a
💻 4. Aplicação Prática & Código Executável (Python 3.11+)
📋 Pré-requisitos e Instalação
Este exemplo utiliza os módulos padrão re e sys do Python, sem necessidade de pacotes externos:
python --version # Requer Python 3.11 ou superior
💻 Código Completo e Autocontido (validar_conventional_commits.py)
Script em Python para validação automatizada de mensagens de commit (Pre-commit Hook) seguindo a especificação Conventional Commits:
"""
Módulo: validar_conventional_commits.py
Domínio: Auditoria de mensagens de commit segundo a convenção da indústria.
"""
import re
import sys
# Padrão: tipo(escopo opcional): descrição
PADRAO_COMMIT = r"^(feat|fix|docs|style|refactor|test|chore|ci)(\([a-z0-9_-]+\))?:\s[a-z0-9].{5,72}$"
def validar_mensagem_commit(mensagem: str) -> bool:
mensagem = mensagem.strip()
if not re.match(PADRAO_COMMIT, mensagem):
print(f"❌ FORMATO DE COMMIT INVÁLIDO: '{mensagem}'")
print(" Exemplos corretos:")
print(" - feat(fretes): adicionar calculo de cubagem por volume")
print(" - fix(auth): corrigir expiracao do token jwt")
print(" - test(pedidos): adicionar testes de integracao com pytest")
return False
print(f"✅ Commit válido: '{mensagem}'")
return True
if __name__ == "__main__":
print("--- Auditoria de Mensagens de Commit (Conventional Commits) ---")
# 1. Caso válido
msg_correta = "feat(rastreio): integrar websocket de notificacao em tempo real"
ok1 = validar_mensagem_commit(msg_correta)
assert ok1 is True
# 2. Caso inválido (sem tipo e formato fora do padrão)
msg_errada = "arrumando bug no login"
ok2 = validar_mensagem_commit(msg_errada)
assert ok2 is False
🚀 Como Executar
Execute o script diretamente no terminal:
python validar_conventional_commits.py
🖥️ Saída Esperada no Terminal
--- Auditoria de Mensagens de Commit (Conventional Commits) ---
✅ Commit válido: 'feat(rastreio): integrar websocket de notificacao em tempo real'
❌ FORMATO DE COMMIT INVÁLIDO: 'arrumando bug no login'
Exemplos corretos:
- feat(fretes): adicionar calculo de cubagem por volume
- fix(auth): corrigir expiracao do token jwt
- test(pedidos): adicionar testes de integracao com pytest
💡 5. Checkpoint de Engenharia & Boas Práticas
- Commits Atômicos: Cada commit deve representar uma unidade lógica de trabalho isolada e completa (ex: uma correção de bug ou uma nova rota). Evite commits gigantescos com centenas de arquivos misturando refatoração e novas features.
- Anti-Pattern Direct-to-Main: Nunca permita commits diretos na branch
main. Todo código deve obrigatoriamente passar por um Pull Request / Merge Request revisado por ao menos um colega (Peer Review).
🔗 6. Conexão com os Projetos Integradores
| Projeto Integrador | Como o conceito deste capítulo é aplicado no PI |
|---|---|
| PI-01 a PI-10 (Todos os 10 PIs) | Aplicação de pre-commit hooks e Conventional Commits (feat(pi):, test:, docs:) em cada entrega dos 10 PIs no Git. |
🧪 7. Quiz de Fixação e Autoavaliação (Formative Assessment)
🧪 Quiz de Autoavaliação — Capítulo 19
🧪 Quiz de Autoavaliação — Capítulo 19
1. No Versionamento Semântico (SemVer: MAJOR.MINOR.PATCH), quando se deve incrementar o número 'MAJOR' (ex: de 1.4.2 para 2.0.0)?
- A) Quando corrigimos um bug de digitação na documentação.
- B) Quando introduzimos mudanças incompatíveis com versões anteriores da API (Breaking Changes), exigindo que os clientes atualizem seu código.
- C) A cada virada de ano civil.
- D) Quando o time troca de linguagem de programação.
💡 Ver Resposta e Justificativa
Resposta Correta: B
Justificativa: O número MAJOR é reservado para quebras de compatibilidade reversa (Breaking Changes), alertando os consumidores da biblioteca/API sobre a necessidade de adaptação.
2. No fluxo GitFlow, qual branch é criada para realizar correções emergenciais críticas diretamente sobre a versão em produção?
-
A)
feature/correcao -
B)
develop -
C)
hotfix/* -
D)
experimental
💡 Ver Resposta e Justificativa
Resposta Correta: C
Justificativa: Branches hotfix/* derivam diretamente da main para sanar um incidente crítico de produção e, ao término, são mescladas de volta na main (com nova tag) e na develop.
3. O que é uma 'Linha de Base' (Baseline) na Gerência de Configuração de Software (SCM)?
- A) Uma linha divisória no código Python.
- B) Uma versão formalmente revisada e aprovada de um conjunto de artefatos de software (como uma Tag no Git) que serve como base imutável para futuros desenvolvimentos.
- C) O salário mínimo dos desenvolvedores.
- D) Um cabo de rede conectado ao servidor principal.
💡 Ver Resposta e Justificativa
Resposta Correta: B
Justificativa: Baselines representam marcos estáveis e rastreáveis no histórico do projeto, permitindo auditorias e rollbacks confiáveis caso ocorra alguma falha em produção.
🛠️ 8. Ponte para a Ação: Laboratório Prático
Coloque esta teoria em prática executando o roteiro de laboratório autoguiado:
👉 ATIVIDADE 15: GITFLOW E TRABALHO COLABORATIVO
📌 9. Resumo Executivo & Key Takeaways
- SCM é Governança: Controla a evolução ordenada e rastreável de todos os artefatos de código, modelos e configurações.
- GitFlow: Isola o trabalho em branches dedicadas (
feature,develop,release,hotfix,main). - Conventional Commits: Cria um histórico de commits legível por humanos e por ferramentas de automação de changelog.
- SemVer: Regra global de transparência (
MAJOR.MINOR.PATCH) para evolução de bibliotecas e APIs.