 |
| Bellacosa Mainframe introducao ao DevOps |
☕ Um Café no Bellacosa Mainframe
🎩 CARLITOS EM TEMPOS MODERNOS — QUANDO O COBOL ENTROU NA ESTEIRA DO DEVOPS
COBOL, Git, Jenkins, DBB, zAppBuild, testes, CI/CD, DevSecOps, observabilidade, rollback, IA e o dia em que Carlitos descobriu que apertar parafusos mais rápido não significa necessariamente produzir software melhor.
🎬 PRÓLOGO — CARLITOS CONSEGUIU SEU PRIMEIRO EMPREGO NO MAINFRAME
Imagine nosso jovem programador COBOL entrando pela primeira vez em um grande Data Center.
Ele olha para aquelas máquinas, terminais, aplicações, filas, bancos de dados, milhares de jobs e milhões de transações e pensa:
— Finalmente! Aprendi COBOL. Estou preparado!
Do outro lado da sala, sentado diante de um terminal 3270, está Carlitos.
Chapéu-coco.
Bigodinho.
Bengala encostada na mesa.
Ele olha silenciosamente para o jovem programador e aponta para uma enorme esteira imaginária.
Sobre ela passam:
REQUISITO
↓
COBOL
↓
COPYBOOK
↓
JCL
↓
BUILD
↓
TESTE
↓
DEPLOY
↓
PRODUÇÃO
O jovem pergunta:
— Isso tudo é programação?
Carlitos balança negativamente a cabeça.
Aponta novamente para a esteira.
Agora aparecem mais peças:
Git
Pull Request
Code Review
DBB
zAppBuild
ZUnit
Quality Gate
Security Scan
SIT
UAT
Deploy
Rollback
Logs
Metrics
Traces
O jovem arregala os olhos.
Bem-vindo aos Tempos Modernos do Mainframe.
Porque conhecer COBOL continua sendo extremamente importante.
Mas COBOL é apenas uma das engrenagens.
O profissional mainframe moderno precisa começar a compreender a fábrica inteira.
⚙️ CAPÍTULO 1 — A FÁBRICA DE SOFTWARE
Em Tempos Modernos, Carlitos trabalha em uma linha de produção.
Sua tarefa parece simples:
apertar parafusos.
Dois parafusos chegam.
Carlitos aperta.
Outros dois.
Aperta novamente.
Mais dois.
Mais dois.
Mais dois.
Até que o homem começa a funcionar como se fosse parte da máquina.
Essa é uma excelente metáfora para um problema que também encontramos no desenvolvimento tradicional.
Durante muito tempo ensinamos programação como uma sequência relativamente isolada:
Receba especificação
↓
Altere programa
↓
Compile
↓
Teste
↓
Entregue
Parece perfeitamente razoável.
Mas surge uma pergunta.
Entregue para quem?
Quem controla a versão?
Quem sabe exatamente o que mudou?
Quem verifica as dependências?
Quem recompila?
Quem executa os testes?
Quem gera as evidências?
Quem promove para outro ambiente?
Quem autoriza produção?
Quem observa o sistema depois do deploy?
Quem volta a versão caso algo dê errado?
É nesse momento que entramos no universo do DevOps Mainframe.
DevOps não significa simplesmente instalar Jenkins.
Também não significa substituir ISPF por uma IDE moderna.
Muito menos significa pegar tudo que funciona no mainframe e colocar dentro de containers.
DevOps é fundamentalmente uma abordagem para melhorar o fluxo de entrega de software, aproximando desenvolvimento, testes, segurança e operações através de processos repetíveis, colaboração e automação.
Nossa fábrica começa a ficar interessante.
🏭 CAPÍTULO 2 — O COBOL NÃO SAI SOZINHO DA FÁBRICA
Considere um programa chamado:
PGMPAG01
Ele processa pagamentos.
O programador recebe:
REQ-38271 — Adicionar código identificador da origem da transação.
Parece fácil.
Ele abre o programa:
01 WS-TRANSACAO.
05 WS-VALOR PIC 9(09)V99.
05 WS-CONTA PIC X(12).
05 WS-ORIGEM PIC X(03).
Pronto?
Não.
Talvez WS-ORIGEM tenha vindo de um copybook.
Talvez o programa grave Db2.
Talvez outro programa utilize a mesma estrutura.
Talvez uma transação CICS chame esse programa.
Talvez um batch noturno leia os registros posteriormente.
Talvez exista uma API expondo aquela informação.
Talvez MQ transporte a mensagem para outro sistema.
A pequena alteração tornou-se:
COPYBOOK
│
┌─────────┼─────────┐
▼ ▼ ▼
COBOL-A COBOL-B COBOL-C
│ │
▼ ▼
CICS BATCH
│ │
└────┬────┘
▼
Db2
│
▼
MQ
│
▼
API
Aqui aparece uma das primeiras lições importantes do DevOps:
O tamanho da alteração não determina necessariamente o tamanho do impacto.
Uma linha pode afetar dezenas de componentes.
🌳 CAPÍTULO 3 — CARLITOS CONHECE O GIT
Carlitos encontra outra máquina na fábrica.
Nela existe uma placa:
GIT
O jovem programador pergunta:
— É onde guardamos os fontes?
Sim.
Mas essa resposta é incompleta.
Ensinar Git apenas como repositório é como ensinar CICS dizendo:
“É aquele negócio que executa COBOL.”
Tecnicamente há alguma verdade.
Pedagogicamente é quase inútil.
Git introduz um modelo importante de gerenciamento de mudanças.
Imagine:
main
│
├──── feature/REQ-38271
│
│ ├── alteração COBOL
│ ├── alteração COPYBOOK
│ └── alteração teste
│
└──── fix/INC-9281
O desenvolvedor trabalha em sua alteração.
Depois:
commit
↓
push
↓
Pull Request
↓
Code Review
↓
Merge
Isso cria algo precioso:
rastreabilidade.
Podemos relacionar:
REQUISITO
↓
COMMIT
↓
BUILD
↓
TESTE
↓
ARTEFATO
↓
DEPLOY
Agora conseguimos responder:
Quem alterou?
Quando?
Por quê?
Qual requisito originou a alteração?
Qual versão foi compilada?
Quais testes passaram?
Qual artefato foi enviado para produção?
Esse tipo de informação é extremamente importante em grandes organizações, especialmente em ambientes sujeitos a controles internos, auditorias e regulamentação.
🧬 CAPÍTULO 4 — UMA COPYBOOK PARA A ESTEIRA
Carlitos está trabalhando tranquilamente quando alguém altera:
COPYB
Na fábrica existem:
PGMA → COPYA
→ COPYB
PGMB → COPYB
→ COPYC
PGMC → COPYD
Pergunta:
Quem precisa ser recompilado?
PGMA utiliza COPYB.
PGMB utiliza COPYB.
PGMC não utiliza COPYB.
Logo:
COPYB
/ \
▼ ▼
PGMA PGMB
Esse exemplo aparentemente simples apresenta ao iniciante um conceito extremamente importante:
dependências.
Em sistemas grandes, recompilar absolutamente tudo após qualquer mudança pode ser caro, demorado e desnecessário.
É aí que conceitos como dependency-based build tornam-se interessantes.
Ferramentas e frameworks de build podem ajudar a determinar quais componentes foram impactados pela mudança e quais precisam ser reconstruídos.
Aqui entram tecnologias como DBB e zAppBuild em determinados ecossistemas de desenvolvimento IBM Z.
Não devemos decorar apenas seus nomes.
Precisamos entender o problema que tentam resolver.
🔨 CAPÍTULO 5 — JENKINS NÃO É O OPERÁRIO
Outra máquina aparece.
Na placa está escrito:
JENKINS
O jovem pergunta:
— Jenkins compila COBOL?
Carlitos olha para ele.
Silêncio.
Jenkins é melhor compreendido como um orquestrador.
Imagine um mestre de cerimônias dizendo:
Pegue código
↓
Execute build
↓
Execute testes
↓
Faça análise
↓
Verifique qualidade
↓
Gere artefato
↓
Promova
Jenkins não precisa executar pessoalmente cada tarefa.
Ele coordena ferramentas, agentes, scripts e etapas.
Essa distinção é importantíssima.
O pipeline pode dizer:
STAGE 1 — CHECKOUT
STAGE 2 — BUILD
STAGE 3 — UNIT TEST
STAGE 4 — STATIC ANALYSIS
STAGE 5 — SECURITY
STAGE 6 — PACKAGE
STAGE 7 — DEPLOY DEV
STAGE 8 — INTEGRATION TEST
STAGE 9 — APPROVAL
STAGE 10 — PROD
De repente nossa fábrica ganhou uma linha de montagem automatizada.
Mas existe um perigo.
Automatizar um processo ruim apenas produz resultados ruins mais rapidamente.
🚧 CAPÍTULO 6 — CARLITOS PUXA A ALAVANCA VERMELHA
Imagine:
BUILD
│
▼
TEST
│
▼
SECURITY
│
▼
DEPLOY
Agora imagine que os testes falharam.
O pipeline continua?
Não deveria.
Precisamos de portões:
SOURCE
│
▼
COMPILE ───── ERROR ─────► STOP
│
▼
TEST ──────── ERROR ─────► STOP
│
▼
SECURITY ──── ERROR ─────► STOP
│
▼
QUALITY ───── ERROR ─────► STOP
│
▼
DEPLOY
São os famosos quality gates.
Aqui está uma ideia que todo iniciante deveria guardar:
Pipeline não existe simplesmente para colocar software em produção mais rapidamente. Pipeline também existe para impedir que software inadequado chegue rapidamente à produção.
A automação é simultaneamente acelerador e freio.
🧪 CAPÍTULO 7 — TESTAR NÃO É EXECUTAR E TORCER
Carlitos aperta um botão.
Luz verde.
O jovem comemora:
— Funcionou!
Carlitos entrega outro conjunto de dados.
Luz vermelha.
Esse é outro salto de maturidade.
Testar software não significa executar o cenário que sabemos que funciona.
Precisamos pensar em:
UNIT TEST
│
INTEGRATION TEST
│
SYSTEM TEST
│
REGRESSION TEST
│
ACCEPTANCE TEST
No mainframe isso pode envolver diferentes componentes.
Por exemplo:
COBOL
│
├── lógica isolada
│
├── Db2
│
├── VSAM
│
├── CICS
│
└── MQ
Testar um cálculo isolado é diferente de testar uma transação completa envolvendo banco, mensageria e outros sistemas.
Ferramentas de unit testing como ZUnit podem participar dessa estratégia.
Mas novamente:
ferramenta não é estratégia.
A ferramenta executa o teste.
O engenheiro precisa saber o que deve ser testado.
🛡️ CAPÍTULO 8 — DEVOPS ENCONTRA SEGURANÇA
Em algum momento alguém pergunta:
— E segurança?
Carlitos aponta para uma porta que deveria estar desde o começo da fábrica.
Esse é o espírito do DevSecOps.
Em vez de pensar:
DESENVOLVE
↓
TESTA
↓
ENTREGA
↓
SEGURANÇA OLHA
tentamos aproximar segurança de todo o ciclo:
PLAN
↓
CODE ← SECURITY
↓
BUILD ← SECURITY
↓
TEST ← SECURITY
↓
DEPLOY ← SECURITY
↓
OPERATE ← SECURITY
Podemos verificar código, dependências, configurações, credenciais, permissões e vulnerabilidades durante diferentes etapas.
No mainframe isso conversa muito bem com conceitos tradicionais de controle de acesso, segregação de funções, auditoria e RACF.
DevSecOps não deveria destruir os controles do mainframe.
Deveria ajudar a torná-los mais consistentes, verificáveis e automatizados.
🚚 CAPÍTULO 9 — DEV, SIT, UAT, PRE-PROD E PROD
Agora nossa peça precisa atravessar a fábrica.
DEV
↓
SIT
↓
UAT
↓
PRE-PROD
↓
PROD
Cada ambiente possui uma finalidade.
DEV permite desenvolvimento e testes iniciais.
SIT concentra testes de integração.
UAT permite validação de aceitação conforme o processo da organização.
PRE-PROD tenta aproximar determinadas características da produção.
Finalmente:
PROD.
Mas promover uma aplicação não significa simplesmente copiar um load module.
Pode haver:
LOADLIB
DBRM
PACKAGE
COPYBOOK
JCL
PROC
DB2 CHANGE
CICS RESOURCE
CONFIG
API
É por isso que deployment de aplicações corporativas precisa ser tratado seriamente.
💥 CAPÍTULO 10 — 03:17
Às 03:17, toca o telefone.
Eis nosso pequeno easter egg.
Produção apresentou problema.
Carlitos acorda.
O deploy realizado anteriormente parece estar relacionado.
Alguém grita:
— ROLLBACK!
Parece simples.
Volte a versão.
Mas espere.
A aplicação atualizou 480 mil registros Db2.
Publicou mensagens MQ.
Outro sistema consumiu algumas delas.
Um batch posterior processou parte dos dados.
Agora entendemos algo fundamental:
Rollback não é necessariamente Ctrl+Z.
Existem mudanças reversíveis facilmente.
Outras exigem planejamento.
Podemos ter:
APPLICATION ROLLBACK
DATABASE ROLLBACK
CONFIGURATION ROLLBACK
MESSAGE COMPENSATION
BUSINESS COMPENSATION
Esse conhecimento aproxima o aluno da realidade.
👀 CAPÍTULO 11 — PRODUÇÃO NÃO É O FINAL
A aplicação voltou.
Tudo verde.
Fim?
Não.
Começa outra etapa:
observabilidade.
Precisamos saber o que está acontecendo.
Três conceitos aparecem frequentemente:
METRICS
LOGS
TRACES
Podemos acrescentar eventos e alertas.
O mainframe já possui uma enorme tradição de telemetria e dados operacionais.
O aluno pode encontrar conceitos relacionados a:
SMF
RMF
JES
SDSF
CICS statistics
Db2 statistics
MQ metrics
application logs
e relacioná-los a ecossistemas modernos envolvendo dashboards, APM, Prometheus, Grafana e OpenTelemetry, dependendo da arquitetura adotada.
A grande pergunta deixa de ser:
O programa está rodando?
E passa a ser:
O sistema está se comportando corretamente?
📊 CAPÍTULO 12 — O PROGRAMA ESTÁ VERDE, MAS O CLIENTE ESTÁ VERMELHO
Imagine:
CPU ........ OK
MEMORY ..... OK
CICS ....... OK
DB2 ........ OK
MQ ......... OK
Tudo verde.
Mas pagamentos estão levando 18 segundos.
Tecnicamente diversos componentes podem estar disponíveis.
Do ponto de vista do cliente, porém, existe problema.
Observabilidade precisa aproximar infraestrutura e experiência do negócio.
Podemos acompanhar:
latência
throughput
taxa de erro
tempo de resposta
fila
CPU
I/O
locks
timeouts
transações
e, quando possível, indicadores de negócio.
Esse é um salto enorme para o programador iniciante.
Ele deixa de pensar exclusivamente no programa e começa a pensar no serviço.
🤖 CAPÍTULO 13 — CARLITOS ENCONTRA UM ROBÔ COM IA
Finalmente chega 2026.
A fábrica recebe uma nova máquina:
GENERATIVE AI
O gerente anuncia:
— Agora ela fará tudo!
Carlitos olha desconfiado.
Com razão.
IA pode auxiliar bastante no ciclo de desenvolvimento.
Pode ajudar a:
explicar código legado
documentar programas
sugerir testes
analisar código
resumir mudanças
investigar logs
produzir documentação
auxiliar code review
Imagine um COBOL antigo com milhares de linhas.
Uma ferramenta assistida por IA pode ajudar o desenvolvedor a compreender estruturas e fluxos.
Excelente.
Mas existe uma regra:
AI OUTPUT
↓
HUMAN REVIEW
↓
BUILD
↓
STATIC ANALYSIS
↓
TESTS
↓
SECURITY
↓
APPROVAL
Quanto mais fácil se torna produzir código, maior pode se tornar a necessidade de mecanismos confiáveis para verificar o código produzido.
Portanto existe uma ironia maravilhosa.
IA não elimina DevOps.
Ela pode tornar DevOps ainda mais importante.
🎓 CAPÍTULO 14 — DEVOPS NÃO DEVERIA SER UMA ILHA NA FORMAÇÃO
Aqui chegamos ao ponto central.
Imagine uma pós-graduação organizada assim:
COBOL
JCL
VSAM
DB2
CICS
IMS
MQ
DEVOPS
Parece razoável.
Mas existe um problema pedagógico.
O aluno pode interpretar DevOps como mais uma caixinha.
Eu faria diferente.
DevOps deveria atravessar várias disciplinas.
Aprendeu COBOL?
COBOL + Git + Test
Aprendeu Db2?
Db2 + migration + test + rollback
Aprendeu CICS?
CICS + deploy + observability
Aprendeu MQ?
MQ + integration test + monitoring
Aprendeu API?
API + OpenAPI + pipeline + security
Assim o aluno percebe que DevOps não está no final da estrada.
DevOps é parte da estrada.
🧑🏭 CAPÍTULO 15 — O CODING TANK DE CARLITOS
Eu terminaria essa formação com uma aplicação integradora.
Uma pequena aplicação financeira contendo:
CUSTOMER
ACCOUNT
TRANSACTION
PAYMENT
Tecnologias:
COBOL
JCL
CICS
DB2
VSAM
MQ
API
Então entregaria uma mudança:
Adicionar a origem da transação e disponibilizar a informação para um consumidor externo.
Primeiro o aluno pensa:
— Vou alterar um campo.
Depois descobre:
REQUISITO
↓
ANÁLISE DE IMPACTO
↓
COPYBOOK
↓
COBOL
↓
DB2
↓
CICS
↓
API
↓
GIT
↓
PULL REQUEST
↓
BUILD
↓
UNIT TEST
↓
INTEGRATION TEST
↓
QUALITY GATE
↓
SIT
↓
UAT
↓
APPROVAL
↓
PROD
↓
OBSERVABILITY
Agora COBOL deixou de ser uma disciplina.
Virou parte de um sistema.
🧠 CAPÍTULO 16 — A GRANDE DIFERENÇA ENTRE PROGRAMADOR E ENGENHEIRO
O objetivo não deveria ser abandonar a figura do programador COBOL.
Muito pelo contrário.
Precisamos valorizar profundamente esse conhecimento.
Mas podemos expandi-lo.
O profissional começa sabendo:
MOVE
IF
EVALUATE
PERFORM
CALL
READ
WRITE
Depois compreende:
JCL
VSAM
Db2
CICS
IMS
MQ
E finalmente enxerga:
BUSINESS
│
▼
APPLICATION
│
┌───────────┼───────────┐
▼ ▼ ▼
BATCH ONLINE API
│ │ │
└───────────┼───────────┘
▼
Git
│
▼
CI/CD
│
▼
TESTING
│
▼
SECURITY
│
▼
PROD
│
▼
OBSERVABILITY
Esse profissional começa a se aproximar da ideia de um Mainframe Application Engineer.
Ele não precisa ser especialista em absolutamente tudo.
Isso seria impossível.
Mas precisa entender como as peças conversam.
🎩 EPÍLOGO — CARLITOS SAI DA ESTEIRA
No final de Tempos Modernos, Carlitos percebe que existe algo além daquela fábrica gigantesca.
Nossa metáfora termina de maneira semelhante.
O jovem programador entrou pensando:
Meu trabalho é escrever COBOL.
Depois descobriu:
Meu trabalho é alterar uma aplicação.
Mais tarde percebeu:
Meu trabalho é entregar uma mudança segura.
Finalmente compreendeu:
Meu trabalho faz parte da entrega contínua de um serviço de negócio.
Essa evolução muda completamente a maneira como ensinamos mainframe.
COBOL continua essencial.
JCL continua essencial.
CICS, IMS, Db2, VSAM e MQ continuam essenciais.
Mas precisamos construir as pontes:
LEGADO
│
▼
Git
│
▼
AUTOMAÇÃO
│
▼
TESTES
│
▼
SEGURANÇA
│
▼
CI/CD
│
▼
PRODUÇÃO
│
▼
OBSERVABILIDADE
É por isso que DevOps precisa ganhar muito mais espaço na formação mainframe em 2026.
Não porque Git seja moderno.
Não porque Jenkins seja moderno.
Não porque pipeline seja moderno.
Mas porque o próprio trabalho mudou.
A empresa não precisa apenas de alguém capaz de apertar perfeitamente o parafuso que passa diante dele na esteira.
Ela precisa de profissionais capazes de olhar para as engrenagens e perguntar:
De onde veio esta peça?
Quem a modificou?
Como sabemos que funciona?
Como sabemos que é segura?
Quem autorizou sua passagem?
Como sabemos exatamente o que entrou em produção?
Como descobriremos que existe um problema?
E como voltaremos com segurança se algo der errado?
Carlitos pega sua bengala.
Olha uma última vez para a fábrica.
Em algum lugar, um pipeline fica vermelho.
O relógio marca discretamente:
03:17.
O jovem programador olha desesperado para ele:
— Carlitos! O que fazemos agora?
Ele aponta para o dashboard.
Depois para os logs.
Depois para o último commit.
Depois para o pipeline.
Finalmente aponta para o rollback documentado.
E sorri.
Porque finalmente o jovem entendeu.
Mainframe DevOps não é fazer o COBOL correr mais rápido pela esteira.
É construir uma esteira na qual saibamos o que entrou, quem colocou, por que entrou, como foi testado, como chegou até ali, como está funcionando e como retirá-lo caso alguma engrenagem comece a triturar Carlitos outra vez.
☕ Um Café no Bellacosa Mainframe
Porque até em Tempos Modernos alguém precisa descobrir quem fez deploy direto em produção.
