 |
| Bellacosa Mainframe apresenta o jenkins |
☕ Um Café no Bellacosa Mainframe
Jenkins Muito Além do Botão "Build"
O Que Todo Programador COBOL Padawan Precisa Saber Sobre CI/CD, DevOps, Pipelines, Git, Automação, IBM Z e Como o Jenkins se Tornou o Maestro da Engenharia de Software Moderna
"Compilar um programa é uma tarefa. Automatizar uma empresa inteira é engenharia."
Introdução
Se você começou recentemente sua jornada no universo IBM Mainframe, provavelmente já ouviu alguém dizer algo parecido com:
"Faz um build no Jenkins."
Parece algo simples.
Você altera um programa COBOL.
Faz um git push.
Alguns minutos depois alguém informa:
"O pipeline ficou verde."
Ou então...
"O Jenkins quebrou."
Para quem está começando, tudo isso parece mágica.
Existe um servidor.
Existe um robô.
Existe um botão chamado Build Now.
E, aparentemente, tudo acontece sozinho.
Mas o Jenkins está muito longe de ser apenas um servidor que compila programas.
Na realidade, ele é um dos pilares que sustentam praticamente toda a engenharia moderna de software.
Se o Git organiza o código-fonte, o Jenkins organiza todo o trabalho realizado sobre esse código.
Neste artigo vamos muito além dos conceitos básicos. Vamos entender como o Jenkins nasceu, por que ele revolucionou a indústria, como funciona sua arquitetura, por que ele continua relevante mesmo na era do Kubernetes, GitHub Actions e Inteligência Artificial, e como tudo isso conversa perfeitamente com o universo IBM Z, COBOL, CICS, DB2 e z/OS.
Pegue seu café.
Hoje vamos conversar sobre um dos softwares mais importantes da história da Engenharia de Software.
Antes do Jenkins: a era da integração manual
Imagine um banco em 1998.
A equipe possui:
80 programadores COBOL
20 analistas
dezenas de aplicações
centenas de programas
Cada desenvolvedor trabalha em sua própria máquina.
Ao final da semana...
Todos entregam seus programas.
Alguém precisa reunir tudo.
Compilar.
Executar testes.
Gerar executáveis.
Mover bibliotecas.
Executar JCLs.
Atualizar CICS.
Publicar em produção.
Tudo manualmente.
Agora imagine o caos.
João alterou o Programa A.
Maria alterou o Programa B.
Carlos modificou um COPY utilizado por ambos.
Quando tudo é compilado junto...
Nada funciona.
Esse problema ficou conhecido como Integration Hell.
Quanto maior a equipe...
Maior o problema.
Era necessário encontrar uma solução.
O nascimento da Integração Contínua
Foi aí que surgiu uma ideia simples.
Ao invés de integrar o código apenas no final do projeto...
Por que não integrar continuamente?
Sempre que alguém fizer uma alteração:
Assim nasceu a Continuous Integration (CI).
A integração contínua não é uma ferramenta.
É uma filosofia.
O Jenkins tornou essa filosofia prática.
O que realmente é o Jenkins?
Muita gente responde:
"É uma ferramenta de Build."
Na verdade, isso é apenas uma pequena parte.
O Jenkins é um servidor de automação.
Ele automatiza praticamente qualquer tarefa repetitiva.
Pode:
Ou seja...
O Jenkins não entende apenas de software.
Ele entende de processos.
Pense no Jenkins como um maestro
Imagine uma orquestra.
Cada músico conhece apenas seu instrumento.
O maestro coordena todos.
O Jenkins faz exatamente isso.
Ele não precisa saber programar Java.
Nem COBOL.
Nem Python.
Ele apenas coordena.
Git
↓
Compilar
↓
Testar
↓
Analisar qualidade
↓
Criar artefatos
↓
Publicar
↓
Implantar
↓
Monitorar
Cada ferramenta executa sua especialidade.
O Jenkins organiza a sequência.
O Pipeline: a esteira de produção do software
Uma fábrica produz automóveis.
O software moderno produz versões.
Imagine uma linha de montagem.
Chassi
↓
Motor
↓
Pintura
↓
Inspeção
↓
Entrega
Agora substitua por desenvolvimento.
Código
↓
Build
↓
Testes
↓
Qualidade
↓
Deploy
↓
Monitoramento
Esse fluxo recebe o nome de Pipeline.
Pipeline significa literalmente:
tubulação.
Cada etapa entrega seu resultado para a próxima.
Se uma etapa falhar...
Nada continua.
O primeiro passo: Git
Tudo começa no Git.
O desenvolvedor altera um programa COBOL.
CLIENTE.CBL
Executa:
git add .
git commit
git push
Nesse instante acontece algo extremamente importante.
O Git envia um evento.
Esse evento dispara um Webhook.
WebHooks: quem avisa quem?
Um erro comum é imaginar que o Jenkins fica perguntando ao Git:
Mudou?
Mudou?
Mudou?
Isso existia.
Chamava-se Poll SCM.
Hoje o modelo mais moderno é o WebHook.
O GitHub avisa imediatamente:
Recebi um commit.
Pode iniciar o Pipeline.
É mais rápido.
Mais eficiente.
Mais escalável.
Build: muito além de compilar
No universo Java, Build normalmente significa:
.java
↓
.class
↓
.jar
No universo COBOL isso muda bastante.
Um Build pode incluir:
compilação COBOL
Link-Edit
geração do Load Module
pré-compilação DB2
BIND
geração de mapas CICS
cópia para bibliotecas
atualização de catálogos
Observe que "Build" não é apenas traduzir código.
É transformar código-fonte em algo executável.
Testes: por que eles são indispensáveis?
Imagine um caixa eletrônico.
Você altera apenas uma linha.
Sem testes.
Na segunda-feira...
Nenhum saque funciona.
Por isso o Pipeline executa testes automaticamente.
Existem vários níveis.
Unit Test
Integration Test
Component Test
Smoke Test
Regression Test
Performance Test
Security Test
Acceptance Test
No universo IBM Z encontramos ferramentas como:
SonarQube: o inspetor de qualidade
Compilar não significa qualidade.
Um programa pode compilar perfeitamente e ainda assim possuir:
Ferramentas como SonarQube analisam tudo isso.
Se a qualidade estiver abaixo do padrão...
O Jenkins interrompe o Pipeline.
Continuous Delivery e Continuous Deployment
Esses conceitos costumam gerar confusão.
Continuous Delivery
Tudo acontece automaticamente.
Mas existe aprovação humana antes da produção.
Build
↓
Testes
↓
Deploy QA
↓
Aprovação
↓
Produção
É o modelo predominante em bancos.
Continuous Deployment
Não existe aprovação manual.
Passou em todos os testes?
Vai automaticamente para produção.
Empresas como Netflix, Spotify e Amazon utilizam amplamente essa estratégia para muitos de seus serviços.
Jenkinsfile: Pipeline como Código
Antigamente configurávamos tudo pela interface gráfica.
Hoje utilizamos Pipeline as Code.
Arquivo:
Jenkinsfile
Exemplo simplificado:
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
}
stage('Deploy') {
steps {
sh './deploy.sh'
}
}
}
}
Esse arquivo também fica versionado no Git.
O Pipeline passa a fazer parte do projeto.
Parametrização: um Pipeline para vários cenários
Imagine quatro ambientes:
Você poderia criar quatro pipelines.
Ou criar apenas um.
Na execução o Jenkins pergunta:
Qual ambiente?
DEV
QA
HML
PRD
Isso é parametrização.
Também podemos solicitar:
número da versão
branch
Change Request
arquivo de entrada
descrição da implantação
Um único Pipeline atende dezenas de cenários.
Cron: automação baseada em tempo
Nem todo Build depende de commits.
Às vezes queremos executar tarefas periodicamente.
Por exemplo:
O Jenkins utiliza a sintaxe CRON.
Exemplo:
0 2 * * *
Executa diariamente às duas da manhã.
Outro detalhe interessante é o uso da letra H, exclusiva do Jenkins.
Ela distribui automaticamente os horários dos Jobs, evitando que centenas de pipelines iniciem exatamente no mesmo minuto.
Controller e Agents
As versões antigas utilizavam os termos Master e Slave.
Hoje a nomenclatura oficial é:
O Controller coordena.
Os Agents trabalham.
Imagine um restaurante.
O gerente organiza os pedidos.
Os cozinheiros preparam os pratos.
O gerente não cozinha.
Da mesma forma, o Controller distribui tarefas para diversos Agents.
Por que vários Agents?
Suponha três Builds de 30 minutos.
Sem Agents:
Build A
↓
Build B
↓
Build C
Tempo total:
90 minutos.
Com três Agents:
Todos executam simultaneamente.
Tempo aproximado:
30 minutos.
Essa é a base da escalabilidade.
Labels: enviando o trabalho para a máquina certa
Nem todos os servidores possuem as mesmas ferramentas.
Podemos ter:
Linux
Windows
Docker
Kubernetes
IBM Z
Java
.NET
COBOL
Os Labels funcionam como etiquetas.
linux
docker
java
ibmz
cobol
Quando o Pipeline precisa compilar COBOL:
agent {
label 'ibmz'
}
O Jenkins envia automaticamente o trabalho ao Agent correto.
Credenciais: segurança em primeiro lugar
Jamais coloque senhas dentro do Jenkinsfile.
O Jenkins possui um cofre chamado Credentials Store.
Nele podemos armazenar:
usuários
senhas
tokens GitHub
chaves SSH
certificados
chaves privadas
O Pipeline acessa essas informações de forma segura, sem expô-las no código.
Workspaces
Cada execução recebe um diretório exclusivo.
Nele ficam:
código baixado do Git
arquivos temporários
artefatos
logs
resultados de testes
Ao final da execução o Workspace pode ser limpo automaticamente.
Isso evita conflitos entre Builds.
Plugins: o verdadeiro poder do Jenkins
O Jenkins possui milhares de plugins.
Entre os mais conhecidos estão:
Git
GitHub
Docker
Kubernetes
SonarQube
Slack
Teams
Ansible
Terraform
Artifactory
Nexus
Blue Ocean
Pipeline Utility Steps
Essa arquitetura modular explica sua enorme popularidade.
Jenkins e Containers
Hoje muitos Builds acontecem dentro de containers Docker.
Cada execução recebe um ambiente completamente limpo.
Terminou?
O container é destruído.
Isso elimina problemas do tipo:
"Na minha máquina funciona."
Jenkins e Kubernetes
A evolução natural foi integrar o Jenkins ao Kubernetes.
Quando um Build começa:
um Pod é criado;
o Pipeline executa;
o Pod é removido.
O ambiente sempre inicia do zero.
É altamente escalável.
Jenkins no IBM Mainframe
Aqui começa a parte que mais interessa ao Programador COBOL Padawan.
Muitas pessoas acreditam que Jenkins serve apenas para aplicações Java.
Nada poderia estar mais distante da realidade.
Hoje o Jenkins integra perfeitamente o universo IBM Z.
Um Pipeline moderno pode executar:
Git Push
↓
Webhook
↓
Jenkins
↓
Zowe CLI
↓
Upload do Programa COBOL
↓
Compilação
↓
Link-Edit
↓
DB2 BIND
↓
Execução do ZUnit
↓
Análise SonarQube
↓
Deploy para CICS
↓
Smoke Test
↓
Atualização do Endevor
↓
Notificação
Perceba.
O Jenkins não substitui o Mainframe.
Ele conversa com o Mainframe.
DevOps não elimina o Mainframe
Existe um mito de que DevOps pertence apenas ao mundo Linux.
Na realidade, DevOps é uma cultura.
Ela pode ser aplicada em qualquer plataforma.
Inclusive no IBM Z.
Hoje encontramos pipelines automatizando:
COBOL
PL/I
Assembler
JCL
DB2
IMS
CICS
MQ
z/OS Connect
Tudo integrado ao GitHub, GitLab e Azure DevOps.
Inteligência Artificial e Jenkins
Estamos entrando em uma nova fase.
Os modelos de IA auxiliam na geração de código, revisão automática, documentação e testes.
Mas alguém ainda precisa orquestrar todo o processo.
É aí que o Jenkins continua relevante.
Imagine um Pipeline moderno:
Commit
↓
IA revisa Pull Request
↓
Build
↓
Testes
↓
SonarQube
↓
Análise de Segurança
↓
Deploy
↓
Observabilidade
↓
Feedback para IA
A automação não desaparece.
Ela apenas incorpora novas ferramentas.
Conclusão
Quando começamos a estudar Jenkins, é comum enxergá-lo apenas como uma tela com um botão chamado Build Now.
Depois descobrimos os Pipelines.
Mais tarde aprendemos sobre WebHooks, Agents, Labels, Credenciais, Containers, Kubernetes e DevOps.
Finalmente percebemos algo muito maior.
O Jenkins não é apenas uma ferramenta.
Ele é uma plataforma de orquestração da engenharia de software.
Para um Programador COBOL Padawan, compreender esse ecossistema significa deixar de pensar apenas na compilação de programas e começar a enxergar o ciclo completo de vida das aplicações.
O futuro do IBM Mainframe não está em competir com as tecnologias modernas, mas em integrá-las. Git, Jenkins, Zowe CLI, Ansible, APIs REST, testes automatizados, observabilidade e Inteligência Artificial já fazem parte da realidade dos ambientes corporativos que executam aplicações críticas sobre IBM Z.
Dominar Jenkins é compreender que escrever código é apenas o começo. A verdadeira engenharia acontece quando conseguimos transformar esse código em software confiável, testado, rastreável, seguro e entregue continuamente aos usuários. E é justamente nesse ponto que o Jenkins deixa de ser um simples servidor de Build para se tornar o maestro que coordena toda a sinfonia da entrega contínua, conectando o legado robusto do Mainframe às práticas mais modernas da Engenharia de Software.
