 |
| Bellacosa Mainframe e ci/cd sem misterios |
☕ Um Café no Bellacosa Mainframe
CI/CD sem Mistérios
O Guia do Programador COBOL Padawan para Entender por que o Mainframe Faz DevOps Há Décadas (Mesmo Antes de Chamarem Assim)
Existe uma frase muito comum quando alguém começa a estudar DevOps:
"CI/CD revolucionou a forma de desenvolver software."
Ela não está errada.
Mas para quem trabalha com IBM Z, CICS, Db2, COBOL, IMS e JCL, existe uma observação divertida:
"Revolucionou para quem nunca trabalhou com mainframe."
E aqui está um dos maiores easter eggs da computação.
Durante décadas, enquanto boa parte do mundo compilava programas diretamente no servidor de produção usando FTP e um editor de texto, o universo mainframe já possuía ambientes separados, aprovação, promoção de código, controle de versões internos, rollback, auditoria e pipelines extremamente rígidos.
Não recebiam o nome de DevOps.
Mas faziam praticamente a mesma coisa.
O que significa CI/CD?
CI significa
Continuous Integration
(Integração Contínua)
CD possui dois significados.
Primeiro:
Continuous Delivery
(Entrega Contínua)
Depois:
Continuous Deployment
(Implantação Contínua)
Por isso muita gente escreve
CI/CD
para representar todo o fluxo.
 |
| Bellacosa Mainframe e o ciclo Ci/Cd |
A ideia parece moderna...
...mas é muito antiga.
A origem vem da necessidade de resolver um enorme problema dos anos 70, 80 e 90.
Imagine uma empresa com:
300 desenvolvedores
milhares de programas
centenas de alterações diárias
Cada programador alterava arquivos diferentes.
No final da semana alguém tentava juntar tudo.
Resultado?
Era praticamente inevitável aparecerem conflitos, regressões e erros de integração.
Nascia então a necessidade de integrar continuamente.
O problema que existia
Imagine cinco programadores.
João altera cálculo de juros.
Maria altera cadastro.
Carlos altera emissão.
Pedro altera impostos.
Ana altera relatórios.
Todos trabalham separados durante um mês.
Na hora de juntar tudo...
Começa o caos.
Isso era chamado de:
Integration Hell
Ou
Inferno da Integração.
CI nasceu justamente para evitar isso.
O objetivo do CI
Ao invés de integrar tudo no final...
Integra-se o tempo inteiro.
Cada alteração dispara automaticamente:
compilação
testes
validações
análise estática
geração de artefatos
Se algo quebra...
Descobre-se em minutos.
Não em semanas.
Delivery
Continuous Delivery responde outra pergunta.
Depois que compilou...
Como levar até produção?
Sem copiar arquivos manualmente.
Sem esquecer datasets.
Sem esquecer um BIND.
Sem esquecer um módulo.
Tudo passa a ser automatizado.
Deployment
Continuous Deployment vai além.
Se tudo passou...
O sistema entra automaticamente em produção.
Sem intervenção humana.
Este modelo é muito comum em empresas digitais.
No mundo bancário, normalmente utiliza-se Continuous Delivery com aprovação humana antes da promoção para produção, por exigências regulatórias e de governança.
Onde surgiu?
As raízes aparecem ainda nas práticas de integração de software dos anos 1980 e foram consolidadas com métodos como Extreme Programming (XP) na década de 1990. Em 2006, Martin Fowler popularizou o conceito de Continuous Integration, e a partir da década de 2010, com a ascensão do DevOps, CI/CD tornou-se um padrão amplamente adotado.
Curiosamente...
O mainframe já fazia muitas dessas práticas décadas antes.
O Easter Egg do IBM Z
Imagine um desenvolvedor COBOL em 1988.
Ele faz:
Editar
↓
Compilar
↓
Link
↓
Teste
↓
Homologação
↓
Produção
Agora veja um pipeline GitHub.
Commit
↓
Compile
↓
Test
↓
Package
↓
Deploy QA
↓
Deploy PROD
São praticamente a mesma filosofia.
A diferença está na automação e nas ferramentas.
O ciclo clássico do Mainframe
Durante muitos anos, um fluxo típico era:
Desenvolvimento
↓
Teste Unitário
↓
Integração
↓
Homologação
↓
Produção
Cada ambiente possuía:
bibliotecas próprias
datasets próprios
Db2 próprio
CICS próprio
IMS próprio
Nada era compartilhado.
O programador Padawan pensa...
"Mas isso já não é CI/CD?"
Na essência...
Sim.
A maior diferença é:
antes boa parte das promoções dependia de pessoas.
Hoje dependem de pipelines.
Como funcionava antigamente?
Um fluxo clássico podia ser:
Programador
↓
Compila
↓
Entrega ao líder
↓
Líder aprova
↓
Equipe de mudança
↓
Equipe de produção
↓
Operadores
↓
Implantação
Cada etapa envolvia documentos.
Telefonemas.
Assinaturas.
Mudanças em papel.
Mudanças aprovadas em CAB (Change Advisory Board).
Tudo extremamente controlado.
As equipes antigamente
Era comum existir:
Programadores
↓
Analistas
↓
QA
↓
DBA
↓
Operadores
↓
Produção
↓
Sysprog
↓
Storage
↓
Segurança
↓
Change Management
Cada equipe era responsável apenas por sua parte.
Esse modelo ficou conhecido como "silos".
Hoje
O objetivo do DevOps não é eliminar especialistas.
É fazê-los trabalhar juntos.
Em vez de jogar o problema para o próximo grupo.
Todos compartilham responsabilidade.
O pipeline moderno
Hoje um commit pode executar automaticamente:
Git
↓
Build
↓
Compile COBOL
↓
IBM COBOL Check
↓
Testes ZUnit
↓
Code Review
↓
Quality Gate
↓
DBB/zBuilder
↓
Empacotamento
↓
Deploy DEV
↓
Deploy QA
↓
Deploy UAT
↓
Deploy Produção
Tudo registrado.
Tudo auditável.
Tudo reproduzível.
O grande objetivo
Reduzir risco.
Não aumentar velocidade.
Velocidade é consequência.
O verdadeiro objetivo é:
Confiabilidade.
Comparando com Waterfall
Waterfall
Grande planejamento.
↓
Grande desenvolvimento.
↓
Grande teste.
↓
Grande implantação.
Tudo ocorre em blocos.
Mudanças são caras.
Feedback demora.
Agile
Entrega pequena.
↓
Feedback rápido.
↓
Correções rápidas.
↓
Novos ciclos.
O cliente participa continuamente.
Onde entra o CI/CD?
O Agile responde:
Como organizar o trabalho?
CI/CD responde:
Como entregar software com segurança e repetibilidade?
São complementares.
Waterfall sem CI/CD
Planejar
↓
Desenvolver
↓
Meses depois integrar
↓
Torcer
Agile sem CI/CD
Sprint
↓
Entrega
↓
Implantação manual
↓
Muito retrabalho
Agile + CI/CD
Sprint
↓
Commit
↓
Pipeline
↓
Testes
↓
Deploy
↓
Feedback
É essa combinação que caracteriza a maior parte das organizações modernas.
O Mainframe já fazia isso?
Muito mais do que muita gente imagina.
Ferramentas como:
Endevor
Changeman ZMF
ISPW
Librarian
Panvalet
já implementavam conceitos de:
versionamento
promoção
rollback
aprovação
auditoria
segregação de ambientes
Décadas antes do GitHub existir.
O pipeline "invisível"
Um pipeline moderno apenas automatiza etapas que o mainframe tradicional já conhecia:
Editar COBOL
↓
Compile
↓
DBRM
↓
BIND PACKAGE
↓
BIND PLAN
↓
Link Edit
↓
Load Library
↓
Deploy
↓
Smoke Test
↓
Produção
Hoje isso pode ser disparado por um único commit.
Os requisitos para um verdadeiro CI/CD
Não basta instalar Jenkins.
É necessário:
Controle de versão (Git ou equivalente).
Build automatizado (DBB/zBuilder, Maven, Gradle etc.).
Testes automatizados (ZUnit, JUnit...).
Análise estática (IBM COBOL Check, SonarQube...).
Pipeline (Jenkins, GitHub Actions, GitLab CI...).
Promoção automatizada entre ambientes.
Rollback.
Auditoria.
Observabilidade.
Aprovação quando exigida por compliance.
Sem esses elementos, há automação parcial, mas não um pipeline maduro.
É hype?
Hoje, não.
Há alguns anos, "DevOps" virou uma buzzword usada para vender ferramentas e consultorias. Porém, CI/CD deixou de ser moda para se tornar uma prática consolidada de engenharia de software.
O hype passou.
A necessidade permaneceu.
É uma buzzword?
Depende do contexto.
Quando alguém diz:
"Nossa empresa faz DevOps."
Mas:
não existe automação;
não há testes automáticos;
tudo é manual;
produção depende de copiar arquivos;
rollback não existe;
Então virou apenas uma buzzword.
Quando existe pipeline, testes, rastreabilidade, observabilidade e governança, CI/CD deixa de ser discurso e vira prática.
O maior mito
Muitos acreditam:
"CI/CD serve para entregar software mais rápido."
Na verdade...
Serve para entregar software com menos risco.
A velocidade aparece porque há menos retrabalho, menos erros humanos e mais confiança no processo.
Curiosidades
NASA, bancos, companhias aéreas e bolsas de valores utilizam pipelines altamente controlados, muitas vezes exigindo aprovações humanas mesmo com automação.
O IBM Z integra-se hoje com Git, Jenkins, GitHub Actions, Azure DevOps, Ansible, Zowe, DBB/zBuilder, UrbanCode Deploy e outras ferramentas modernas.
Em ambientes regulados, é comum usar Continuous Delivery, mas não Continuous Deployment, porque uma etapa de aprovação humana continua sendo obrigatória.
Easter Eggs para o Padawan COBOL
🥚 Endevor fazia "pipeline" antes do pipeline existir.
🥚 Promotion Levels do ISPW lembram muito os estágios (stages) de um pipeline moderno.
🥚 O DBRM pode ser visto como um "artefato de build", equivalente ao que linguagens modernas geram antes da implantação.
🥚 O BIND PACKAGE é, em muitos aspectos, semelhante a uma etapa especializada de empacotamento e configuração dentro de um pipeline.
🥚 O JCL sempre foi uma forma declarativa de orquestração de tarefas em lote, décadas antes de arquivos YAML de pipelines se tornarem populares.
A Grande Lição para um Padawan COBOL
Quando você ouvir alguém dizer:
"DevOps e CI/CD chegaram para substituir o mainframe."
Sorria.
Depois explique que o IBM Z já separava ambientes, promovia código entre níveis, exigia aprovações, mantinha auditoria, fazia rollback e garantia rastreabilidade muito antes dessas práticas receberem os nomes que conhecemos hoje.
O que mudou não foi a filosofia.
Mudaram as ferramentas, o grau de automação e a integração entre equipes.
No fim das contas, CI/CD não é uma tecnologia nem uma moda passageira. É a evolução natural de uma ideia simples: tornar a entrega de software repetível, segura, auditável e previsível. E, para quem vive no universo COBOL e IBM Z, essa história soa surpreendentemente familiar. Afinal, o mainframe sempre ensinou que colocar código em produção é um processo de engenharia — nunca um ato de improviso.
Sem comentários:
Enviar um comentário