 |
| Bellacosa Mainframe apresenta o jenkins para mainframers |
☕ Um Café no Bellacosa Mainframe
Jenkins: O JES2 da Era DevOps que Todo Padawan COBOL Precisa Entender
"Se você já submeteu um JOB no JES2 esperando que tudo desse certo, então já conhece metade da filosofia do Jenkins. A diferença é que, no mundo moderno, quem dispara os jobs não é mais apenas um operador. É um robô extremamente paciente que nunca esquece um passo da esteira."
Existe uma pergunta que praticamente todo programador COBOL faz quando começa a conversar com equipes DevOps:
"Mas afinal... o que exatamente é esse tal de Jenkins?"
A resposta mais simples seria:
Jenkins é um servidor de automação.
Mas essa resposta é tão incompleta quanto dizer que o JES2 "serve apenas para executar jobs".
Na prática, Jenkins é muito mais do que isso.
Para quem vem do universo IBM Z, entender Jenkins fica extremamente fácil quando fazemos as analogias corretas.
Hoje vamos tomar mais um café e descobrir que talvez você já trabalhe com algo muito parecido há décadas...
Antes de existir DevOps...
Durante muito tempo o desenvolvimento Mainframe seguia uma sequência bastante conhecida.
O programador fazia alterações.
Compilava.
Testava.
Gerava Load Module.
Alguém promovia.
Outro aprovava.
Outro copiava bibliotecas.
Outro atualizava o pacote.
Outro executava testes.
Outro validava produção.
Era um processo enorme.
Muito humano.
Muito sujeito a erros.
E principalmente...
Muito lento.
Foi justamente daí que nasceu o conceito de automação de pipelines.
Imagine um operador que nunca dorme
Imagine existir um operador que:
nunca esquece um passo
nunca pula uma etapa
nunca executa fora de ordem
nunca chega atrasado
trabalha 24 horas
registra tudo
avisa quando algo falha
envia e-mails
chama APIs
dispara testes
gera documentação
cria containers
publica versões
Esse operador existe.
Seu nome é Jenkins.
A analogia perfeita para um coboleiro
Pense no seguinte fluxo clássico.
Editar COBOL
↓
Compilar
↓
Link Edit
↓
Executar Teste
↓
Validar RC
↓
Gerar pacote
↓
Mover Load
↓
Atualizar ambiente
↓
Notificar equipe
Agora imagine alguém executando tudo isso automaticamente.
Isso é Jenkins.
O Jenkins é um grande Scheduler?
Sim.
Mas com superpoderes.
Ele lembra um pouco:
JES2
Control-M
CA-7
ESP
IZWS
OPC
TWS
Só que em vez de apenas disparar JOBs...
Ele coordena toda a cadeia de desenvolvimento.
O pipeline é o novo JCL
Para quem programa COBOL existe uma analogia maravilhosa.
Pipeline é praticamente um JCL moderno.
Veja.
No JCL:
STEP010 EXEC PGM=IGYCRCTL
STEP020 EXEC PGM=IEWL
STEP030 EXEC PGM=TESTE
STEP040 EXEC PGM=IEFBR14
Cada STEP possui dependências.
Cada RC determina o próximo passo.
Pipeline faz exatamente isso.
Stage Build
↓
Stage Test
↓
Stage Package
↓
Stage Deploy
↓
Stage Validation
É a mesma filosofia.
Jenkinsfile é praticamente um PROC moderno
Todo pipeline costuma ficar armazenado em um arquivo chamado
Jenkinsfile
Para um padawan...
Pense nele como um PROC extremamente inteligente.
Nele existe:
condições
loops
paralelismo
variáveis
chamadas externas
scripts
Tudo automatizado.
O Build
Uma palavra muito usada.
Build.
O que significa?
No Mainframe:
Compilar
+
Link Edit
+
Gerar Executável
No mundo distribuído:
Build significa exatamente isso.
Produzir algo executável.
O Jenkins compila COBOL?
Sim.
E isso surpreende muita gente.
Hoje é comum encontrar pipelines como:
Git
↓
Jenkins
↓
IBM Dependency Based Build
↓
Compilador Enterprise COBOL
↓
DB2 Bind
↓
Package
↓
Deploy
↓
Testes
↓
Produção
Tudo automático.
Sem intervenção humana.
IBM Dependency Based Build
Conhecido como
DBB.
Ele virou praticamente o "make" oficial do Mainframe.
Com ele o Jenkins entende:
quais programas mudaram
quais COPYBOOKs foram alterados
quais programas dependem deles
quais precisam recompilar
Antes disso...
Era comum recompilar milhares de programas.
Hoje recompila apenas o necessário.
O Git virou a nova PDS?
Não exatamente.
Mas quase.
Antigamente:
PDS
↓
Membro
↓
ISPF Edit
Hoje:
Git Repository
↓
Branch
↓
Commit
↓
Merge
O conceito mudou.
Mas o objetivo continua igual.
Controlar código-fonte.
Onde entra o Docker?
Aqui aparece uma dúvida enorme.
"Mas Docker roda no Mainframe?"
Sim.
E não.
Depende.
Docker não substitui o z/OS
Jamais.
Docker não executa CICS.
Não executa JES2.
Não executa DB2 z/OS.
Não executa IMS.
Não executa RACF.
Então para que serve?
Docker é o laboratório portátil
Imagine um desenvolvedor Java.
Ele precisa:
Maven
Java
Node
Python
Git
Curl
SDKs
Ferramentas IBM
Ao invés de instalar tudo...
Ele usa um Container.
O coboleiro também usa Docker
Aqui vem um dos maiores Easter Eggs do mundo Mainframe.
Muitos desenvolvedores COBOL usam Docker diariamente...
Sem perceber.
Exemplo.
Dentro do container ficam:
Zowe CLI
Git
Groovy
Python
DBB
Ferramentas de Build
utilitários Unix
scripts
O COBOL continua no Mainframe.
Mas todo o ambiente DevOps roda dentro do Container.
Outro Easter Egg
Existe quem imagine:
"Docker executa COBOL."
Na prática...
O que normalmente acontece é:
Docker
↓
Zowe CLI
↓
SSH
↓
z/OSMF
↓
JES
↓
Compilador COBOL
↓
Mainframe
Ou seja...
Docker apenas prepara o ambiente.
Quem executa continua sendo o IBM Z.
Mais um Easter Egg
Muitas empresas possuem dezenas de Jenkins.
Cada um com uma função.
Jenkins DEV
↓
Jenkins QA
↓
Jenkins Produção
↓
Jenkins Infra
Eles conversam entre si.
Jenkins conversa com o Mainframe?
Muito.
Hoje existem plugins para:
z/OSMF
Zowe
SSH
FTP
SFTP
MQ
REST APIs
Tudo integrado.
Pipeline típico COBOL
Imagine um Commit.
Git Push
Automaticamente.
↓
Jenkins detecta alteração
↓
Baixa código
↓
Analisa dependências
↓
Compila COBOL
↓
Executa DBB
↓
Executa testes
↓
Executa SonarQube
↓
Publica resultados
↓
Gera artefatos
↓
Promove ambiente
↓
Notifica Teams
↓
Notifica Slack
↓
Fecha Change
Tudo isso pode levar poucos minutos.
E quando algo falha?
O pipeline para.
Exatamente como um STEP retornando:
RC=12
ABEND S0C7
SQLCODE -904
O Jenkins registra tudo.
Logs.
Tempo.
Erro.
Quem fez.
Qual Commit.
Qual Branch.
Tudo.
A importância dos Logs
Um bom coboleiro aprende cedo:
Nunca ignore o SYSPRINT.
No Jenkins vale exatamente a mesma regra.
Nunca ignore:
Console Output
Ali está praticamente tudo.
Como identificar pipelines ruins?
Alguns sintomas.
Build demora horas
Normalmente existe:
recompilação desnecessária
testes redundantes
scripts lentos
Pipeline enorme
Às vezes um pipeline possui:
5000 linhas
Ninguém entende.
Ninguém mantém.
É igual um JCL gigantesco.
Sem versionamento
Pipeline criado diretamente pela interface.
Erro clássico.
Sempre use:
Jenkinsfile
Versionado no Git.
Sem testes
Pipeline apenas compila.
Não testa.
É praticamente entregar COBOL sem executar.
Como evoluir?
Primeiro passo.
Automatizar.
Depois.
Padronizar.
Depois.
Medir.
Depois.
Melhorar continuamente.
Métricas importantes
Tempo de Build.
Tempo de Deploy.
Quantidade de falhas.
Rollback.
Lead Time.
Change Failure Rate.
São indicadores extremamente importantes.
O Pipeline perfeito existe?
Não.
Porque software muda.
Infra muda.
Ferramentas mudam.
Negócio muda.
Pipeline também precisa evoluir.
Integração entre ambientes
Uma boa esteira normalmente possui.
Developer
↓
Sandbox
↓
Integração
↓
Homologação
↓
Pré-Produção
↓
Produção
Cada ambiente possui regras diferentes.
O Jenkins respeita aprovações?
Sim.
É muito comum existir.
Build
↓
Testes
↓
Aguardando aprovação
↓
Deploy QA
↓
Aguardando CAB
↓
Deploy Produção
Nada acontece sozinho.
Segurança
Aqui mora um perigo enorme.
Nunca coloque:
senhas
tokens
passwords
certificados
Dentro do Jenkinsfile.
Use:
Credentials.
Vault.
Secrets.
O maior erro dos iniciantes
Criar um pipeline que funciona...
Somente na máquina dele.
Isso quebra um dos princípios do DevOps.
Tudo deve ser reproduzível.
Outra armadilha
Scripts gigantes.
Exemplo.
Shell Script
800 linhas
Ninguém mantém isso.
Divida responsabilidades.
Jenkins não faz milagres
Se o processo manual é ruim...
Automatizar apenas cria um desastre mais rápido.
Primeiro melhore o processo.
Depois automatize.
Como um Padawan COBOL deve estudar?
Uma boa sequência seria.
Git
Aprenda commits.
Branches.
Merge.
Pull Request.
Linux básico
Mesmo trabalhando no z/OS.
Você verá muito:
grep
awk
sed
chmod
curl
tar
gzip
Docker
Não precisa virar especialista.
Mas saiba:
criar imagem
executar container
montar volume
entrar no bash
Jenkins
Aprenda:
Pipeline
Stages
Agents
Workspace
Artifacts
Credentials
Groovy
Não precisa dominar.
Mas entender a sintaxe ajuda muito.
Curiosidades
Uma empresa pode executar milhares de pipelines por dia.
Algumas executam dezenas por minuto.
Há pipelines que duram:
20 segundos.
Outros:
8 horas.
Tudo depende da aplicação.
Curiosidade Mainframe
Muitas empresas possuem aplicações COBOL com mais de:
40 milhões de linhas.
Sem automação seria impossível manter tudo isso.
Curiosidade interessante
Um COPYBOOK alterado pode obrigar centenas de programas a recompilar.
É justamente aí que o DBB faz enorme diferença.
Curiosidade divertida
Muitos programadores COBOL nunca abriram a interface do Jenkins.
Eles apenas fazem:
git push
E alguns minutos depois...
Recebem um e-mail dizendo:
✔ Build Success
O lado psicológico
Uma boa esteira reduz ansiedade.
Você não fica imaginando:
"Será que esqueceram de promover?"
"Será que copiaram o Load?"
"Será que executaram o Bind?"
O Jenkins lembra.
Sempre.
Fraquezas do Jenkins
Embora seja extremamente poderoso, o Jenkins também apresenta desafios que um programador Mainframe precisa conhecer.
A primeira fraqueza é a manutenção. Quanto mais pipelines personalizados uma empresa cria, maior se torna o esforço para mantê-los. Um Jenkins mal administrado acaba se transformando em uma coleção de scripts difíceis de entender, semelhante àquela PROC antiga que apenas um analista aposentado sabia alterar.
Outra limitação é a dependência de plugins. O ecossistema do Jenkins é gigantesco, mas isso significa que plugins podem ficar desatualizados, incompatíveis entre si ou apresentar vulnerabilidades de segurança. É fundamental manter uma política de atualização e testes antes de promover novas versões para ambientes produtivos.
Também existe a questão da escalabilidade. Um único servidor Jenkins executando centenas de builds simultâneos pode tornar-se um gargalo. Por isso, grandes organizações costumam distribuir a carga utilizando Agents, que funcionam como "executores remotos" capazes de processar builds em paralelo.
Vantagens para quem trabalha com IBM Z
Para o universo Mainframe, o Jenkins traz benefícios que vão muito além da simples automação:
Elimina tarefas repetitivas.
Reduz erros humanos durante promoções.
Padroniza o processo de compilação.
Garante que todos utilizem as mesmas ferramentas.
Facilita auditorias e conformidade.
Integra facilmente Git, Zowe, DBB, SonarQube e plataformas de colaboração como Teams e Slack.
Produz histórico completo de todas as alterações realizadas.
Isso significa menos tempo resolvendo problemas operacionais e mais tempo escrevendo código COBOL de qualidade.
O futuro do Padawan COBOL
Há alguns anos era comum imaginar que um programador Mainframe viveria apenas dentro do ISPF.
Hoje a realidade é diferente.
O profissional moderno alterna naturalmente entre:
VS Code
Git
Jenkins
Docker
Zowe CLI
APIs REST
Enterprise COBOL
JCL
CICS
DB2
z/OS
Ele continua sendo um especialista em Mainframe, mas agora também compreende como sua aplicação percorre toda a esteira DevOps até chegar à produção.
Conclusão
Existe uma frase bastante conhecida no mundo DevOps:
"Se um processo precisa ser executado duas vezes, ele provavelmente deveria ser automatizado."
No universo IBM Z essa ideia faz ainda mais sentido. Sistemas críticos processam milhões de transações diariamente e não podem depender da memória de uma pessoa para lembrar cada etapa de compilação, teste e implantação.
O Jenkins não substitui o conhecimento do programador COBOL. Ele não escreve regras de negócio, não resolve um S0C7 e não otimiza um SQL ruim. O que ele faz é garantir que todo o caminho entre o commit e a produção seja repetível, rastreável e confiável.
Para o Padawan COBOL, aprender Jenkins é como aprender JCL décadas atrás: no começo parece apenas mais uma ferramenta, mas logo se percebe que ela se torna parte do trabalho diário. E quanto antes você entender como Git, Docker, Zowe, DBB e Jenkins trabalham em conjunto, mais preparado estará para atuar nos ambientes IBM Z modernos.
No fim das contas, o Jenkins é o JES2 da era DevOps: recebe solicitações, organiza a execução, controla dependências, registra tudo o que aconteceu e garante que cada etapa aconteça na ordem correta. A diferença é que, agora, a esteira começa muito antes do JOB chegar ao z/OS e termina muito depois da compilação do COBOL, conectando desenvolvimento, testes, segurança, observabilidade e entrega contínua em um único fluxo automatizado.
E esse é talvez o maior easter egg de todos: muitos dos conceitos considerados "modernos" no DevOps sempre existiram no Mainframe. Apenas ganharam novas ferramentas, novos nomes e uma interface muito mais amigável. O espírito continua o mesmo: processos confiáveis, automação inteligente e qualidade acima de tudo.
