 |
| Bellacosa Mainframe CI/CD no Mainframe |
☕ Um Café no Bellacosa Mainframe
CI/CD no Mainframe: Como um Programador COBOL Pode Entrar na Era da Entrega Contínua Sem Esquecer Tudo o que Aprendeu
"O problema nunca foi o COBOL. O problema sempre foi imaginar que um processo criado há 40 anos precisa continuar igual para sempre."
Durante décadas, o desenvolvimento em IBM Mainframe seguiu um ritual quase sagrado.
O programador alterava um programa COBOL.
Executava alguns testes.
Enviava o fonte para uma biblioteca de homologação.
Alguém fazia uma revisão.
Outro profissional gerava o package.
Outro realizava o BIND.
Outro submetia o JOB.
Dias depois, talvez semanas, aquela alteração finalmente chegava à produção.
Esse modelo funcionou.
Aliás...
Ele continua funcionando em milhares de empresas.
Mas o mercado mudou.
Hoje bancos digitais publicam dezenas de versões por dia.
Fintechs liberam pequenas correções continuamente.
Empresas querem reduzir riscos fazendo pequenas entregas em vez de grandes implantações trimestrais.
É justamente aí que entra o CI/CD.
E não...
CI/CD não significa abandonar o Mainframe.
Significa modernizar a maneira de trabalhar com ele.
Antes de tudo: o que significa CI/CD?
CI significa Continuous Integration.
CD significa Continuous Delivery ou Continuous Deployment.
São conceitos diferentes.
Continuous Integration
É a prática de integrar alterações ao repositório principal várias vezes ao dia.
Em vez de esperar uma semana para juntar o trabalho de dez programadores, cada alteração pequena é integrada rapidamente.
Isso reduz conflitos.
Reduz retrabalho.
Reduz surpresas.
Continuous Delivery
Depois que o código foi integrado, ele já está preparado para ser implantado.
Existe uma "linha de montagem".
Cada etapa acontece automaticamente.
Por exemplo:
compilação
geração de DBRM
BIND
testes
análise de qualidade
empacotamento
aprovação
implantação
Tudo acontece de forma repetível.
Continuous Deployment
Vai além.
Após todos os testes serem aprovados, a implantação ocorre automaticamente.
Nem todas as empresas permitem isso no Mainframe.
E tudo bem.
Em ambientes bancários, normalmente existe uma aprovação humana antes da produção.
Como nasceu o CI/CD?
Nos anos 90, os projetos começaram a ficar enormes.
Cada desenvolvedor trabalhava isoladamente.
Quando chegava a hora de integrar tudo...
Era um verdadeiro pesadelo.
Esse problema ficou conhecido como Integration Hell.
Martin Fowler e outros especialistas passaram a defender integrações frequentes.
Mais tarde, o movimento Agile fortaleceu essa ideia.
Depois veio o DevOps.
E finalmente surgiram pipelines automatizados.
Hoje praticamente toda aplicação moderna utiliza CI/CD.
Inclusive aplicações que executam em IBM Z.
"Mas Mainframe sempre teve automação..."
Essa é uma observação extremamente interessante.
Muito antes de existir Jenkins...
Muito antes de existir GitHub Actions...
Muito antes de existir Azure DevOps...
O Mainframe já possuía automação.
Pense em:
JCL
PROCs
Scheduler
CA-7
Control-M
IBM Workload Scheduler
REXX
CLIST
Na prática...
O Mainframe já automatizava tarefas quando muitos servidores ainda nem existiam.
O que mudou foi a filosofia.
Antes automatizávamos jobs.
Hoje automatizamos todo o ciclo de desenvolvimento.
Essa diferença muda completamente a produtividade.
O velho processo
Imagine um desenvolvedor COBOL.
Ele altera:
CLIENTE01.CBL
Depois precisa:
compilar
gerar load
atualizar DBRM
fazer BIND
solicitar implantação
enviar documentação
abrir chamado
esperar aprovação
Cada etapa depende de uma pessoa.
Cada pessoa gera espera.
Cada espera aumenta o tempo.
Cada demora aumenta o custo.
O processo moderno
Agora imagine outra empresa.
O desenvolvedor apenas faz:
git commit
git push
O restante acontece sozinho.
Pipeline:
↓
Compila COBOL
↓
Executa testes
↓
Executa análise estática
↓
Compila DB2
↓
Gera Package
↓
Executa BIND
↓
Publica artefatos
↓
Implanta homologação
↓
Notifica equipe
↓
Solicita aprovação
↓
Produção
O programador continua escrevendo COBOL.
Quem mudou foi o processo.
O Git substitui o Endevor?
Essa é uma das perguntas mais comuns.
Resposta curta:
Depende.
Muitas empresas continuam usando:
Endevor
Changeman
ISPW
Outras utilizam Git integrado.
Algumas usam ambos.
Hoje existem integrações excelentes entre Git e ambientes z/OS.
O importante não é abandonar uma ferramenta.
É automatizar o fluxo.
Como funciona uma pipeline Mainframe?
Uma pipeline normalmente possui etapas bem definidas.
Etapa 1
Receber alteração.
git push
Etapa 2
Executar compilação.
COBOL.
PLI.
Assembler.
Easytrieve.
Natural.
Etapa 3
Executar análise de qualidade.
Exemplo:
variáveis não utilizadas
SQL incorreto
COPY duplicado
warnings
complexidade
Etapa 4
Executar testes.
Hoje existem ferramentas como:
zUnit
IBM Test Accelerator
Micro Focus Unit Test
Etapa 5
Gerar artefatos.
LOAD MODULE
DBRM
Package
Objetos
Etapa 6
Implantar automaticamente.
Dependendo da empresa:
Desenvolvimento
Integração
Homologação
Produção
O que muda para um programador COBOL?
Muita coisa.
Mas não na linguagem.
Na forma de trabalhar.
Antes:
"Funcionou na minha LPAR."
Agora:
"O pipeline precisa aprovar."
Antes:
"O compilador aceitou."
Agora:
"Todos os testes precisam passar."
Antes:
"Eu testei."
Agora:
"O teste automatizado comprovou."
Essa mudança cultural é enorme.
O programador passa a escrever testes
Isso assusta muitos profissionais.
Mas pense da seguinte forma.
Se você altera um cálculo de juros.
Como garante que não quebrou o restante?
Criando testes.
Os testes viram documentação viva.
E principalmente...
Protegem seu código daqui a cinco anos.
Qualidade deixa de ser opcional
Em muitas empresas modernas:
Código com warning...
Não passa.
Cobertura baixa...
Não passa.
Duplicação elevada...
Não passa.
Complexidade excessiva...
Não passa.
O pipeline torna-se um fiscal automático.
O papel do JCL muda?
Não.
Na verdade...
Ele ganha ainda mais importância.
Toda pipeline Mainframe executa JCL.
Compilação.
Link-edit.
BIND.
RUN.
Utility.
IDCAMS.
SORT.
Tudo continua passando pelo bom e velho JCL.
A diferença é que ele agora faz parte de um fluxo automatizado.
Ferramentas comuns
Hoje encontramos diversas soluções.
IBM Dependency Based Build (DBB)
Permite construir aplicações Mainframe utilizando Git e pipelines modernas.
Jenkins
Muito usado para orquestrar pipelines.
GitHub Actions
Integra facilmente repositórios Git.
GitLab CI
Muito utilizado em ambientes híbridos.
Azure DevOps
Cada vez mais presente em grandes empresas.
UrbanCode Deploy
Muito forte para implantação empresarial.
Ansible
Automação de infraestrutura.
Inclusive para IBM Z.
O que exige atenção?
Nem tudo são flores.
Alguns cuidados são fundamentais.
Dependências
Um programa COBOL pode utilizar dezenas de COPYBOOKS.
Uma alteração em COPY pode impactar centenas de programas.
A pipeline precisa descobrir essas dependências.
Ordem de compilação
No mundo distribuído isso costuma ser simples.
No Mainframe nem sempre.
Existem:
COPY
DBRM
BMS
Mapsets
PSB
DBD
Macros
Assembler
Tudo possui ordem correta.
Segurança
Automatizar não significa liberar tudo.
Pipelines precisam utilizar:
RACF
certificados
tokens
controle de acesso
segregação de funções
auditoria
Aprovação
Nem toda implantação deve ser automática.
Em ambientes regulados:
bancos
seguros
governo
saúde
geralmente existe aprovação humana.
Os riscos
Automação ruim automatiza erros.
Se o pipeline estiver incorreto...
O erro será reproduzido centenas de vezes.
Outro risco:
Implantar rapidamente código mal testado.
Velocidade sem qualidade é perigosa.
CI/CD não elimina responsabilidade.
Ele aumenta a responsabilidade.
Um erro clássico
Um desenvolvedor altera um COPYBOOK.
Compila apenas seu programa.
Tudo funciona.
Produção falha.
Por quê?
Porque outros 700 programas dependiam daquele COPY.
Uma pipeline moderna detecta esse impacto automaticamente.
Outro erro clássico
"Vamos automatizar tudo."
Sem documentação.
Sem padronização.
Sem versionamento.
Resultado?
Caos automatizado.
Automação precisa nascer de processos bem definidos.
A evolução do papel do programador
Há vinte anos.
O programador escrevia código.
Hoje ele precisa compreender:
Git
Branches
Merge
Pipeline
Testes
Qualidade
Observabilidade
Versionamento
Entrega
Automação
Isso não significa virar DevOps.
Significa entender o ciclo completo.
Curiosidades
Pouca gente sabe, mas muitos bancos já executam pipelines modernas para COBOL.
Algumas empresas realizam centenas de compilações automáticas diariamente.
Existem ambientes em que um simples Pull Request dispara:
compilação COBOL
geração de DBRM
testes
análise de qualidade
implantação automática em ambiente de integração
Tudo em poucos minutos.
Algo que antigamente podia consumir vários dias.
CI/CD elimina o analista de produção?
Não.
Ele muda de função.
Em vez de executar tarefas repetitivas.
Passa a administrar pipelines.
Governança.
Qualidade.
Segurança.
Métricas.
Automação.
Seu trabalho torna-se mais estratégico.
Vantagens
Os ganhos são enormes.
Menos erros humanos.
Entregas menores e mais seguras.
Feedback quase imediato.
Redução do retrabalho.
Maior rastreabilidade.
Auditoria facilitada.
Padronização dos processos.
Menor tempo entre desenvolvimento e produção.
Melhor qualidade do software.
Maior confiança nas implantações.
E as desvantagens?
Também existem.
Curva de aprendizado.
Mudança cultural.
Investimento inicial.
Necessidade de testes automatizados.
Dependência de boas práticas.
Necessidade de revisão das esteiras existentes.
Empresas que tentam implantar CI/CD apenas comprando ferramentas normalmente fracassam.
O sucesso está na mudança de cultura.
O futuro
A próxima evolução já começou.
Pipelines inteligentes.
IA revisando código COBOL.
Agentes analisando impacto.
Testes sendo gerados automaticamente.
Análise de risco baseada em Machine Learning.
Deploy assistido por Inteligência Artificial.
Tudo isso já está chegando ao IBM Z.
O programador que entender CI/CD hoje estará muito mais preparado para trabalhar com essas tecnologias amanhã.
Conclusão
Durante muito tempo acreditou-se que modernizar o Mainframe significava substituir COBOL.
A realidade mostrou exatamente o contrário.
Os maiores bancos, seguradoras e empresas do mundo continuam confiando no IBM Z para executar suas cargas mais críticas. O que mudou não foi a robustez da plataforma, mas a forma como desenvolvemos, testamos e entregamos software.
CI/CD não é uma moda importada do mundo distribuído. É a evolução natural da automação que o próprio Mainframe sempre cultivou. A diferença é que agora automatizamos toda a jornada do desenvolvimento, desde o primeiro commit até a implantação em produção, com rastreabilidade, testes, segurança e governança.
Para o Programador COBOL Padawan, a maior transformação não está em aprender uma nova linguagem, mas em adotar uma nova mentalidade. Continuará escrevendo PROCEDURE DIVISION, manipulando VSAM, DB2, CICS e JCL, porém trabalhando em equipes colaborativas, utilizando Git, pipelines, testes automatizados e revisão contínua de código.
No fim das contas, o COBOL continua sendo o motor. O CI/CD passa a ser a esteira inteligente que garante que esse motor seja atualizado com segurança, rapidez e qualidade.
Porque no universo do IBM Mainframe, o futuro não pertence a quem escreve mais linhas de código.
Pertence a quem consegue entregar valor ao negócio com confiança, repetibilidade e excelência.
E essa é, talvez, a maior evolução que um verdadeiro Padawan pode aprender.
