Visão geral do curso

Este mini curso foi desenhado para te levar da base do Jenkins ate um fluxo profissional de CI/CD com pipelines versionadas, agentes dinamicos em Docker e governanca operacional.

Ao longo dos 7 dias, voce vai construir uma trilha progressiva e pratica:

• começar com fundamentos de CI/CD e arquitetura Jenkins
• subir Jenkins com Docker e preparar ambiente reproduzivel
• evoluir de pipelines basicas para intermediarias e avancadas
• implementar multibranch e shared library
• operar com seguranca, backup e rotina de manutencao

O que voce vai dominar

• Pipeline as Code com Jenkinsfile declarativa
• Build, testes e empacotamento com rastreabilidade
• Multibranch para fluxo de branch e pull request
• Provisionamento de agents Docker por demanda
• Boas praticas de seguranca, credenciais e governanca

Para quem este curso e indicado

• pessoas desenvolvedoras que querem padronizar CI/CD
• profissionais DevOps iniciando ou consolidando Jenkins
• times que precisam reduzir tempo de entrega com qualidade

Pre-requisitos recomendados

• noções de Git e linha de comando
• Docker instalado no ambiente local
• conhecimento basico de build Java/Maven (desejavel)

Trilha de 7 dias

• Day 01: Fundamentos do Jenkins
• Day 02: Jenkins com Docker
• Day 03: Pipelines Basicos
• Day 04: Pipelines Intermediarios
• Day 05: Pipelines Avancados
• Day 06: Agents Docker
• Day 07: Seguranca e Governanca

Como aproveitar melhor

1. Estude um modulo por dia e execute os exemplos.
2. Adapte os Jenkinsfiles ao seu repositorio real.
3. Use o pacote ZIP de materiais como base de aceleracao.
4. No final, aplique o checklist de governanca no seu ambiente.

Resultado esperado

Ao concluir o curso, voce tera uma base pronta para operar Jenkins em ambiente real, com pipeline escalavel, padronizacao de scripts e processo de manutencao continua.

Day 01 | Fundamentos do Jenkins

Objetivos

• Compreender o papel do Jenkins no ciclo de CI/CD
• Entender arquitetura controller/agents
• Executar um primeiro pipeline declarativo

CI/CD na prática

A proposta de CI/CD é reduzir risco por meio de mudanças pequenas e frequentes.

• CI valida cada commit com build e testes
• CD prepara ou publica a entrega com automação
• Feedback rápido reduz custo de correção

Arquitetura do Jenkins

O Jenkins opera com dois papéis principais:

• Controller: orquestra jobs, plugins, filas e histórico
• Agents: executam tarefas de build/test/deploy

Essa separação permite isolamento e paralelismo de workloads.

Fluxo ponta a ponta (mental model)

1. Pessoa desenvolvedora envia commit
2. Repositório dispara webhook para Jenkins
3. Jenkins enfileira a execução do job
4. Um agent executa build + testes
5. Jenkins publica resultado e artefatos

Esse fluxo evita o "funciona na minha maquina" e transforma feedback em minutos.

flowchart LR
  A[Commit no Git] --> B[Webhook para Jenkins]
  B --> C[Fila de execucao]
  C --> D[Agent executa build e testes]
  D --> E[Publica artefatos e relatorio]
  E --> F[Feedback para time]

Primeiro pipeline

pipeline {
  agent any
  stages {
    stage('Hello Jenkins') {
      steps {
        echo 'Pipeline inicial funcionando'
        sh 'echo "Build host: $(uname -a)"'
      }
    }
  }
}

Diferença entre Entrega e Implantacao Continua

• Entrega Continua: sistema fica sempre pronto para producao, mas deploy final pode ser manual
• Implantacao Continua: aprovou testes e politicas, vai automaticamente para producao

Em equipes iniciantes, o caminho recomendado e comecar em Entrega Continua.

Pratica guiada

1. Criar job do tipo Pipeline
2. Colar o Jenkinsfile da secao anterior
3. Executar manualmente e observar logs
4. Alterar mensagem do echo e executar novamente
5. Comparar tempo e status entre as execucoes

Checklist do dia

• Jenkins instalado e acessível
• Primeiro job executado com sucesso
• Entendimento do fluxo commit -> build -> feedback
• Diferenca entre entrega e implantacao continua compreendida

Day 02 | Jenkins com Docker

Objetivos

• Executar Jenkins com Docker e Docker Compose
• Entender persistência de dados e rede
• Configurar Docker Cloud para criação de agents

Execução rápida

docker run -d \
  --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts

Estrutura recomendada com Compose

Use o docker-compose.yml para padronizar portas, volumes e integrações.

• Volume nomeado para estado do Jenkins
• Rede dedicada para comunicação com serviços auxiliares
• Configuração versionada para replicabilidade

Exemplo minimo de docker-compose.yml:

services:
  jenkins:
    image: jenkins/jenkins:lts
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock

volumes:
  jenkins_home:

Docker Cloud no Jenkins

No painel do Jenkins:

• Manage Jenkins -> Clouds -> New Cloud
• Tipo: Docker
• Docker Host URI: unix:///var/run/docker.sock
• Defina templates com label (ex.: Docker)

Campos importantes no template:

• Docker Image: imagem com Java/Maven/Node conforme seu stack
• Remote File System Root: normalmente /home/jenkins
• Instance Capacity: limite de containers por template
• Pull strategy: evitar pull sempre que imagem for local e controlada

Troubleshooting essencial

docker logs -f jenkins
docker exec -it jenkins bash
docker stats
docker inspect jenkins | head -n 40

Erros comuns:

• permission denied no socket Docker: validar bind de /var/run/docker.sock
• agent nao conecta: revisar label e configuracao de launcher
• perda de configuracao apos restart: validar volume jenkins_home

Checklist do dia

• Jenkins rodando em Docker
• Persistência validada após reinício
• Docker Cloud criado com template funcional
• Template executando ao menos uma pipeline com label Docker

Day 03 | Pipelines Básicos

Objetivos

• Dominar os blocos centrais de um Jenkinsfile
• Integrar pipeline a repositórios Git
• Aplicar ações de pós-build (sucesso/falha)

Anatomia de uma pipeline declarativa

pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Build') {
      steps { sh 'mvn -q -DskipTests package' }
    }
    stage('Tests') {
      steps { sh 'mvn -q test' }
    }
  }
  post {
    success { echo 'Build concluída com sucesso' }
    failure { echo 'Falha na build' }
  }
}

Boas práticas iniciais

• Nomes de stage claros e orientados a resultado
• Falhar cedo com validações de qualidade
• Separar responsabilidades por estágio

Componentes declarativos (resumo)

• agent: define onde a pipeline sera executada
• stages: organiza o fluxo em etapas legiveis
• steps: comandos de execucao da etapa
• post: acoes de encerramento (sucesso, falha, always)

Essa estrutura facilita manutencao e observabilidade.

flowchart TD
  A[Pipeline Start] --> B[agent]
  B --> C[stage Checkout]
  C --> D[stage Build]
  D --> E[stage Tests]
  E --> F{Resultado}
  F -->|sucesso| G[post success]
  F -->|falha| H[post failure]

Integração com Git

• Preferir pipeline como código versionada no repositório
• Garantir gatilho por push/PR conforme fluxo do time
• Padronizar convenção de commits quando possível

Exemplo de gatilho por polling (quando webhook nao esta disponivel):

triggers {
  pollSCM('H/5 * * * *')
}

Se possivel, prefira webhook para reduzir custo de polling.

Exercicio pratico

1. Adicionar etapa Lint
2. Forcar falha controlada em um stage
3. Confirmar execucao do post { failure { ... } }
4. Corrigir falha e validar fluxo de sucesso

Checklist do dia

• Jenkinsfile criada no repositório
• Pipeline executa checkout, build e teste
• Bloco post configurado para feedback
• Gatilho de execucao configurado (webhook ou polling)

Day 04 | Pipelines Intermediários

Objetivos

• Aplicar paralelismo para reduzir tempo total
• Incluir quality gates no fluxo de CI
• Integrar ferramentas de build e análise

Exemplo com stages paralelas

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { sh 'mvn -q -DskipTests package' }
    }
    stage('Tests in Parallel') {
      parallel {
        stage('Unit') {
          steps { sh 'mvn -q test' }
        }
        stage('Static Analysis') {
          steps { sh 'mvn -q -DskipTests verify' }
        }
      }
    }
  }
}

Padrões intermediários

• Consolidar variáveis em environment
• Isolar comandos repetidos em funções/shared libs
• Publicar artefatos e relatórios de forma consistente

Quality gates na pipeline

Boas validacoes para esse nivel:

• Cobertura minima de testes
• Build falha se teste unitario quebrar
• Publicacao de relatorio JUnit
• Regra de nao prosseguir deploy com status instavel

Exemplo de publicacao de testes:

post {
  always {
    junit testResults: '**/target/surefire-reports/*.xml', allowEmptyResults: true
  }
}

Artefatos e rastreabilidade

Publicar artefato da build ajuda em auditoria e rollback:

archiveArtifacts artifacts: 'target/*.war', fingerprint: true

Com fingerprint, voce rastreia o binario entre jobs e ambientes.

Evolucao recomendada

1. Pipeline basica com build e testes
2. Paralelismo para reduzir tempo
3. Quality gates e publicacao de relatorios
4. Extracao de funcoes para shared library

Checklist do dia

• Pipeline com bloco parallel
• Critérios de qualidade explícitos
• Relatórios e artefatos disponíveis no job
• Regras de bloqueio para deploy em caso de falha ativas

Day 05 | Pipelines Avançados

Objetivos

• Configurar Multibranch Pipeline
• Adotar práticas de performance e confiabilidade
• Preparar pipeline para cenários cloud

Multibranch pipeline

A estratégia multibranch permite:

• Descobrir branches automaticamente
• Executar pipelines por branch/PR
• Aumentar velocidade de feedback em revisão de código

Otimização prática

• Reaproveitar cache de dependências
• Evitar workspaces sujos entre builds
• Rodar jobs somente quando necessário (paths/changes)

Versao e release automatica

No fluxo avancado, a pipeline pode inferir tipo de release por convencao de commit:

• feat: incremento MINOR
• fix: incremento PATCH
• ! no commit: incremento MAJOR

Essa estrategia reduz atividade manual e melhora rastreabilidade.

Exemplo com shared library

@Library('jenkins-shared-libs') _

pipeline {
  agent { label 'Docker' }
  stages {
    stage('Validate Commit') {
      steps {
        script { pipelineUtils.validateCommit('^(feat|fix|chore): .+') }
      }
    }
  }
}

Estrategia de deploy progressivo

Sequencia recomendada:

1. Build e testes unitarios
2. Testes de integracao
3. Empacotamento e arquivamento
4. Deploy em ambiente de homologacao
5. Promocao para producao por aprovacao

Mesmo em contexto avancado, priorize rollback facil sobre automacao agressiva.

  flowchart LR
    A[Branch ou PR] --> B[Build]
    B --> C[Testes Unitarios]
    C --> D[Testes Integracao]
    D --> E[Archive Artifact]
    E --> F[Deploy Homologacao]
    F --> G{Aprovacao}
    G -->|sim| H[Deploy Producao]
    G -->|nao| I[Correcoes e novo ciclo]

Checklist do dia

• Job multibranch configurado
• Descoberta de PR/branch ativa
• Boas práticas de performance aplicadas
• Estrategia de versionamento e release definida

Day 06 | Agents Docker

Objetivos

• Criar templates de agents com labels
• Controlar capacidade e recursos dos containers
• Escalar de acordo com demanda de builds

Fluxo de execução com Docker agents

1. Pipeline pede agent { label 'Docker' }
2. Jenkins Cloud provisiona container do template
3. Build roda isolada no container
4. Container é descartado ao final

Configurações-chave do template

• Docker Image adequada ao stack do projeto
• Remote FS Root (ex.: /home/jenkins)
• Instance Capacity e estratégia de uso
• Política de limpeza de volumes

Metodos de conexao comuns:

• Attach Docker container
• SSH launcher
• Inbound agent (JNLP)

Para laboratorios locais, o modo Attach costuma ser o mais direto.

Boas práticas

• Imagens versionadas e pequenas
• Separar templates por stack (java, node, python)
• Aplicar limite de concorrência por tipo de workload

Observabilidade do pool de agents

• Monitore fila de build vs capacidade configurada
• Acompanhe consumo de CPU/memoria por template
• Defina alertas para crescimento anormal de tempo de fila

Com isso, voce evita gargalos silenciosos em horarios de pico.

flowchart LR
	A[Pipeline pede label Docker] --> B[Jenkins Cloud avalia template]
	B --> C[Provisiona container agent]
	C --> D[Executa stages da pipeline]
	D --> E[Publica logs e resultados]
	E --> F[Destroi container]

Troubleshooting rapido

docker ps
docker logs <container-agent>
docker inspect <container-agent> | head -n 40

Sintomas frequentes:

• Job preso em fila: label sem template correspondente
• Agent sobe e cai: imagem sem Java ou comando de entrada invalido
• Workspace inconsistente: politicas de limpeza ausentes

Checklist do dia

• Template Docker funcional por label
• Build rodando em agent efêmero
• Limpeza automática validada
• Painel com fila e capacidade revisado

Day 07 | Segurança e Governança

Objetivos

• Definir controle de acesso por perfil
• Padronizar uso de credenciais e segredos
• Estruturar rotina de backup e atualização

Segurança aplicada

• Ativar autenticação e autorização no Jenkins
• Definir matriz de permissões por função (RBAC)
• Restringir execução de scripts sem controle

Recomendacoes de hardening:

• Forcar HTTPS no acesso ao Jenkins
• Revisar politicas de CSP quando usar descricoes HTML
• Remover usuarios e tokens sem uso

Uso seguro de credenciais

withCredentials([
  usernamePassword(
    credentialsId: 'aws-creds',
    usernameVariable: 'AWS_ACCESS_KEY',
    passwordVariable: 'AWS_SECRET_KEY'
  )
]) {
  sh 'echo "Credenciais injetadas de forma segura"'
}

Operação contínua

• Backup diário de configurações e jobs
• Janela de atualização de plugins com validação em staging
• Rotina de limpeza de workspace e retenção de builds

Politica de atualizacao de plugins

1. Avaliar changelog e dependencia de plugin
2. Testar em ambiente de homologacao
3. Atualizar em janela controlada
4. Monitorar jobs criticos por 24h

Evite atualizar dezenas de plugins em lote sem plano de rollback.

Checklist de governanca mensal

• Revisar matriz de permissoes
• Auditar credenciais e expiracao
• Validar restauracao de backup
• Revisar tempo medio de fila/build
• Limpar jobs obsoletos e artifacts antigos

flowchart TD
  A[Inicio do ciclo mensal] --> B[Auditar permissões RBAC]
  B --> C[Revisar credenciais e expiração]
  C --> D[Testar restauracao de backup]
  D --> E[Revisar plugins e changelogs]
  E --> F[Monitorar fila e performance]
  F --> G[Plano de acao para melhorias]

Checklist final

• RBAC implementado
• Credenciais migradas para Credentials Store
• Política de backup e atualização definida
• Checklist de governança institucionalizado
• Processo mensal de auditoria executado