Jenkins na prática
sem gargalos.

Da Retrospectiva Caótica à Integração Contínua: As 3 Fases do Pipeline CI

Na retrospectiva da Sprint 1, a equipe planejou entregar três funcionalidades, mas concluiu apenas uma: a segunda quebrou no QA, a terceira nem começou e os desenvolvedores gastaram quase metade da semana compilando código manualmente e caçando bugs introduzidos por commits de colegas. Como desenhar um fluxo de Integração Contínua que estanque esse sangramento?

O Diagnóstico da Sprint 1 e o Princípio do Feedback Contínuo

Nos Capítulos 1 e 2 de CI/CD Pipeline with Docker and Jenkins, Sandeep Rawat apresenta o caso real de uma equipe construindo uma aplicação de telemedicina (video consultation app, lidando com dados pessoais e histórico médico sensível sob prazo rigoroso de 6 meses / 12 sprints). O quadro da retrospectiva da primeira sprint revela cinco dores clássicas que travam qualquer equipe sem CI/CD: 1) compilação manual lenta após cada alteração e commits de código que nem sequer compila; 2) dependências inseguras que abrem brechas graves; 3) ausência de padrões de código, gerando code smells e código duplicado; 4) testes de regressão e smoke tests executados manualmente a cada release; e 5) todos os desenvolvedores trabalhando em uma única branch compartilhada.

Como destaca o livro na Figura 2.2, sem automação os desenvolvedores chegam a gastar 45% do tempo corrigindo bugs e dívida técnica em vez de construir novas funcionalidades. A primeira decisão arquitetural tomada no Capítulo 2 é definir quando validar o código: em vez de rodar um build apenas à noite (o que obrigaria o desenvolvedor a revisar um dia inteiro de código acumulados às 19h antes de ir para casa), aplica-se o Princípio de Ouro da Integração Contínua — o Feedback Contínuo a cada commit.

A Arquitetura Completa da Integração Contínua em 3 Fases (Capítulo 2)

Para que nenhum detalhe escape antes de escrevermos a primeira linha no Jenkins, o Capítulo 2 organiza o pipeline de CI em três grandes fases sequenciais:

# Simule o portão de Pré-Deploy (Quality Gate estilo SonarQube) demonstrando por que
# medir apenas Line Coverage sem Condition Coverage deixa bugs críticos passarem:
python3 - <<'PY'
modulos = [
    {"servico": "auth-service",    "compila": True, "line_cov": 92, "cond_cov": 85, "cves_criticas": 0},
    {"servico": "payment-service", "compila": True, "line_cov": 90, "cond_cov": 50, "cves_criticas": 0},
    {"servico": "video-service",   "compila": True, "line_cov": 88, "cond_cov": 82, "cves_criticas": 2}
]

for m in modulos:
    falhas = []
    if not m["compila"]: falhas.append("Falha de Code Stability")
    if m["line_cov"] < 80: falhas.append(f"Line Coverage baixa ({m['line_cov']}%)")
    if m["cond_cov"] < 75: falhas.append(f"Condition Coverage insuficiente ({m['cond_cov']}% < 75%)")
    if m["cves_criticas"] > 0: falhas.append(f"{m['cves_criticas']} vulnerabilidade(s) OWASP/CVE")
    status = "QUALITY GATE APROVADO" if not falhas else "BLOQUEADO: " + ", ".join(falhas)
    print(f"[{m['servico']:15}] -> {status}")
PY

Conexão com o livro · Capítulos 1 e 2 · retrospectiva da Sprint 1, princípio do feedback contínuo, Pre-Deployment Checks (Code Stability, SonarQube, Line vs. Condition Coverage, OWASP), Intermediate Operations (Nexus/JFrog e Flyway/Liquibase) e Post-Deployment Checks (Smoke Test 80/20, Regression, API Testing e Notificações).

O Panorama de Ferramentas CI/CD e a Arquitetura Interna do Jenkins

Diante de opções integradas ao Git (GitHub Actions, GitLab CI) e plataformas SaaS (CircleCI, TravisCI), quando o Jenkins auto-hospedado vence o jogo — e como funciona sua arquitetura interna entre o Controller, os Agentes e o diretório JENKINS_HOME?

VCS-Integrated vs. SaaS vs. Self-Hosted: Por que escolher o “Canivete Suíço” Jenkins?

No Capítulo 3 (Seções 3.1 e 3.2), Sandeep Rawat avalia o mercado de ferramentas de CI/CD segundo seis critérios: baixa complexidade inicial, código aberto, integrações disponíveis, independência de plataforma, builds rápidos/estáveis e suporte a Build-as-Code. O livro divide o ecossistema em três famílias:

Arquitetura Master/Controller e Agent/Slave (A Analogia do Mordomo Alfred) e o `JENKINS_HOME`

Na Seção 3.9, o autor usa uma analogia memorável da trilogia Batman: o Jenkins funciona como o mordomo Alfred. Alfred é extraordinariamente competente, mas não faz todo o trabalho pesado sozinho quando dezenas de tarefas acontecem ao mesmo tempo — ele coordena ajudantes especializados. Da mesma forma, o Jenkins opera em uma Arquitetura Distribuída Controller-Agent (Master-Slave):

• Jenkins Controller (Master): é o cérebro central. Sua função é servir a interface web HTTP (porta 8080), guardar as configurações e credenciais, monitorar gatilhos do Git, agendar os builds e despachar a execução para os agentes. Regra de produção: nunca execute compilações pesadas ou testes diretamente no nó Controller! Se um pacote quebrado corromper o sistema operacional ou consumir 100% da CPU/disco durante um build, o servidor Jenkins inteiro cai.
• Jenkins Nodes / Agents (Slaves): são máquinas físicas, VMs ou contêineres efêmeros que recebem ordens do Controller (via protocolo JNLP — Java Network Launch Protocol rodando o arquivo agent.jar / remoting.jar, via SSH ou sob demanda na nuvem/Docker/Kubernetes), executam as etapas do job em um diretório de trabalho isolado e devolvem os logs e artefatos ao Controller. Isso permite que um único Jenkins em Linux dispare builds simultâneos em agentes Linux, Windows e macOS!
• A Anatomia do Diretório `JENKINS_HOME` (Seção 3.8): toda a vida do seu servidor Jenkins reside dentro de uma única árvore de diretórios (por padrão /var/lib/jenkins em instalações Debian/Ubuntu ou /var/jenkins_home em contêineres):
  • config.xml: configuração global do servidor, segurança e agentes;
  • jobs/<nome-do-job>/: contém o config.xml de cada pipeline e a subpasta builds/ com o histórico numerado de execuções, logs de console e artefatos arquivados;
  • plugins/: todos os plugins instalados (arquivos .jpi / .hpi e suas pastas extraídas);
  • secrets/ e credentials.xml: chaves criptográficas mestras (master.key e hudson.util.Secret) que protegem todas as senhas e tokens cadastrados;
  • workspace/: área temporária onde o código é baixado quando um job roda localmente.

# Simule um inspetor da árvore JENKINS_HOME e calcule quantos Agentes/Executors são necessários
# para zerar filas de espera mantendo 0 executors de build no nó Controller:
python3 - <<'PY'
estrutura_jenkins_home = {
    "config.xml": "Configuração principal, Security Realm e definições de Nodes/Clouds",
    "credentials.xml + secrets/": "Cofre criptografado de tokens Git, SSH keys e senhas (CRÍTICO PARA BACKUP)",
    "jobs/": "Definições XML dos jobs/pastas e histórico de builds/logs",
    "plugins/": "Pacotes .hpi/.jpi instalados do Update Center",
    "workspace/": "Diretórios de checkout de código (efêmero, não incluir no backup rápido)"
}

print("Anatomia do diretório JENKINS_HOME:")
for item, desc in estrutura_jenkins_home.items():
    print(f"  /{item:26} -> {desc}")

# Dimensionamento de Executors: 24 builds/hora com duração média de 5 minutos (capacidade = 12 builds/hora por executor)
builds_por_hora = 24
duracao_media_min = 5
executors_necessarios = int((builds_por_hora * duracao_media_min) / 60) + 1
print(f"\nRegra de Ouro: Controller Executors = 0 | Agentes dedicados necessários: {executors_necessarios} executors paralelos")
PY

Conexão com o livro · Capítulo 3 (Seções 3.1, 3.2, 3.8 e 3.9) · Tooling landscape (VCS Integrated, SaaS, Self-Hosted), Why Jenkins, diretório JENKINS_HOME e arquitetura Master-Slave (Controller-Agent).

Instalação Rápida do Jenkins: Linux (Debian/Systemd), Ansible e Contêiner Docker

Como colocar um servidor Jenkins LTS no ar em menos de cinco minutos — seja diretamente em uma máquina Linux Debian/Ubuntu, provisionado sem intervenção humana via Ansible ou isolado em contêiner com volume persistente?

Método 1: Instalação Nativa em Linux (Debian / Ubuntu) e Desbloqueio Inicial

Na Seção 3.3, Sandeep Rawat demonstra que o único pré-requisito obrigatório para rodar o Jenkins é o Java (JDK). Em servidores Linux da família Debian/Ubuntu, a instalação oficial via gerenciador de pacotes configura automaticamente o serviço do sistema operacional (systemd), o usuário dedicado jenkins e o diretório /var/lib/jenkins:

1. Instale o pacote do OpenJDK (nas versões LTS modernas do Jenkins, utilize Java 17 ou Java 21);
2. Adicione a chave GPG oficial do repositório Jenkins e registre o repositório debian-stable em /etc/apt/sources.list.d/jenkins.list;
3. Atualize o índice do apt, instale o pacote jenkins, inicie e habilite o serviço no boot com systemctl start/enable jenkins;
4. Libere a porta padrão 8080 no firewall (ufw allow 8080) e acesse http://ip_do_servidor:8080;
5. Na tela inicial Unlock Jenkins (Figura 3.6), leia a senha administrativa temporária gerada pelo instalador em /var/lib/jenkins/secrets/initialAdminPassword.

Método 2: Provisionamento Automatizado com Ansible e Método 3: Subida Rápida em Docker

Para evitar repetir comandos manuais a cada novo servidor (seguindo o princípio de Infraestrutura como Código), o Capítulo 3.3.3 apresenta a automação via Ansible usando roles prontas do Ansible Galaxy (como opstree_devops.jenkins ou geerlingguy.jenkins) que já instalam o Java, o Jenkins, os plugins essenciais e as configurações globais em um único comando ansible-playbook -i hosts site.yml.

# =========================================================================
# OPÇÃO A: Instalação nativa em Debian/Ubuntu (Capítulo 3.3.1 atualizado LTS)
# =========================================================================
sudo apt-get update && sudo apt-get install -y fontconfig openjdk-17-jre
sudo wget -O /usr/share/keyrings/jenkins-keyring.asc https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt-get update && sudo apt-get install -y jenkins
sudo systemctl enable --now jenkins
sudo ufw allow 8080
sudo cat /var/lib/jenkins/secrets/initialAdminPassword

# =========================================================================
# OPÇÃO B: Provisionamento automatizado com Ansible (Capítulo 3.3.3)
# =========================================================================
cat <<'EOF' > hosts
[jenkins]
10.1.1.100 ansible_ssh_user=ubuntu ansible_ssh_private_key_file=~/.ssh/id_ed25519
EOF

cat <<'EOF' > site.yml
---
- hosts: jenkins
  become: yes
  roles:
    - opstree_devops.jenkins
EOF
# Executar com: ansible-playbook -i hosts site.yml

# =========================================================================
# OPÇÃO C: Subida rápida em Contêiner (Persistindo /var/jenkins_home)
# =========================================================================
docker run -d --name jenkins-controller \
  --restart=on-failure \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home_data:/var/jenkins_home \
  jenkins/jenkins:lts-jdk17
docker exec jenkins-controller cat /var/jenkins_home/secrets/initialAdminPassword

Conexão com o livro · Capítulo 3 (Seção 3.3: Jenkins Installation) · instalação em Linux (Debian/Ubuntu, systemctl, ufw 8080), instalação em Windows (serviço vs. processo local), desbloqueio com `initialAdminPassword` e automação completa via Ansible + integração com o curso de Docker.

Arquitetura de Plugins: Web UI, Jenkins-CLI, Arquivos `.hpi` Offline e as 5 Famílias Essenciais

Você precisa instalar quinze plugins padronizados via script sem clicar em menus ou atualizar um servidor Jenkins corporativo que roda em uma rede fechada sem acesso à internet. Como dominar o ecossistema de plugins do Jenkins por dentro?

O Update Center, os Arquivos `.hpi` e os 3 Métodos de Instalação (Seção 3.4)

Na Seção 3.4, Sandeep Rawat explica que o Jenkins segue uma arquitetura plug and play pura: o núcleo do servidor é enxuto e quase toda funcionalidade — de conectar ao Git até publicar relatórios HTML ou acionar agentes SSH — vem de plugins desenvolvidos em Java pela comunidade e distribuídos pelo repositório central chamado Update Center. Cada plugin é empacotado em um arquivo com extensão .hpi (ou .jpi, derivado do formato de arquivo comprimido Hemera Technologies Proprietary Image) contendo o código compilado, metadados de versão e dependências.

O livro detalha três métodos complementares para instalar e atualizar plugins:

1. 1. Pela Interface Web (`Manage Jenkins > Manage Plugins`): dividida em quatro abas — Updates (plugins instalados que possuem versão mais nova no Update Center), Available (catálogo para buscar e instalar novos plugins), Installed (inventário atual) e Advanced (configuração de proxy HTTP, URL customizada de Update Center e upload manual de arquivo .hpi). Recomendação de ouro do livro (página 51): embora exista o botão Install without restart, prefira sempre reiniciar o serviço do Jenkins após instalar ou atualizar plugins estruturais (Download now and install after restart), pois muitos plugins só carregam seus ganchos de memória corretamente após o reinício!
2. 2. Pela Linha de Comando (`jenkins-cli.jar` / `jenkins-plugin-cli`): ideal para engenheiros DevOps que automatizam a criação do servidor por scripts. Você baixa o cliente jenkins-cli.jar diretamente do seu próprio servidor (em http://seu_jenkins:8080/jnlpJars/jenkins-cli.jar) e executa o subcomando install-plugin passando as flags -deploy (instalar imediatamente) ou -restart (reiniciar após concluir).
3. 3. Instalação Offline / Sem Internet via Arquivo `.hpi` (Seção 3.4.3): quando o servidor Jenkins roda em uma rede corporativa isolada sem acesso externo ao Update Center, você baixa o arquivo <plugin>.hpi em uma máquina autorizada (a partir de https://updates.jenkins-ci.org/download/plugins/), valida sua integridade e o instala fazendo upload na aba Manage Plugins > Advanced > Deploy Plugin ou copiando o arquivo .hpi diretamente para o diretório $JENKINS_HOME/plugins/ e reiniciando o serviço.

As 5 Categorias de Plugins Indispensáveis no Dia a Dia (Seção 3.5)

Entre os mais de 1.500 plugins disponíveis, o Capítulo 3 seleciona o conjunto essencial que estrutura qualquer servidor profissional:

# 1. Comandos para baixar o jenkins-cli.jar e instalar o pacote essencial de plugins com restart:
# wget http://localhost:8080/jnlpJars/jenkins-cli.jar
# java -jar jenkins-cli.jar -s http://localhost:8080 -auth admin:SEU_API_TOKEN \
#   install-plugin git cloudbees-folder workflow-aggregator warnings-ng htmlpublisher sonar audit-trail thinBackup slack email-ext -restart

# 2. Validador em Python para auditar se todos os plugins obrigatórios das 5 famílias estão presentes:
python3 - <<'PY'
plugins_obrigatorios = {
    "SCM": ["git", "workflow-scm-step"],
    "UI": ["cloudbees-folder", "pipeline-stage-view"],
    "Admin": ["ssh-slaves", "audit-trail", "thinBackup"],
    "Build": ["warnings-ng", "htmlpublisher", "sonar"],
    "Pipeline_Notify": ["workflow-aggregator", "pipeline-utility-steps", "slack", "email-ext"]
}

total = sum(len(v) for v in plugins_obrigatorios.values())
print(f"Manifesto Base de Produção validado ({total} plugins essenciais em 5 categorias):")
for cat, lista in plugins_obrigatorios.items():
    print(f"  [{cat:15}] -> {', '.join(lista)}")
PY

Conexão com o livro · Capítulo 3 (Seções 3.4 e 3.5: Plugins) · Update Center, formato `.hpi`, instalação via Web UI, Jenkins-CLI e arquivos `.hpi` offline, e plugins de SCM (Git), UI (Folders, BlueOcean), Administração (Agents, AuditTrail), Build Management (Warnings-NG, HTML Publisher, SonarScanner) e Notificações (Slack, Email-ext).

Segurança no Jenkins: Autenticação (Security Realm), Autorização RBAC e Simulador de ROI

Por que deixar o Jenkins com a opção “Logged-in users can do anything” ativada transforma qualquer conta de estagiário ou desenvolvedor em um superadministrador capaz de ler segredos de produção e apagar pipelines de outros times?

Autenticação (Trancar o Portão) vs. Autorização (Trancar os Cômodos e Gavetas)

Na Seção 3.6, Sandeep Rawat enfatiza por que a segurança do Jenkins exige atenção máxima: o Jenkins senta exatamente no meio da infraestrutura com acesso ao código-fonte, aos repositórios de artefatos, aos bancos de dados e aos servidores de produção, além de guardar senhas, tokens e chaves privadas. O livro divide a blindagem em dois domínios independentes configurados em Manage Jenkins > Configure Global Security:

1. 1. Authentication (Autenticação — O *Security Realm*): define quem pode fazer login no Jenkins. As opções suportadas incluem:
   • Jenkins’ own user database (Banco próprio do Jenkins): simples para times pequenos, mas jamais marque a caixa “Allow users to sign up” (o administrador deve controlar toda criação de conta);
   • LDAP / Active Directory e Unix User/Group Database: centraliza usuários em diretórios corporativos;
   • Identity Provider Plugins / Single Sign-On (SSO — Google Login, GitHub OAuth, SAML/Okta): a recomendação número um para ambientes de produção, pois elimina senhas duplicadas, impõe MFA centralizado e desativa o acesso instantaneamente quando alguém sai da empresa.
2. 2. Authorization (Autorização — O que cada usuário autenticado pode fazer): os modos “Anyone can do anything”, “Legacy mode” e “Logged-in users can do anything” nunca devem ser usados em produção. Para controle granular real, o Capítulo 3 compara duas estratégias avançadas:
   • Matrix-based Security / Project-based Matrix Authorization: atribui permissões granulares em uma tabela (Overall, Credentials, Agent, Job, Run, View, SCM), permitindo no modo Project-based definir listas de controle de acesso (ACLs) específicas por projeto;
   • Role-Based Authorization Strategy (RBAC — Recomendação de Ouro do Livro): em vez de dar permissões usuário por usuário, você cria Papéis (Roles) em Manage Jenkins > Manage and Assign Roles divididos em Global Roles (ex.: admin, viewer_global) e Item / Project Roles baseadas em expressões regulares sobre o nome da pasta/job (ex.: o papel dev_pagamento com padrão ^Pagamentos/.* permite criar e disparar apenas jobs dentro da pasta Pagamentos/!).

# Teste suas expressões regulares (Regex) do plugin Role-Based Authorization Strategy
# antes de aplicá-las no Jenkins para garantir que uma squad nunca enxergue ou dispare jobs de outra:
python3 - <<'PY'
import re

jobs_no_servidor = [
    "Backend/api-pagamentos-ci",
    "Backend/servico-video-ci",
    "Frontend/web-portal-ci",
    "Infra/terraform-prod-deploy"
]

item_roles = {
    "role_backend_dev": r"^Backend/.*",
    "role_frontend_dev": r"^Frontend/.*",
    "role_sre_infra": r"^Infra/.*"
}

for role, padrao in item_roles.items():
    regex = re.compile(padrao)
    liberados = [j for j in jobs_no_servidor if regex.match(j)]
    print(f"Papel RBAC '{role:17}' (Regex: {padrao:14}) -> Acesso permitido a: {liberados}")
PY

Conexão com o livro · Capítulo 3 (Seção 3.6: Authentication and Authorization) · Security Realm (Basic Auth, Servlet, LDAP, Unix, SSO) e Authorization (Matrix-based, Project-based Matrix e a recomendação de produção SSO + Role-Based Authorization Strategy).

Global Tool Configuration e as 3 Linhas de Defesa em Backup (`ThinBackup` e `JENKINS_HOME`)

Um projeto legado exige JDK 8 com Maven 3.6, enquanto o novo microsserviço exige JDK 21 com Maven 3.9 — e um comando errado no terminal ameaça apagar o servidor Jenkins inteiro. Como gerenciar múltiplas ferramentas e blindar o servidor com três camadas de backup?

Global Tool Configuration: Múltiplas Versões de JDK, Maven, SonarScanner e Docker (Seção 3.10)

Na Seção 3.10, Sandeep Rawat apresenta o painel Global Tool Configuration (acessado em Manage Jenkins > Tools / Global Tool Configuration). Em vez de instalar uma única versão global de compilador no sistema operacional e travar todos os times na mesma versão, o Jenkins permite declarar múltiplas instalações nomeadas de JDK, Git, Maven, Gradle, Ant, SonarQube Scanner, Snyk e Docker:

• Você pode apontar para um caminho já instalado nos agentes (ex.: /usr/lib/jvm/java-17-openjdk-amd64) ou marcar a opção Install automatically (Instalar automaticamente), fazendo com que o Jenkins baixe e extraia a versão exata da ferramenta sob demanda no nó agente apenas para o job que a solicitou!
• Assim, o Job A declara tools { jdk 'jdk-8'; maven 'maven-3.6' } e o Job B declara tools { jdk 'jdk-21'; maven 'maven-3.9' } no mesmo servidor sem nenhum conflito.

“E se o servidor for deletado?” As 3 Linhas de Segurança em Backup (Seção 3.8)

Na Seção 3.8 (páginas 67–70), o livro lembra uma verdade dura: “Um crash do Jenkins sem backup custa um dia e uma noite inteiros de trabalho para colocar tudo no ar novamente.” Como o servidor Jenkins guarda todas as integrações, usuários, credenciais e históricos da empresa, Rawat estrutura três linhas de segurança complementares:

# Veja como criar um script de backup enxuto do JENKINS_HOME (2ª Linha de Defesa do Capítulo 3.8)
# que preserva todas as configurações, jobs, plugins e chaves criptográficas ignorando workspaces pesados:
python3 - <<'PY'
script_backup_sh = """#!/usr/bin/env bash
set -euo pipefail
JENKINS_HOME="${JENKINS_HOME:-/var/lib/jenkins}"
BACKUP_DIR="/backup/jenkins"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
mkdir -p "$BACKUP_DIR"

# Compacta configs XML, jobs (sem workspaces temporários), usuários, plugins e segredos mestres:
tar -czf "$BACKUP_DIR/jenkins_home_${TIMESTAMP}.tar.gz" \\
  --exclude="workspace/*" \\
  --exclude="caches/*" \\
  --exclude="war/*" \\
  -C "$JENKINS_HOME" \\
  config.xml credentials.xml secret.key secret.key.not-so-secret \\
  secrets/ users/ jobs/ nodes/ plugins/*.jpi plugins/*.hpi

echo "Backup concluído: $BACKUP_DIR/jenkins_home_${TIMESTAMP}.tar.gz"
"""
print(script_backup_sh)
PY

Conexão com o livro · Capítulo 3 (Seções 3.8: What If the Server Gets Deleted — ThinBackup, JENKINS_HOME backup e Server Image; e 3.10: Global Tool Configuration — JDK, Maven, SonarScanner, Snyk e Docker).

Estratégia de Branching, Organização com Pastas (`Folders`) e Conexão com o Git

Se dez desenvolvedores fazem push diretamente na mesma branch e você tem cinquenta jobs espalhados na tela inicial do Jenkins, cada deploy vira uma roleta-russa. Como alinhar a estratégia de ramificação do Git à hierarquia de jobs no Jenkins?

A Estratégia de Branching para CI/CD sem Conflitos (Seção 2.6, Figura 2.10)

Na Seção 2.6 do Capítulo 2, o líder de desenvolvimento Adeel confessa o motivo pelo qual a equipe perdia horas resolvendo conflitos de merge e não conseguia fazer rollback: todo mundo desenvolvia, corrigia bugs e fazia deploy a partir de uma única branch! Para resolver isso sem criar uma burocracia excessiva de dezenas de branches aninhadas, Abhishek e Adeel definem o fluxo pragmático da Figura 2.10 (que complementa perfeitamente o que estudamos na nossa trilha Git com Critério — Etapa 2):

1. Feature Branches (`feature/*`): criadas a partir da branch develop para cada nova funcionalidade. Ao abrir um Pull Request para develop, o Jenkins executa automaticamente os Pre-Deployment Checks (compilação, Checkstyle/SonarQube, testes unitários e OWASP);
2. Development Branch (`develop`): quando o Pull Request é aprovado e mesclado na develop, o pipeline de CI do Jenkins gera o artefato versionado, envia ao Nexus, aplica as migrações de banco com Flyway e faz o deploy automático no ambiente de Desenvolvimento/QA seguido de Smoke Tests;
3. Master / Main Branch (`main` / `master`): após validação em homologação, um Pull Request promove o código para a main, disparando o fluxo de entrega para Produção;
4. Hotfix Branches (`hotfix/*`): se surgir um bug crítico em produção, cria-se a branch hotfix/* diretamente a partir da main; após passar pelo pipeline do Jenkins e corrigir produção, as branches develop e feature/* puxam (pull) a correção imediatamente.

Organizando o Servidor com `Folders` e Configurando o Plugin Git (Capítulos 3.5 e 4.1)

Antes de criar jobs soltos na tela inicial do Jenkins, o Capítulo 3.5.2 recomenda usar o plugin Folders (`cloudbees-folder`) para criar diretórios hierárquicos por projeto, squad ou estágio (por exemplo: CI/, CD-QA/, CD-Prod/ ou Obvis/Backend/). Dentro da pasta, você conecta o job ao seu repositório Git definindo:

# Veja como o Jenkins decide automaticamente quais estágios executar com base na branch do Git
# seguindo a estratégia de Branching da Figura 2.10 do livro:
python3 - <<'PY'
branches_evento = ["feature/login-video", "develop", "hotfix/corrige-timeout", "main"]

for br in branches_evento:
    estagios = ["1. Checkout", "2. Code Stability", "3. Code Quality (Sonar)", "4. Unit & OWASP Tests"]
    if br == "develop":
        estagios += ["5. Upload Artifact (Nexus)", "6. Deploy Dev + Flyway DB", "7. Smoke & API Tests"]
    elif br.startswith("hotfix/") or br == "main":
        estagios += ["5. Release Artifact", "6. Deploy Staging/Prod", "7. Smoke Test + Slack Alert"]
    print(f"Branch: {br:24} -> Estágios acionados: {' -> '.join(estagios)}")
PY

Conexão com o livro · Capítulos 2 (Seção 2.6: Branching Strategy), 3 (Seção 3.5: Git e Folders Plugins) e 4 (Seção 4.1.7: Converting Multibranch Pipeline).

Gatilhos Push vs. Pull: Webhooks, Poll SCM e o Primeiro Job com Pipeline Syntax Generator

Como fazer o Jenkins iniciar o build no exato segundo em que um desenvolvedor executa git push no GitHub ou GitLab — e o que fazer quando o servidor Jenkins está atrás de um firewall corporativo que bloqueia conexões externas?

Mecanismo Push-Based (Webhooks) vs. Pull-Based (Poll SCM) (Capítulo 2, Página 19)

Na página 19 do Capítulo 2, Abhishek, Adeel e Sonia discutem uma decisão arquitetural que todo engenheiro precisa dominar ao conectar o Git ao Jenkins: como o servidor de CI descobre que há um novo commit no repositório? Existem dois mecanismos fundamentais:

Gerando seu Primeiro Pipeline com o Pipeline Syntax Generator (Capítulo 4.1)

Na Seção 4.1 (páginas 77–81), Sandeep Rawat ensina a regra número um antes de automatizar qualquer etapa no Jenkins: sempre execute e valide os comandos primeiro no terminal de uma máquina de desenvolvimento (PoC) antes de colocá-los no pipeline. Uma vez validados, você não precisa decorar a sintaxe Groovy de cada plugin de cabeça: o Jenkins inclui o Pipeline Syntax (Snippet Generator) (Figura 3.26 e 4.6), que gera o bloco de código exato ao preencher o formulário na tela!

Abaixo estão os dois formatos fundamentais de código que o Jenkins utiliza (e que aprofundaremos ao máximo na Etapa 2): a sintaxe Scripted Pipeline (mostrada nos primeiros exemplos do Capítulo 4 com node("master")) e a sintaxe moderna Declarative Pipeline (recomendada com pipeline { agent any ... }), já realizando o Code Checkout e a verificação inicial de Code Stability:

// =========================================================================
// 1. SINTAXE DECLARATIVA MODERNA (Recomendada para o seu Jenkinsfile)
// =========================================================================
pipeline {
    agent any
    triggers {
        // Recebe evento instantâneo via Push (Webhook) ou verifica a cada 5 min com H (Hash)
        githubPush()
        pollSCM('H/5 * * * *')
    }
    stages {
        stage('1. Cloning Project (Code Checkout)') {
            steps {
                git branch: 'main',
                    credentialsId: 'git-token-cred',
                    url: 'https://github.com/bpbpublications/CI-CD-Simplified.git'
            }
        }
        stage('2. Code Stability (Compilation Check)') {
            steps {
                sh 'mvn clean compile -DskipTests'
            }
        }
    }
}

// =========================================================================
// 2. EQUIVALENTE SCRIPTED PIPELINE (Capítulo 4.1 do livro)
// =========================================================================
node('linux-agent') {
    stage('Cloning Spring3Hibernate Project') {
        git url: 'https://github.com/bpbpublications/CI-CD-Simplified'
    }
    stage('Code Stability') {
        sh 'mvn clean install -DskipTests'
    }
}

Conexão com o livro · Capítulos 2 (Seção 2.2: Pull-based vs. Push-based mechanism), 3 (Seção 3.7: Scripted vs. Declarative Pipeline e Pipeline Syntax Generator) e 4 (Seções 4.1.1 e 4.1.2: Code Checkout e Code Stability).