 |
| Bellacosa Mainframe apresenta Jenkins muito alem do botao build |
☕ Um Café no Bellacosa Mainframe
Jenkins Muito Além do Botão "Build"
O Que Todo Programador COBOL Padawan Precisa Saber Sobre CI/CD, Pipelines, DevOps, Containers, Kubernetes, Git e Como os Grandes Bancos Automatizam Milhões de Transações Todos os Dias
"Compilar um programa é uma tarefa. Automatizar uma empresa inteira é engenharia."
Quando um programador COBOL começa a ouvir falar de Jenkins, normalmente imagina uma ferramenta que "compila programas Java".
Nada poderia estar mais distante da realidade.
Se você trabalha em um banco, seguradora, empresa aérea, governo ou qualquer ambiente IBM Z, provavelmente já faz parte de um processo de CI/CD sem perceber. A diferença é que, durante muitos anos, grande parte dessa automação era construída com ferramentas proprietárias, scripts, JCLs, Control-M, CA-7, Endevor, Changeman, ISPW ou soluções internas.
O Jenkins não substituiu esses conceitos.
Ele apenas modernizou a maneira como pensamos sobre automação.
Neste café vamos muito além do famoso botão Build Now.
Vamos entender por que o Jenkins se tornou um dos pilares da Engenharia de Software moderna e como um Programador COBOL Padawan pode compreender essa tecnologia usando conceitos familiares do mundo Mainframe.
Pegue seu café.
Hoje a conversa será longa.
Antes do Jenkins
Imagine um desenvolvedor em 2005.
Ele terminava uma alteração.
Compilava localmente.
Executava alguns testes.
Gerava um pacote.
Enviava por e-mail.
Outro profissional copiava os arquivos.
Alguém fazia o deploy.
Outro executava os testes.
Outro autorizava produção.
Cada etapa era manual.
Cada etapa demorava.
Cada etapa podia falhar.
Agora imagine isso acontecendo para:
500 sistemas
4.000 desenvolvedores
20 países
milhares de deploys por dia
Seria impossível.
Era necessário automatizar.
Foi exatamente nesse cenário que ferramentas como Jenkins começaram a ganhar importância.
Jenkins não é um compilador
O primeiro erro de quem está aprendendo Jenkins é pensar:
"Jenkins serve para compilar."
Não.
Jenkins serve para orquestrar processos.
Essa diferença muda completamente a maneira de enxergar a ferramenta.
Imagine um maestro.
Ele não toca todos os instrumentos.
Ele coordena músicos.
O Jenkins faz exatamente isso.
Ele conversa com dezenas de ferramentas diferentes.
Pode executar:
Java
COBOL
Python
Node.js
Shell Script
PowerShell
Docker
Kubernetes
Terraform
Ansible
Maven
Gradle
IBM DBB
Zowe CLI
JCL
APIs REST
Ele não faz o trabalho.
Ele manda outras ferramentas fazerem.
Uma analogia para quem conhece Mainframe
Vamos imaginar um Job Batch.
Você escreve um JCL.
STEP001
STEP002
STEP003
STEP004
Cada STEP executa um programa diferente.
No Jenkins acontece exatamente o mesmo.
Só muda o nome.
Em vez de STEP...
temos STAGE.
Checkout
↓
Compile
↓
Test
↓
Package
↓
Deploy
Na prática, Pipeline é um JCL moderno.
Essa comparação ajuda muito quem vem do mundo IBM Z.
Controller e Agent
Outro conceito extremamente importante.
Imagine uma cozinha industrial.
Existe o gerente.
Existem os cozinheiros.
O gerente organiza.
Os cozinheiros executam.
No Jenkins acontece o mesmo.
Controller
É o cérebro.
Ele:
recebe requisições
agenda builds
controla filas
guarda configurações
gerencia plugins
registra logs
Mas ele não compila.
Quem faz isso são os Agents.
Agents
Os Agents são os trabalhadores.
Podem existir centenas deles.
Cada um especializado em uma tecnologia.
Por exemplo:
Agent Linux
Docker
Java
Maven
kubectl
Agent Windows
Visual Studio
MSBuild
Agent IBM Z
IBM DBB
COBOL
Enterprise COBOL
JCL
Zowe CLI
Quando um Pipeline começa, o Controller pergunta:
"Quem sabe fazer este trabalho?"
O Agent responde.
E começa a execução.
Executors
Pouca gente entende essa diferença.
Cada Agent possui Executors.
Imagine um servidor.
Ele possui:
8 CPUs
64 GB de RAM
Pode executar vários builds ao mesmo tempo.
Cada Executor representa uma capacidade de executar um Pipeline.
Se um Agent possui quatro Executors...
ele consegue executar quatro Builds simultaneamente.
É semelhante ao conceito de multitarefa.
O Pipeline é a estrela principal
Pipeline significa fluxo.
Não importa se sua empresa usa Java.
COBOL.
Python.
Go.
Rust.
O conceito é sempre o mesmo.
Existe uma sequência lógica.
Exemplo:
Receber código
↓
Compilar
↓
Executar testes
↓
Executar análise estática
↓
Criar artefato
↓
Construir imagem Docker
↓
Publicar Registry
↓
Atualizar Kubernetes
↓
Executar testes automatizados
↓
Notificar equipe
Tudo isso sem intervenção humana.
Pipeline como Código
Uma das maiores revoluções do Jenkins foi transformar configurações em código.
Antes.
Tudo era configurado clicando na interface.
Problemas:
Ninguém sabia exatamente como aquele Job funcionava.
Não existia histórico.
Não existia revisão.
Não existia versionamento.
Hoje usamos:
Jenkinsfile
Ele fica dentro do Git.
Assim como qualquer programa COBOL.
Isso significa:
histórico
revisão
Pull Request
auditoria
rollback
O próprio Pipeline passa a ser tratado como software.
Declarative Pipeline
É o padrão atual.
Mais simples.
Mais organizado.
Mais fácil de manter.
Ideal para praticamente todas as empresas.
Sua estrutura lembra bastante uma linguagem descritiva.
Cada etapa fica claramente separada.
Isso facilita manutenção, auditoria e leitura.
Scripted Pipeline
Quando o processo fica muito complexo...
usa-se Groovy.
É quase programação completa.
Pode conter:
loops
funções
classes
recursividade
tratamento de exceções
programação dinâmica
É extremamente poderoso.
Mas também exige bastante disciplina para não transformar o Pipeline em um sistema impossível de manter.
Git e Jenkins trabalham juntos
Hoje praticamente todo Pipeline começa da mesma forma.
Um desenvolvedor faz um Commit.
O Git registra a alteração.
O GitHub ou GitLab envia um Webhook.
O Jenkins recebe o evento.
O Pipeline começa automaticamente.
Ninguém precisa clicar em Build.
É tudo automático.
Essa integração é um dos pilares do DevOps moderno.
Poll SCM versus Webhook
No passado.
O Jenkins ficava perguntando:
"Houve alteração?"
"Houve alteração?"
"Houve alteração?"
Isso chamava-se Poll SCM.
Hoje quem avisa é o Git.
Assim que ocorre um Push.
O Git envia um Webhook.
Resultado:
Menor consumo de recursos.
Resposta imediata.
Automação em tempo real.
Docker mudou completamente o CI/CD
Antigamente era comum ouvir:
"Na minha máquina funciona."
Em produção não funcionava.
Dependências diferentes.
Versões diferentes.
Bibliotecas diferentes.
Docker resolveu esse problema.
Agora todo mundo utiliza exatamente o mesmo ambiente.
O Jenkins simplesmente constrói a imagem.
Publica.
Executa.
Sem diferenças.
Kubernetes levou isso para outro nível
Imagine milhares de Builds acontecendo simultaneamente.
Seria inviável manter centenas de servidores dedicados.
Então surgiu a ideia.
Cada Build cria seu próprio ambiente.
Executa.
Depois destrói tudo.
É exatamente isso que Kubernetes faz usando Pods efêmeros.
O Jenkins apenas solicita.
O Kubernetes cria.
Quando termina.
Tudo desaparece.
Resultado:
Mais economia.
Mais isolamento.
Mais escalabilidade.
CI
Continuous Integration.
Significa integrar frequentemente.
Todo Commit dispara:
Compilação.
Testes.
Validações.
Análises.
Assim os erros aparecem rapidamente.
Quanto antes um problema é encontrado.
Mais barato fica corrigi-lo.
CD
Aqui existe uma pequena confusão.
CD pode significar:
Continuous Delivery.
Ou
Continuous Deployment.
Delivery significa que tudo está pronto.
Mas alguém ainda aprova o Deploy.
Deployment significa que nem essa aprovação existe.
Passou nos testes?
Vai para produção automaticamente.
Empresas como Netflix fazem isso milhares de vezes por dia.
Bancos normalmente preferem Continuous Delivery devido às exigências regulatórias.
Shared Libraries
Imagine cem Pipelines.
Todos executam exatamente os mesmos comandos.
Seria absurdo copiar tudo cem vezes.
Para resolver isso surgiram as Shared Libraries.
Você cria funções reutilizáveis.
Como:
BuildJava()
Deploy()
DockerBuild()
RunTests()
Todos os projetos passam a reutilizar o mesmo código.
É o mesmo princípio da reutilização de módulos COBOL.
Credenciais
Jamais escreva:
Senha.
Token.
Chave SSH.
Dentro do Pipeline.
Isso é um dos erros mais graves encontrados em auditorias.
O Jenkins possui um Credentials Store.
Existem também integrações com:
Hashicorp Vault.
AWS Secrets Manager.
Azure Key Vault.
CyberArk.
Tudo criptografado.
Tudo auditável.
Segurança
Grandes bancos tratam Jenkins como infraestrutura crítica.
Não basta instalar.
É necessário proteger.
Algumas práticas:
RBAC.
LDAP.
Active Directory.
Autenticação multifator.
Plugins assinados.
TLS.
Auditoria.
Backups.
Princípio do Menor Privilégio.
Cada equipe enxerga apenas seus projetos.
Cada Pipeline recebe somente as permissões necessárias.
Monitoramento
Jenkins também precisa ser monitorado.
Empresas utilizam:
Prometheus.
Grafana.
Loki.
Elastic Stack.
OpenTelemetry.
As métricas mais importantes incluem:
Tempo médio de Build.
Fila de execução.
Uso de CPU.
Uso de memória.
Tempo de espera.
Falhas por Pipeline.
Taxa de sucesso.
MTTR.
Deploy Frequency.
Essas métricas fazem parte dos famosos DORA Metrics.
Troubleshooting
Talvez seja a habilidade mais importante.
Quando um Build falha.
Nunca comece reiniciando servidores.
Siga uma metodologia.
Primeiro.
Descubra em qual Stage ocorreu a falha.
Depois.
Leia os Logs.
Verifique credenciais.
Verifique DNS.
Verifique certificados.
Verifique armazenamento.
Verifique rede.
Somente depois investigue o código.
Na maioria das vezes o problema nem está no Jenkins.
Está na infraestrutura ao redor.
Performance
Empresas que executam milhares de Builds diariamente investem muito em desempenho.
Algumas técnicas:
Build paralelo.
Cache de dependências.
Cache Docker.
Executores distribuídos.
Agentes especializados.
Pipelines menores.
Stages independentes.
Tudo isso reduz o tempo de entrega.
Jenkins no IBM Z
Aqui chegamos ao ponto que interessa ao Programador COBOL Padawan.
Existe um mito.
"Mainframe não usa DevOps."
Usa.
E muito.
Hoje é perfeitamente possível criar Pipelines para aplicações COBOL.
Imagine um fluxo.
Desenvolvedor altera um programa.
Faz Commit.
O Jenkins recebe o evento.
Executa IBM Dependency Based Build.
Compila COBOL.
Executa testes.
Analisa qualidade.
Submete JCL.
Valida retorno.
Publica relatório.
Promove para homologação.
Tudo automaticamente.
Ferramentas frequentemente utilizadas:
IBM DBB.
Zowe CLI.
Ansible for IBM Z.
UrbanCode Deploy.
Enterprise COBOL.
ZUnit.
COBOL Check.
Git.
GitHub Enterprise.
GitLab.
O conceito é exatamente o mesmo utilizado para aplicações Java.
A única diferença é a tecnologia executada.
O que os grandes bancos realmente fazem?
Em ambientes corporativos o Jenkins raramente trabalha sozinho.
Ele faz parte de um ecossistema muito maior.
GitHub ou GitLab armazenam o código.
SonarQube mede qualidade.
Nexus ou Artifactory armazenam artefatos.
Docker Registry guarda imagens.
Kubernetes executa aplicações.
Vault protege credenciais.
Prometheus coleta métricas.
Grafana cria dashboards.
ServiceNow registra mudanças.
Slack ou Microsoft Teams notificam equipes.
O Jenkins é o maestro dessa orquestra.
Muito além do Build
Quando você compreender Jenkins apenas como um botão que compila programas, estará enxergando apenas a superfície.
Na realidade, ele representa uma mudança de paradigma na Engenharia de Software.
Ele transforma tarefas repetitivas em processos automatizados, documentados, auditáveis e reproduzíveis.
Para quem vem do universo COBOL, o Jenkins não substitui os conhecimentos adquiridos ao longo dos anos. Pelo contrário, aproveita muitos deles.
Pipelines lembram JCLs.
Stages lembram Steps.
Artifacts lembram Load Modules.
Shared Libraries lembram módulos reutilizáveis.
Agents lembram LPARs especializadas.
Executors lembram múltiplas execuções concorrentes.
O pensamento estruturado que sempre caracterizou os profissionais de Mainframe continua extremamente valioso.
A diferença é que agora ele é aplicado em uma plataforma capaz de integrar linguagens, sistemas operacionais, containers, APIs, nuvens públicas, ambientes híbridos e até mesmo aplicações IBM Z.
No fim das contas, Jenkins não é sobre Java, Docker ou Kubernetes.
É sobre transformar conhecimento técnico em processos confiáveis, repetíveis e automatizados.
E essa sempre foi uma das maiores virtudes da informática: fazer com que computadores executem tarefas repetitivas com precisão, enquanto as pessoas se concentram naquilo que realmente exige criatividade, análise e engenharia.
Porque, no mundo moderno, o verdadeiro diferencial não está em saber apertar o botão Build.
Está em entender toda a orquestra invisível que entra em ação depois que esse botão é pressionado.
