📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Módulo 13: DevOps e Cloud. Recomendado revisar antes de começar.
v1.0 — Versionamento Profissional, Branching Strategy e Automação de CI/CD
Trilha de Especialização Pedagógica — Projeto 1 de 4
- ➡️ v1 (este): Git Flow · Conventional Commits · Pull Requests · GitHub Actions CI
- v2: Trunk-Based Development & Monorepos
- v3: Git Hooks com Husky & Lint-Staged
- v4: Release Automation & Semantic Release
🎓 Nível Profissional Simulado: Desenvolvedor Júnior / Engenheiro DevOps Trainee. Saber
git commitegit pushnão é suficiente para o mercado. Equipes de alta performance trabalham com fluxos estruturados de branches, mensagens semânticas rastreáveis e pipelines de Integração Contínua (CI) que bloqueiam código quebrado antes de chegar em produção.
Implementar um fluxo de versionamento corporativo com Git Flow, padronização de Conventional Commits (feat:, fix:, docs:, refactor:), abertura de Pull Requests com Template de Revisão e pipeline automatizado de GitHub Actions para validação de build e testes a cada commit.
“Nosso time está cometendo código quebrado direto na branch main com mensagens inúteis como ‘ajustes’ ou ‘arrumando bug’. Precisamos padronizar o Git Flow com branches separadas por funcionalidade, exigir commits semânticos rastreáveis e configurar um workflow do GitHub Actions que rode os testes automaticamente em todo Pull Request e trave o merge se houver erros.”
| ID | Tipo | Descrição | Origem no Briefing |
|---|---|---|---|
| RF01 | Funcional | Estruturar branches main, develop e feature/US.... |
“branches separadas por funcionalidade” |
| RF02 | Funcional | Padronizar mensagens de commit segundo a convenção Conventional Commits. | “commits semânticos rastreáveis” |
| RF03 | Funcional | Configurar workflow de CI no GitHub Actions (.github/workflows/ci.yml). |
“workflow do GitHub Actions” |
| RNF01 | Não-Funcional | O pipeline de CI deve executar em menos de 2 minutos no GitHub. | Produtividade / CI |
| RNF02 | Não-Funcional | Trava de merge se a suíte de testes falhar no Pull Request. | Qualidade de Software |
| ID | User Story | Prioridade |
|---|---|---|
| US01 | Como desenvolvedor, quero abrir uma branch de feature e submeter um PR com checklist. | Alta |
| US02 | Como Tech Lead, quero ver o status do build do GitHub Actions direto na interface do PR. | Alta |
# 1. Partir da branch principal atualizada
git checkout main && git pull origin main
# 2. Criar branch da funcionalidade
git checkout -b feature/US01-pipeline-ci
# 3. Commitar com mensagem semântica
git add .
git commit -m "ci: adicionar workflow do github actions para validacao de testes (US01)"
# 4. Enviar para o GitHub
git push -u origin feature/US01-pipeline-ci
.github/workflows/ci.yml)name: Continuous Integration
on:
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Executar Testes Automatizados
run: echo "Executando testes no ambiente de CI..."
No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:
cd devops_01_pipeline_git_actions
terraform init && terraform plan
# ou docker-compose up -d
[!TIP] Dica para execução a partir da raiz do repositório: Se você abriu o repositório completo no VS Code, basta navegar até a pasta antes de executar: cd catalogo_projetos/devops_01_pipeline_git_actions`
O diagrama abaixo ilustra a topologia de componentes, balanceamento, esteiras de automação e observabilidade na subpasta .github/:
flowchart TD
subgraph Config["Configuração & IaC"]
C1["Manifestos Declarativos"] --> C2["Variáveis & Segredos"]
end
subgraph Orquestracao["Orquestração & Redes"]
O1["Load Balancer / Ingress"] --> O2["Pods / Contêineres de Serviço"]
end
subgraph Observabilidade["Observabilidade & Segurança"]
M1["Telemetria Prometheus / k6"] --> M2["Scanners SAST & Dashboards"]
end
subgraph Qualidade["Homologação & Qualidade"]
Q1["Automação CI/CD"] --> Q2["Checkpoints CP-01..05 PASS"]
end
Config --> Orquestracao
Orquestracao --> Observabilidade
Observabilidade --> Qualidade
style Config fill:#e3f2fd,stroke:#1976d2,stroke-width:1.5px
style Orquestracao fill:#fffde7,stroke:#fbc02d,stroke-width:1.5px
style Observabilidade fill:#e8f5e9,stroke:#388e3c,stroke-width:1.5px
style Qualidade fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px
| ID | Persona | História de Usuário | Critério de Aceite | Prioridade |
|---|---|---|---|---|
| US-01 | Desenvolvedor de Software | Desejo pipeline de CI disparado a cada Push e Pull Request | Execução automática de linting, testes unitários e verificação de tipagem | Alta |
| US-02 | Tech Lead | Desejo validação obrigatória de Commits Semânticos (Conventional Commits) | Check de PR bloqueando merges fora do padrão feat:, fix:, docs:, chore: | Alta |
| US-03 | Engenheiro de Release | Desejo automação de versionamento semântico (SemVer) e changelog | Geração automática de tags Git e releases com notas de versão | Alta |
| US-04 | Analista de Qualidade | Desejo execução de testes em matriz de sistemas e versões do Python/Node | Estratégia matrix rodando em Ubuntu, Windows e múltiplas versões de runtime | Média |
| US-05 | Auditor de CI | Desejo validação local de workflows com a ferramenta act | Capacidade de reproduzir a pipeline localmente sem poluir o histórico Git | Média |
| ID | Descrição do Requisito | Criticidade |
|---|---|---|
| RF-01 | Workflows GitHub Actions estruturados com triggers on: [push, pull_request] | Alta |
| RF-02 | Job de validação de mensagens de commit conforme Conventional Commits | Alta |
| RF-03 | Matriz de execução multi-versão com cache de dependências | Alta |
| RF-04 | Publicação automática de relatórios de cobertura de testes em artefatos | Média |
| RF-05 | Módulo de testes automatizados com scripts de lint e execução local | Média |
| ID | Especificação Arquitetural | Criticidade |
|---|---|---|
| RNF-01 | Tempo total de execução da esteira em nuvem inferior a 3 minutos | Alta |
| RNF-02 | Segurança de segredos utilizando GITHUB_TOKEN e permissões restritas | Alta |
| RNF-03 | Sintaxe dos workflows 100% encapsulada contra parsing Liquid do Jekyll | Alta |
| RNF-04 | Conformidade com padrões oficiais GitHub Actions e Git Flow | Média |
| RNF-05 | Estruturação dos workflows na pasta .github/workflows/ | Alta |
| User Story | Requisito Funcional | Requisito Não-Funcional | Módulo / Artefato de Código | Status de Homologação |
|---|---|---|---|---|
| US-01 | RF-01 |
RNF-01, RNF-03 |
.github/workflows/ci.yml |
Testado |
| US-02 | RF-02 |
RNF-02, RNF-04 |
.github/workflows/commit-lint.yml |
Testado |
| US-03 | RF-03 |
RNF-01, RNF-03 |
.github/workflows/release.yml |
Testado |
| US-04 | RF-04 |
RNF-01, RNF-02 |
.github/workflows/ci.yml |
Testado |
| US-05 | RF-05 |
RNF-03, RNF-05 |
.github/workflows/test_local.sh |
Testado |
| Checkpoint | Escopo da Validação | Artefato Verificado | Status |
|---|---|---|---|
| CP-01 | Configuração Declarativa do Ambiente | .github/ |
PASS ✅ |
| CP-02 | Provisionamento & Orquestração | Deployments / Services |
PASS ✅ |
| CP-03 | Redes, Proxies & Segurança de Borda | Ingress / Security Groups |
PASS ✅ |
| CP-04 | Observabilidade, Métricas & SAST | Metrics / Scanners |
PASS ✅ |
| CP-05 | Homologação com Suíte de Testes | Test Suite / CI Gate |
PASS ✅ |