 |
| Bellacosa Mainframe apresenta CI/CD na Stack Mainframe |
☕ Um Café no Bellacosa Mainframe
Continuous Integration e Continuous Delivery (CI/CD): O Pipeline Invisível que Transformou o Mainframe sem Pedir Permissão ao COBOL
"Você pode passar vinte anos escrevendo COBOL sem nunca criar um pipeline CI/CD. Mas dificilmente trabalhará em uma empresa moderna sem que algum pipeline execute o seu programa diversas vezes antes de chegar à produção."
Existe uma cena que acontece diariamente em centenas de bancos, seguradoras e grandes empresas.
O programador termina um programa COBOL.
Compila.
Resolve alguns erros.
Faz o BIND.
Executa testes.
Entrega para homologação.
Dias depois alguém pergunta:
— "Já passou pelo pipeline?"
O programador COBOL mais experiente responde naturalmente.
O padawan pergunta:
— "Pipeline? Eu só alterei três linhas..."
E aí começa a descoberta de um dos maiores conceitos da engenharia de software moderna.
O que é CI/CD?
CI/CD significa:
Continuous Integration
Continuous Delivery (ou Continuous Deployment)
Não é uma ferramenta.
Não é Docker.
Não é Jenkins.
Não é Git.
Não é GitHub.
Não é Azure DevOps.
CI/CD é uma filosofia de trabalho.
É uma maneira de entregar software continuamente com segurança.
Se antigamente uma equipe entregava uma versão a cada seis meses, hoje algumas empresas fazem dezenas ou centenas de implantações por dia.
E sim...
Isso também acontece em ambientes IBM Z.
O problema antigo
Imagine um banco em 1998.
Existem:
600 programas COBOL
180 JCLs
90 CICS
dezenas de COPYBOOKS
centenas de PROC
milhares de datasets
João altera um COPYBOOK.
Maria altera um programa.
Carlos modifica outro programa.
Pedro altera um JCL.
Na sexta-feira tudo é colocado em produção.
Ninguém sabe exatamente:
quem alterou o quê
qual versão entrou
quem compilou
qual compilador foi usado
quais módulos dependem daquele COPYBOOK
Resultado?
ABEND.
A integração contínua nasceu para resolver isso
A ideia é simples.
Sempre que alguém altera código...
o sistema automaticamente:
baixa o código
compila
executa testes
verifica qualidade
mede cobertura
procura vulnerabilidades
gera relatórios
cria pacotes
disponibiliza para homologação
Sem intervenção humana.
Pense como um Batch
O coboleiro entende isso rapidamente.
Imagine um JOB.
STEP010 - COMPILA
↓
STEP020 - LINKEDIT
↓
STEP030 - BIND
↓
STEP040 - TESTES
↓
STEP050 - GERA PACOTE
↓
STEP060 - ENVIA QA
↓
STEP070 - AGUARDA APROVAÇÃO
↓
STEP080 - PRODUÇÃO
Isso...
é praticamente um pipeline CI/CD.
A diferença é que hoje tudo pode ser disparado automaticamente por um simples:
git push
Continuous Integration
O nome já explica.
Toda alteração feita pelos desenvolvedores é integrada continuamente ao projeto principal.
Ao invés de esperar um mês...
integra-se várias vezes ao dia.
Isso reduz conflitos gigantes.
O maior inimigo do COBOL não é o compilador
É isto.
Dois programadores alterando o mesmo COPYBOOK.
Imagine:
CLIENTE.cpy
José altera:
01 CLIENTE.
05 CPF.
Maria altera:
01 CLIENTE.
05 EMAIL.
Carlos altera:
01 CLIENTE.
05 SCORE.
Quem vence?
Antes...
quem compilava por último.
Hoje...
Git resolve conflitos.
Pipeline verifica impacto.
Testes garantem funcionamento.
Continuous Delivery
Depois que tudo foi integrado...
vem a entrega.
O software fica pronto para produção.
Observe a diferença.
Continuous Integration
↓
Integra constantemente.
Continuous Delivery
↓
Entrega constantemente.
Continuous Deployment
↓
Entrega automaticamente em produção.
Nem todo banco permite Deployment automático.
Mas Delivery...
cada vez mais.
O pipeline invisível
Imagine uma esteira.
Programador
↓
Git
↓
Pipeline
↓
Compilação
↓
Testes
↓
Qualidade
↓
Empacotamento
↓
Homologação
↓
Produção
O desenvolvedor apenas envia código.
Todo o resto acontece sozinho.
Onde entra o Docker?
Aqui existe um mito enorme.
Muitos imaginam:
"Mainframe usa Docker."
Na maioria dos casos...
não.
O IBM Z executa z/OS.
Docker normalmente roda em Linux.
Mas isso não significa que eles não trabalhem juntos.
Na verdade...
trabalham diariamente.
O Docker do Coboleiro
Imagine que você possui uma aplicação composta por:
Frontend React
↓
API Java
↓
Kafka
↓
Redis
↓
PostgreSQL
↓
Mainframe
Toda essa parte distribuída pode rodar em Docker.
Enquanto isso...
o COBOL continua rodando no z/OS.
O pipeline moderno
Git
↓
Docker
↓
Compila Java
↓
Executa Testes
↓
Sobe Banco
↓
Executa APIs
↓
Integra com Mainframe
↓
Executa Testes End-to-End
↓
Entrega
O COBOL faz parte da cadeia.
Mesmo sem estar dentro do container.
Easter Egg para Coboleiros
Docker lembra muito...
JCL PROC.
Pense nisso.
Uma PROC define um ambiente reutilizável.
Docker Image também.
PROC:
IEFBR14
SORT
IDCAMS
IKJEFT01
Docker Image:
Ubuntu
Python
Java
Node
Maven
Nos dois casos...
alguém preparou um ambiente padrão.
Você apenas reutiliza.
Outro Easter Egg
Um Container é quase como um JOB temporário.
Ele nasce.
Executa.
Produz resultado.
Morre.
Exatamente como milhares de jobs batch.
E mais um...
Imagem Docker lembra LOADLIB.
Você cria uma imagem.
Depois apenas executa.
Muito parecido com um módulo compilado.
Como um coboleiro trabalha hoje?
Imagine o dia.
8:00
Atualiza Git.
git pull
8:15
Altera COBOL.
9:10
Executa testes locais.
9:20
Commit.
git commit
9:21
Push.
git push
Nesse instante...
o pipeline começa.
Sem perguntar nada.
O pipeline executa
checkout
download
compilação
COBOL Check
SonarQube
testes
ZUnit
quality gate
geração de pacote
upload
Tudo automático.
Enquanto isso...
O desenvolvedor toma café.
Ambientes
Uma empresa normalmente possui:
DEV
↓
SIT
↓
QA
↓
UAT
↓
PRE-PROD
↓
PROD
Cada ambiente possui:
Db2
CICS
MQ
datasets
usuários
certificados
APIs
filas
Tudo diferente.
O pipeline controla isso.
O maior erro dos iniciantes
Achar que DEV é igual PROD.
Nunca é.
Produção possui:
volume
segurança
criptografia
RACF
WLM
políticas
auditoria
SMF
monitoramento
O pipeline reduz erros humanos
Antes alguém precisava:
copiar módulos
alterar datasets
trocar parâmetros
executar binds
atualizar packages
Hoje...
scripts fazem isso.
Muito menos erro.
Como identificar que sua empresa precisa evoluir?
Existem alguns sinais.
Compilação manual
Ainda existe alguém clicando em dezenas de telas.
Pode automatizar.
Testes manuais
Tudo depende de pessoas.
Pode automatizar.
Deploy manual
Alguém copia LOADLIB.
Pode automatizar.
Sem Git
Problema sério.
Sem versionamento
Outro problema.
Sem rollback
Problema gravíssimo.
Como evoluir?
Não tente implantar tudo.
Comece pequeno.
Primeiro:
Git.
Depois:
Build automático.
Depois:
Testes.
Depois:
Qualidade.
Depois:
Deploy.
Depois:
Observabilidade.
Ferramentas comuns
No mundo distribuído:
GitHub
GitLab
Jenkins
Azure DevOps
GitHub Actions
Bamboo
TeamCity
No mundo IBM Z:
IBM Dependency Based Build (DBB)
UrbanCode Deploy
IBM Developer for z/OS
Zowe CLI
z/OSMF
IBM Wazi
IBM Test Accelerator
IBM Application Delivery Foundation
Cada uma resolve uma parte do quebra-cabeça.
Docker no dia a dia do coboleiro
Mesmo que você nunca execute um container...
provavelmente usa algo que foi criado por ele.
Exemplos:
VS Code Dev Container.
SonarQube.
Jenkins.
Nexus.
Artifactory.
Mongo.
Redis.
RabbitMQ.
Kafka.
Prometheus.
Grafana.
Tudo frequentemente hospedado em containers.
O pipeline conversa com o Mainframe
Hoje isso acontece usando:
SSH
FTP seguro
SFTP
Zowe CLI
REST APIs
z/OSMF
MQ
Connect:Direct
Ansible
Ou seja...
o pipeline não precisa morar no z/OS.
Ele apenas conversa com ele.
Os perigos
Automação ruim acelera erros.
Existe uma frase famosa.
"Se você automatizar um processo ruim, apenas conseguirá errar muito mais rápido."
Um pipeline mal configurado pode:
apagar datasets
publicar versão errada
executar BIND incorreto
substituir módulos
gerar indisponibilidade
Automação exige governança.
Fraquezas
CI/CD não resolve:
má arquitetura.
código ruim.
COPYBOOK gigante.
programa de 70 mil linhas.
GOTO infinito.
IF aninhado em vinte níveis.
Tudo isso continua existindo.
Apenas chega mais rápido à homologação.
As vantagens
São enormes.
Menos erro humano.
Mais rastreabilidade.
Rollback simples.
Auditoria.
Histórico.
Segurança.
Qualidade.
Velocidade.
Repetibilidade.
Padronização.
Confiança.
Curiosidades
Os bancos mais modernos executam milhares de pipelines por dia.
Alguns pipelines levam poucos minutos.
Outros...
compilam milhares de programas COBOL.
Há pipelines que analisam impacto em centenas de COPYBOOKS antes mesmo da compilação.
Outros verificam automaticamente se um programa alterou SQL estático e disparam o BIND apenas quando necessário.
Em muitas instituições, uma alteração em um COPYBOOK crítico dispara uma análise de dependências para descobrir todos os programas afetados, permitindo recompilar somente o necessário em vez de reconstruir toda a aplicação.
Também é comum que o pipeline consulte políticas de segurança: se um desenvolvedor tentar promover um módulo diretamente para produção sem as aprovações exigidas, a entrega é bloqueada automaticamente.
CI/CD e a mentalidade do Padawan
O maior aprendizado para quem está começando não é decorar nomes de ferramentas.
É entender que o código deixou de ser um arquivo isolado. Ele faz parte de um ecossistema.
Quando você altera uma linha em um programa COBOL, essa mudança pode disparar:
validação de sintaxe;
análise de qualidade;
execução de testes unitários;
testes de integração;
análise de impacto em COPYBOOKs;
geração de métricas;
publicação de artefatos;
implantação em ambientes de teste.
Você continua escrevendo COBOL, mas agora trabalha em uma cadeia de entrega muito maior.
Uma analogia para nunca esquecer
Imagine uma fábrica de automóveis.
O programador COBOL fabrica uma peça do motor.
O CI/CD é a esteira de montagem.
Ele verifica se a peça está correta, mede suas dimensões, confirma a compatibilidade com as demais peças, registra quem a produziu, armazena o histórico e só então permite que ela siga para a próxima etapa.
Sem essa esteira, cada carro dependeria de verificações totalmente manuais.
Com ela, a produção ganha velocidade, qualidade e previsibilidade.
No mundo IBM Z acontece exatamente a mesma coisa.
O COBOL continua sendo o coração do processamento de negócios. O JCL continua orquestrando cargas batch. O CICS continua atendendo milhões de transações. O Db2 continua armazenando dados críticos. O que mudou foi a forma de construir, validar e entregar essas aplicações.
No fim das contas, o CI/CD não substitui o conhecimento do coboleiro. Pelo contrário: ele amplia seu alcance. O profissional que entende Git, pipelines, testes automatizados, Docker (mesmo que apenas como parte da infraestrutura), Zowe, automação de builds e integração entre ambientes torna-se capaz de participar de projetos modernos sem abandonar a robustez do mainframe.
E talvez esse seja o maior segredo do IBM Z em 2026: o mainframe não ficou preso ao passado. Ele incorporou práticas modernas de engenharia de software e continua evoluindo. O padawan que aprende essa mentalidade deixa de ser apenas um programador COBOL e passa a enxergar toda a jornada do software — desde o primeiro git push até o momento em que um módulo é promovido para produção com segurança, rastreabilidade e confiança. Afinal, no universo Bellacosa Mainframe, escrever código é apenas o começo; entregar software de forma consistente é o verdadeiro diferencial.
Sem comentários:
Enviar um comentário