Jenkinsfile
como código vivo.

Pipeline como Código: Declarative vs. Scripted Pipeline, Termos Chave e Execução Paralela

Um colega edita um script diretamente na caixa de texto da interface web do Jenkins às 18h, quebra o build de produção e ninguém sabe o que estava escrito antes nem quem alterou. Como transformar o pipeline em código versionado, revisável e paralelo?

Por que o `Jenkinsfile` no Git é a Fonte Única da Verdade (Seção 3.7)

Na Seção 3.7, Sandeep Rawat estabelece a regra de ouro da automação moderna no Jenkins: embora você possa digitar o script do pipeline diretamente na tela de configuração do job (útil apenas para testes rápidos), em qualquer projeto real a definição do pipeline deve morar em um arquivo texto chamado Jenkinsfile na raiz do repositório Git. Escrito na linguagem Groovy (baseada na plataforma Java, assim como o próprio Jenkins) e apoiado nos plugins workflow-aggregator e pipeline-utility-steps, o Jenkinsfile entrega quatro vantagens decisivas:

1. Histórico e Reversão Imutáveis: toda alteração no pipeline passa por Pull Request, revisão de pares e pode ser revertida em segundos com git revert;
2. Descoberta Automática por Branch: permite que o Jenkins crie automaticamente pipelines para cada nova branch e Pull Request;
3. Pausa e Controle de Fluxo: permite pausar o pipeline no meio da execução aguardando um clique humano de aprovação (input) antes de avançar para um ambiente sensível;
4. Execução Sequencial e Paralela: permite encadear etapas dependentes em sequência e disparar etapas independentes ao mesmo tempo com o bloco parallel.

Scripted Pipeline vs. Declarative Pipeline e os 5 Termos Fundamentais

O livro compara as duas sintaxes oficiais suportadas pelo Jenkinsfile e define seus cinco blocos estruturais (pipeline, node/agent, stage, steps e parallel):

// Exemplo prático unindo estrutura Declarativa, ferramentas gerenciadas,
// execução em PARALELO (reduzindo o tempo de build) e bloco script{} controlado:
pipeline {
    agent { label 'linux-agent' }
    options {
        timestamps()
        timeout(time: 20, unit: 'MINUTES')
        disableConcurrentBuilds()
    }
    tools {
        jdk 'jdk-17'
        maven 'maven-3.9'
    }
    stages {
        stage('1. Code Checkout & Stability') {
            steps {
                checkout scm
                sh 'mvn clean compile -DskipTests'
            }
        }
        stage('2. Verificações Paralelas (Qualidade & Testes)') {
            parallel {
                stage('2A. Code Quality (Checkstyle)') {
                    steps {
                        sh 'mvn checkstyle:checkstyle'
                    }
                }
                stage('2B. Unit Testing') {
                    steps {
                        sh 'mvn test'
                    }
                }
                stage('2C. Dockerfile Lint (Hadolint)') {
                    steps {
                        script {
                            if (fileExists('Dockerfile')) {
                                sh 'hadolint Dockerfile --no-fail -f json > hadolint.json'
                            }
                        }
                    }
                }
            }
        }
    }
}

Conexão com o livro · Capítulo 3 (Seção 3.7: Jenkins Pipeline — Scripted vs. Declarative Pipeline, Pipeline Syntax Generator e os termos Pipeline, Node, Stage, Steps e Parallel).

Cofre de Credenciais do Jenkins: Escopos, `credentials()`, `withCredentials` e Armadilhas de Interpolação

No primeiro exemplo do Capítulo 4, variáveis do SonarQube foram colocadas nas configurações globais de ambiente, mas em produção você precisa garantir que tokens do Sonar, senhas do Nexus e chaves SSH nunca apareçam em texto puro nos logs nem fiquem acessíveis para jobs de outras equipes. Como dominar o Cofre de Credenciais do Jenkins?

Tipos de Credenciais e Isolamento por Escopo (Global vs. System vs. Folder)

Nos Capítulos 3.6, 4.2 e 6.2, Sandeep Rawat mostra como cadastrar credenciais identificadas por um ID único (como git-creds, nexus-creds e snyk) para desacoplar segredos do código. O plugin Credentials e o Credentials Binding oferecem cinco formatos principais de segredos:

• Username with password: guarda usuário e senha juntos sob um único ID (usado para Git HTTPS, Sonatype Nexus e Docker Registry);
• Secret text: guarda um token único criptografado (usado para API Token do SonarQube, token do Snyk ou Webhook Token do Slack);
• SSH Username with private key: guarda a chave privada SSH (e sua passphrase opcional) para clonar repositórios Git via SSH ou executar playbooks Ansible em servidores de destino;
• Secret file: guarda um arquivo inteiro de configuração sensível (como um kubeconfig do Kubernetes ou um arquivo settings.xml / certificado), disponibilizando-o em um caminho temporário apenas durante o build e apagando-o imediatamente ao final;
• Escopo por Pasta (Folder-Level Credentials): em vez de cadastrar todas as credenciais no escopo Global do Jenkins (onde qualquer job do servidor poderia referenciar aquele credentialsId), cadastre as credenciais específicas de uma squad dentro da Pasta (Folder) daquela squad! Assim, apenas os pipelines contidos naquela pasta conseguem utilizar o segredo.

`environment { credentials() }` vs. `withCredentials` e a Armadilha das Aspas Duplas em Groovy

Existem duas maneiras seguras de injetar segredos no seu Jenkinsfile, ambas ativando o mascaramento automático (`****`) no Console Output. Mas há uma armadilha de segurança em Groovy que todo engenheiro precisa conhecer:

// Exemplo prático demonstrando as duas formas corretas de injetar credenciais no Jenkinsfile
// sem jamais usar interpolação insegura de aspas duplas Groovy:
pipeline {
    agent any
    stages {
        stage('1. Análise SonarQube (Usando environment credentials no stage)') {
            environment {
                // Secret text: injeta o token apenas durante este estágio
                SONAR_TOKEN = credentials('sonarqube-api-token')
            }
            steps {
                // Aspas simples ('...') garantem que o shell leia $SONAR_TOKEN sem interpolação Groovy!
                sh 'mvn sonar:sonar -Dsonar.host.url=http://sonar.interno:9000 -Dsonar.token=$SONAR_TOKEN'
            }
        }
        stage('2. Publicação e Deploy (Usando withCredentials de escopo mínimo)') {
            steps {
                withCredentials([
                    usernamePassword(
                        credentialsId: 'nexus-creds',
                        usernameVariable: 'NEXUS_USER',
                        passwordVariable: 'NEXUS_PASS'
                    ),
                    sshUserPrivateKey(
                        credentialsId: 'dev-server-ssh-key',
                        keyFileVariable: 'SSH_KEY_FILE',
                        usernameVariable: 'SSH_USER'
                    )
                ]) {
                    sh '''
                        echo "Autenticando no Nexus com usuário: $NEXUS_USER"
                        mvn deploy -DaltDeploymentRepository=nexus::default::http://nexus.interno:8081/repository/maven-releases/
                        ansible-playbook -i hosts playbook.yaml --private-key "$SSH_KEY_FILE" -u "$SSH_USER"
                    '''
                }
            }
        }
    }
}

Conexão com o livro · Capítulos 3 (Seção 3.6), 4 (Seções 4.1.6 e 4.2.2: variáveis SonarQube e `nexus-creds`) e 6 (Seções 6.2.1 e 6.2.5: `git-creds` e token `snyk`).

Estágios de Qualidade em Paralelo: Checkstyle, Hadolint (`Dockerfile`) e `warnings-ng`

Seu código Java/Python passa no linter da linguagem, mas o desenvolvedor alterou o Dockerfile colocando COPY . . na primeira linha, usando a tag :latest e esquecendo de limpar o cache do apt — triplicando o tamanho da imagem e o tempo de cada build. Como auditar código e contêiner juntos no Jenkins?

Integrando Checkstyle e Hadolint com `recordIssues` (Capítulos 4.1.3 e 6.2.2)

No Capítulo 4 (Seção 4.1.3) e no Capítulo 6 (Seção 6.2.2, Código 6.5), Sandeep Rawat evolui o estágio de Code Quality para auditar tanto o código-fonte da aplicação quanto a receita de containerização (Dockerfile) em paralelo, publicando ambos os relatórios no painel do Jenkins através do plugin Warnings Next Generation (`warnings-ng` / step `recordIssues`):

// Trecho completo baseado no Código 6.5 do Capítulo 6, adicionando Quality Gates
// automáticos no plugin warnings-ng para barrar commits que introduzam novos erros graves:
stage('Code Quality | Checkstyle & Hadolint') {
    parallel {
        stage('Checkstyle (App Code)') {
            agent {
                docker {
                    image 'maven:3.9-eclipse-temurin-17'
                    args '-v $HOME/.m2:/root/.m2'
                    reuseNode true
                }
            }
            steps {
                sh 'mvn checkstyle:checkstyle'
                recordIssues(
                    enabledForFailure: true,
                    tools: [checkStyle(pattern: '**/checkstyle-result.xml')],
                    qualityGates: [[threshold: 1, type: 'NEW_ERROR', unstable: false]]
                )
            }
        }
        stage('Hadolint (Dockerfile Best Practices)') {
            steps {
                sh 'hadolint Dockerfile --no-fail -f json | tee hadolint.json'
                recordIssues(
                    enabledForFailure: true,
                    tools: [hadoLint(pattern: 'hadolint.json')],
                    qualityGates: [[threshold: 1, type: 'TOTAL_ERROR', unstable: true]]
                )
            }
        }
    }
}

Conexão com o livro · Capítulos 4 (Seção 4.1.3: Code Quality com Checkstyle e `warnings-ng`) e 6 (Seção 6.2.2: Boas práticas de Dockerfile, instalação do Hadolint e execução paralela no Código 6.5).

Testes Unitários (JUnit) e Cobertura de Código (Cobertura / JaCoCo) com Metas Condicionais

Como configurar o seu Jenkinsfile para executar os testes unitários em um ambiente limpo, publicar gráficos históricos de falhas e impor metas mínimas de cobertura de linha, método e condição?

Automatizando Unit Testing e Code Coverage no `Jenkinsfile` (Capítulos 4.1.4 e 6.2.3/6.2.4)

Nos Capítulos 4 e 6 (Códigos 6.6 e 6.7), Sandeep Rawat demonstra como encadear a execução dos testes unitários e a medição de cobertura de código dentro de contêineres isolados para não poluir o sistema operacional principal do agente Jenkins:

1. Estágio de Unit Testing (`mvn test` / `pytest` + JUnit Parser): executa a suíte de testes unitários (localizada em src/test/java ou tests/) que gera relatórios padronizados em XML (target/surefire-reports/*.xml). No Jenkins, o plugin JUnit / recordIssues(tools: [junitParser(...)]) transforma esses arquivos XML em gráficos de tendência de testes aprovados, ignorados e quebrados a cada build;
2. Estágio de Code Coverage (`mvn cobertura:cobertura` / JaCoCo): instrumenta o bytecode durante a execução dos testes para gerar o relatório coverage.xml e aplica três alvos numéricos independentes no passo cobertura (ou recordCoverage moderno):
   • `lineCoverageTargets: '80, 0, 0'` (meta saudável de 80% de linhas cobertas);
   • `methodCoverageTargets: '80, 0, 0'` (meta saudável de 80% dos métodos testados);
   • `conditionalCoverageTargets: '70, 0, 0'` (meta saudável de 70% das condições lógicas if/else/switch exercitadas nos testes!).

// Estágios de Testes Unitários e Cobertura de Código em contêiner efêmero
// exigindo mínimo de 80% em linhas/métodos e 70% em condições (branches):
stage('Unit Testing & Code Coverage') {
    agent {
        docker {
            image 'maven:3.9-eclipse-temurin-17'
            args '-v $HOME/.m2:/root/.m2'
            reuseNode true
        }
    }
    steps {
        sh 'mvn test cobertura:cobertura'
    }
    post {
        always {
            // Publica os resultados dos testes unitários mesmo se algum teste falhar:
            junit allowEmptyResults: false, testResults: 'target/surefire-reports/*.xml'
            // Publica o relatório de cobertura de código com metas para Linha, Método e Condição:
            cobertura(
                autoUpdateHealth: false,
                autoUpdateStability: false,
                coberturaReportFile: '**/target/site/cobertura/coverage.xml',
                lineCoverageTargets: '80, 60, 75',
                methodCoverageTargets: '80, 60, 75',
                conditionalCoverageTargets: '70, 50, 65',
                failUnhealthy: false,
                failUnstable: true,
                onlyStable: false,
                sourceEncoding: 'UTF-8',
                zoomCoverageChart: true
            )
        }
    }
}

Conexão com o livro · Capítulos 4 (Seção 4.1.4: Unit Testing) e 6 (Seções 6.2.3 e 6.2.4: Unit Testing e Code Coverage em contêineres — Códigos 6.6 e 6.7).

Segurança DevSecOps no Pipeline: OWASP, Snyk (Container Scan), SonarQube e Simulador

Seu código próprio não tem vulnerabilidades, mas uma biblioteca transitiva no `pom.xml` ou um pacote Linux dentro da imagem base do contêiner possui uma CVE crítica recém-descoberta. Como automatizar varreduras de dependências, imagens e SonarQube no `Jenkinsfile`?

Varredura Paralela de Dependências (OWASP) e de Imagens de Contêiner (Snyk / Trivy)

Na Seção 6.2.5 (Código 6.8, páginas 129–134), Sandeep Rawat explica por que testar apenas o código da aplicação não basta quando empacotamos software em contêineres: quase sempre herdamos imagens base públicas que podem conter pacotes de sistema operacional vulneráveis ou configurações inseguras listadas nos benchmarks do CIS (Center for Internet Security) e nas bases de CVEs (Common Vulnerabilities and Exposures).

O livro compara as principais ferramentas de Image Scanning do mercado — Trivy, Anchore, Clair, AquaScanner e Snyk — e monta no Código 6.8 um estágio paralelo de segurança em duas frentes, complementado pela análise centralizada do SonarQube (Seção 4.1.6):

// Implementação baseada no Código 6.8 (Capítulo 6) + Seção 4.1.6 (SonarQube):
stage('Security Testing | OWASP, Snyk & SonarQube') {
    parallel {
        stage('1. Dependency Scan (OWASP)') {
            steps {
                sh 'mvn org.owasp:dependency-check-maven:check'
                publishHTML([
                    allowMissing: false,
                    alwaysLinkToLastBuild: true,
                    keepAll: true,
                    reportDir: 'target',
                    reportFiles: 'dependency-check-report.html',
                    reportName: 'OWASP Dependency Check Report',
                    reportTitles: 'Relatorio de Vulnerabilidades'
                ])
            }
        }
        stage('2. Container Image Scan (Snyk)') {
            steps {
                snykSecurity(
                    snykInstallation: 'snyk',
                    snykTokenId: 'snyk-api-token',
                    additionalArguments: "--docker registry.interno:5000/app/servico:${env.BUILD_ID}",
                    failOnError: true
                )
            }
        }
        stage('3. SonarQube Analysis & Quality Gate') {
            environment {
                SONAR_TOKEN = credentials('sonar-token-cred')
            }
            steps {
                withSonarQubeEnv('sonarqube-prod') {
                    sh 'mvn sonar:sonar -Dsonar.token=$SONAR_TOKEN -Dsonar.java.binaries=target/classes'
                }
                timeout(time: 5, unit: 'MINUTES') {
                    waitForQualityGate abortPipeline: true
                }
            }
        }
    }
}

Conexão com o livro · Capítulos 4 (Seções 4.1.5 e 4.1.6: Security Testing com OWASP Dependency-Check, `publishHTML` e SonarQube) e 6 (Seção 6.2.5: Image Scanning Tools — Trivy, Anchore, Clair, Aqua, Snyk e Código 6.8).

Operações Intermediárias: Upload de Artefatos (Nexus / Registry) e DB Versioning (Flyway)

Por que recompilar o código a cada ambiente (Dev, QA, Produção) viola a confiabilidade da entrega contínua, e como garantir que o artefato binário publicado no Nexus (ou a imagem no Registry) suba sincronizado com as migrações do banco de dados no Flyway?

Publicando Artefatos Imutáveis no Sonatype Nexus e no Docker Registry (Seção 4.2)

Na Seção 4.2 (páginas 89–98), Sandeep Rawat conecta os estágios de pré-deploy aos estágios intermediários que preparam o terreno para o deploy: Artifact Generation & Upload e DB Update. A regra fundamental é construir o pacote binário (.war, .jar, pacote Python/Node ou imagem Docker) uma única vez e promovê-lo entre os ambientes a partir de um repositório central de artefatos:

• Por que usar o plugin `nexusArtifactUploader` no Jenkinsfile em vez de fixar o Nexus no `pom.xml`? Na página 92, o autor destaca um detalhe arquitetural elegante: se você colocar o endereço do servidor Nexus dentro do pom.xml de 30 repositórios e o endereço ou porta do Nexus mudar, você terá que editar 30 arquivos de código-fonte! Ao usar o step nexusArtifactUploader do Jenkins (com credentialsId: 'nexus-creds'), toda a configuração do repositório fica centralizada no pipeline;
• E quando o artefato é uma Imagem Docker (Capítulo 6)? Em aplicações containerizadas (cujo processo de build multi-stage estudamos no curso Docker em Produção com Critério), o estágio de upload autentica no Registro privado (Nexus Docker Registry, Harbor, ECR, GHCR) usando docker.withRegistry('https://...', 'registry-creds') e publica a imagem marcada com o número imutável do build (${env.BUILD_ID}).

Database as Code: Versionando o Schema com Flyway no Pipeline (Seção 2.3.2 e 4.2.4)

Uma das maiores causas de queda em deploys é atualizar o código da aplicação esquecendo de aplicar uma alteração de tabela (ALTER TABLE) no banco de dados daquele ambiente. Com o Flyway (ou Liquibase), cada alteração de schema é um script SQL numerado no Git (ex.: db/migration/V1__create_users.sql, V2__add_phone_column.sql). O Flyway mantém uma tabela de metadados (flyway_schema_history) dentro do próprio banco: quando o estágio DB Update roda mvn flyway:migrate no Jenkins, o Flyway verifica os checksums dos scripts já aplicados e executa automaticamente apenas as migrações novas pendentes!

// Estágios intermediários baseados na Seção 4.2 (Nexus + Ansible Dev + Flyway DB Update):
stage('Uploading Artifact to Nexus') {
    steps {
        nexusArtifactUploader(
            nexusVersion: 'nexus3',
            protocol: 'http',
            nexusUrl: 'nexus.interno:8081',
            groupId: 'org.atelie',
            version: "1.0.${env.BUILD_NUMBER}",
            repository: 'spring3hibernate-releases',
            credentialsId: 'nexus-creds',
            artifacts: [[
                artifactId: 'spring3hibernate',
                classifier: '',
                file: 'target/Spring3HibernateApp.war',
                type: 'war'
            ]]
        )
    }
}
stage('Database Migration (Flyway DB as Code)') {
    steps {
        withCredentials([usernamePassword(credentialsId: 'db-dev-creds', usernameVariable: 'DB_USER', passwordVariable: 'DB_PASS')]) {
            // Valida se nenhum script antigo foi adulterado (validate) antes de aplicar os novos (migrate):
            sh 'mvn flyway:validate flyway:migrate -Dflyway.user=$DB_USER -Dflyway.password=$DB_PASS'
        }
    }
}

Conexão com o livro · Capítulos 2 (Seção 2.3: Artifact Management e DB Versioning) e 4 (Seção 4.2: CI Pipeline update with Intermediate steps — Generating Artifacts, Uploading Artifacts to Nexus, Deployment to Dev e DB Update com Flyway).

Multibranch Pipelines, Condicionais `when` e Notificações Inteligentes (`post`, Slack e Email)

Como usar um único Jenkinsfile para que branches `feature/*` rodem apenas os testes e validações, enquanto a branch `develop` publica o artefato e atualiza o ambiente de Dev — avisando a equipe no Slack e por e-mail com o diagnóstico exato do build?

Operando Multibranch Pipelines com Condicionais `when` (Seção 4.1.7)

Nas páginas 87–89 do Capítulo 4 (Figuras 4.19 a 4.23), Sandeep Rawat converte o job tradicional em um Multibranch Pipeline. Como o mesmo arquivo Jenkinsfile viaja junto com o código por todas as branches (feature/*, develop, main) e Pull Requests, usamos o bloco declarativo when { ... } para controlar quais estágios executam em cada contexto:

• Os estágios de Pre-Deployment Checks (Checkout, Code Stability, Checkstyle/Hadolint, Unit Tests, Cobertura, OWASP, Snyk e SonarQube) rodam em todas as branches e Pull Requests para impedir que código quebrado seja mesclado;
• Os estágios de Upload no Nexus, Deploy em Dev e Migração Flyway levam a cláusula when { branch 'develop' } (ou when { anyOf { branch 'develop'; branch 'main' } }), executando apenas após o merge aprovado!

Notificações Inteligentes com o Bloco `post`, Slack e Email-ext (Seção 4.3)

Na Seção 4.3 (páginas 98–100), o autor implementa a estratégia de Notificações Inteligentes planejada no Capítulo 2. Em vez de criar um estágio manual de notificação que deixa de rodar se um estágio anterior falhar, na sintaxe Declarativa usamos a seção final post { ... } combinando os plugins Slack Notification (`slackSend`) e Extended Email (`emailext`):

// Exemplo prático de Multibranch Pipeline com filtro when{} por branch
// e notificações inteligentes no Slack e E-mail via bloco post{}:
pipeline {
    agent any
    stages {
        stage('Pre-Deployment CI Checks') {
            steps {
                echo "Rodando validação completa na branch: ${env.BRANCH_NAME}"
            }
        }
        stage('Upload Artifact & Deploy Dev') {
            when {
                branch 'develop'
            }
            steps {
                echo "Branch develop detectada: enviando artefato ao Nexus e atualizando ambiente Dev..."
            }
        }
    }
    post {
        success {
            slackSend(
                channel: '#ci-cd-builds',
                color: 'good',
                message: "✅ *SUCESSO:* Job `${env.JOB_NAME}` [#${env.BUILD_NUMBER}] na branch `${env.BRANCH_NAME}` concluído!\nDetalhes: ${env.BUILD_URL}"
            )
        }
        failure {
            slackSend(
                channel: '#ci-cd-alertas',
                color: 'danger',
                message: "🚨 *FALHA no CI:* Job `${env.JOB_NAME}` [#${env.BUILD_NUMBER}] quebrou na branch `${env.BRANCH_NAME}`.\nLogs: ${env.BUILD_URL}console"
            )
            emailext(
                to: 'techlead@empresa.com.br',
                recipientProviders: [developers(), requestor()],
                subject: "[FALHA CI] ${env.JOB_NAME} - Build #${env.BUILD_NUMBER}",
                body: "O build #${env.BUILD_NUMBER} na branch ${env.BRANCH_NAME} falhou.\nInspecione os logs em: ${env.BUILD_URL}console"
            )
        }
        always {
            cleanWs()
        }
    }
}

Conexão com o livro · Capítulos 2 (Seção 2.5: Intelligent Notifications) e 4 (Seções 4.1.7: Converting Multibranch Pipeline e 4.3: CI Pipeline with Notification Integration — Slack e Email).

Shared Libraries (`@Library`): Reutilizando Pipelines em Escala sem Duplicar Código

Sua arquitetura cresceu para vinte microsserviços e todos têm uma cópia colada de 150 linhas de Jenkinsfile. Quando você precisa trocar um parâmetro do SonarQube ou do Snyk, precisa editar vinte repositórios diferentes. Como centralizar a inteligência em uma Shared Library?

A Anatomia de uma Jenkins Shared Library (`vars/`, `src/` e `resources/`)

Na Seção 3.7.3 (páginas 64–66), Sandeep Rawat apresenta o recurso mais poderoso do Jenkins para escalar pipelines como código em equipes profissionais: as Shared Libraries (Bibliotecas Compartilhadas). Assim como em programação não reescrevemos um driver de banco de dados do zero em cada projeto, no Jenkins criamos um repositório Git dedicado para guardar nossa biblioteca de pipelines (registrado em Manage Jenkins > System > Global Pipeline Libraries).

Conforme o diagrama da página 65 do livro, todo repositório de Shared Library segue uma estrutura padronizada de três diretórios na raiz:

Com a Shared Library configurada, o Jenkinsfile na raiz de cada um dos seus 20 microsserviços cai de 150 linhas repetidas para apenas duas linhas limpas! Se amanhã você precisar atualizar a versão do scanner de segurança ou adicionar uma regra de auditoria para toda a empresa, basta atualizar um único arquivo na Shared Library (usando tags/branches versionadas como @Library('atelie-shared-lib@v1.2') _ para evitar que mudanças quebrem builds antigos).

// =========================================================================
// ARQUIVO 1 (No repositório da Shared Library): vars/atelieCIPipeline.groovy
// =========================================================================
def call(Map cfg = [:]) {
    pipeline {
        agent { label cfg.get('agentLabel', 'linux-agent') }
        tools {
            jdk cfg.get('jdkVersion', 'jdk-17')
            maven cfg.get('mavenVersion', 'maven-3.9')
        }
        stages {
            stage('1. Checkout & Stability') {
                steps {
                    checkout scm
                    sh 'mvn clean compile -DskipTests'
                }
            }
            stage('2. Parallel Quality & Security') {
                parallel {
                    stage('Checkstyle & Hadolint') {
                        steps {
                            sh 'mvn checkstyle:checkstyle'
                            recordIssues(tools: [checkStyle(pattern: '**/checkstyle-result.xml')])
                        }
                    }
                    stage('Unit Tests & Cobertura') {
                        steps {
                            sh 'mvn test cobertura:cobertura'
                        }
                    }
                    stage('OWASP & SonarQube') {
                        environment {
                            SONAR_TOKEN = credentials('sonar-token-cred')
                        }
                        steps {
                            sh "mvn sonar:sonar -Dsonar.projectKey=${cfg.appName} -Dsonar.token=\$SONAR_TOKEN"
                        }
                    }
                }
            }
        }
        post {
            failure {
                slackSend channel: cfg.get('slackChannel', '#ci-alertas'),
                          color: 'danger',
                          message: "🚨 Falha no serviço *${cfg.appName}* (${env.BRANCH_NAME}): ${env.BUILD_URL}"
            }
        }
    }
}

// =========================================================================
// ARQUIVO 2 (Na raiz de cada microsserviço): Jenkinsfile (Apenas 2 linhas!)
// =========================================================================
@Library('atelie-shared-library@main') _
atelieCIPipeline(appName: 'servico-telemedicina', jdkVersion: 'jdk-17', slackChannel: '#squad-saude')

Conexão com o livro · Capítulo 3 (Seção 3.7.3: Shared Library — estrutura `resources/`, `src/`, `vars/` e chamada `@Library` no `Jenkinsfile`).