 |
| Bellacosa Mainframe ci cd em devops sem misterios |
☕ Um Café no Bellacosa Mainframe
DevOps sem Mistérios para Programadores COBOL
Como entender CI/CD, Containers, Kubernetes, IaC e DevOps usando exemplos do IBM Z
"Um programador COBOL experiente descobre rapidamente que DevOps não substitui o Mainframe. Ele apenas automatiza aquilo que os grandes bancos já faziam há muitos anos."
Antes de tudo...
Imagine um banco.
Todos os dias existem milhares de programas COBOL sendo alterados.
Imagine fazer isso manualmente.
Editar.
Compilar.
Gerar Load Module.
Fazer BIND.
Atualizar CICS.
Liberar produção.
Executar testes.
Se cada desenvolvedor fizesse isso do seu jeito...
...o banco pararia em poucas horas.
Foi exatamente para resolver esse problema que nasceu o DevOps.
Não para Cloud.
Não para Containers.
Mas para organizar o desenvolvimento.
1 — CI/CD
A imagem mostra:
Código
↓
Build
↓
Testes
↓
Deploy
Parece moderno.
Mas vamos traduzir.
No Mainframe seria algo parecido com:
Editar COBOL
↓
Compile
↓
Link Edit
↓
BIND DB2
↓
Newcopy CICS
↓
Testes
↓
Produção
Percebe?
É praticamente igual.
A diferença é que hoje tudo isso acontece automaticamente.
O que significa CI?
Continuous Integration.
Integração Contínua.
Na prática:
Em vez de esperar um mês para juntar alterações...
...cada alteração é integrada imediatamente.
Imagine cinco programadores.
Cada um altera um programa.
Antigamente:
João altera.
Maria altera.
José altera.
Carlos altera.
Tudo junta sexta-feira.
Sexta-feira...
Nada compila.
Ninguém sabe quem quebrou.
Hoje:
Commit
↓
Compile automático
↓
Teste automático
↓
Se falhar...
ninguém faz Merge.
Muito mais seguro.
No Mainframe
Imagine ISPW.
Imagine Endevor.
Imagine Changeman.
Quando você promove um componente...
Já existe uma pipeline.
Hoje ela apenas ficou mais inteligente.
2 — Container
Essa talvez seja a palavra mais mal compreendida.
Todo mundo fala:
"Container."
Mas...
O que é?
Imagine que você escreveu um programa COBOL.
Ele precisa:
Enterprise COBOL
LE Runtime
Db2 Client
MQ
Bibliotecas
Configuração
Certificados
Se você copiar apenas o executável...
Não funciona.
O Container resolve exatamente isso.
Ele empacota tudo.
Programa
+
Bibliotecas
+
Dependências
+
Configuração
+
Runtime
Tudo vira um único pacote.
Analogia Mainframe
Imagine um LOADLIB completo.
Ou uma STEPLIB preparada.
Você leva exatamente o ambiente necessário.
O Container faz isso para Linux.
Por que isso é importante?
Porque elimina:
"Na minha máquina funciona."
Essa frase praticamente desaparece.
3 — Kubernetes
A imagem chama Kubernetes de controlador de tráfego.
Gostei dessa definição.
Imagine um banco.
Existem:
Servidor A
Servidor B
Servidor C
Servidor D
Se um servidor morrer?
Quem percebe?
Quem cria outro?
Quem redistribui usuários?
Quem balanceia carga?
No mundo Cloud:
Kubernetes.
No Mainframe...
Quem faz isso?
Vários componentes.
WLM.
Sysplex.
Coupling Facility.
Dynamic Routing do CICS.
VIPA.
Parallel Sysplex.
Na prática...
IBM resolveu isso muito antes.
Só usou outros nomes.
O Kubernetes faz:
escala
reinicia
monitora
distribui
atualiza
Tudo sozinho.
4 — Infrastructure as Code (IaC)
Essa talvez seja a maior revolução.
Imagine instalar um servidor manualmente.
Clique.
Clique.
Clique.
Próximo.
Avançar.
OK.
Agora imagine repetir isso cem vezes.
Impossível.
Então surgiu:
Infrastructure as Code.
Em vez de clicar...
Você escreve.
Exemplo simplificado:
Servidor:
Linux
8 CPUs
32 GB
Porta 443
Firewall ativo
Rede privada
Pronto.
Um script cria tudo.
No mundo IBM Z
Isso lembra muito:
JCL.
Pense nisso.
JCL descreve infraestrutura.
Quero executar
este programa
com esta memória
este dataset
esta região
estas bibliotecas
Na essência...
JCL já era Infrastructure as Code.
Décadas antes do termo existir.
5 — Pipeline
Pipeline é uma linha de produção.
Literalmente.
A imagem mostra:
Código
↓
Build
↓
Teste
↓
Scan
↓
Deploy
No banco isso pode virar:
Developer
↓
Git
↓
Compile COBOL
↓
Compile Copybooks
↓
SQL Precompiler
↓
DBRM
↓
Bind
↓
Unit Test
↓
SonarQube
↓
Deploy QA
↓
Deploy Homologação
↓
Deploy Produção
Tudo automático.
Ferramentas comuns
GitHub Actions
GitLab CI
Azure DevOps
Jenkins
Tekton
ArgoCD
UrbanCode Deploy
ISPW
Endevor
6 — Monitoring
Depois que o sistema entra em produção...
Acabou?
Muito pelo contrário.
Começa o trabalho.
Monitoramento significa responder perguntas como:
CPU está alta?
Memória?
Tempo de resposta?
Fila MQ?
Db2?
CICS?
VSAM?
JES2?
SMF?
No IBM Z
Você já conhece muitos monitores.
RMF
OMEGAMON
SMF
SDSF
NetView
Tivoli
Z APM
Instana
Todos fazem exatamente isso.
Sem monitoramento...
Você só descobre o problema quando o cliente liga.
7 — Configuration Management
Esse conceito nasceu porque administradores faziam mudanças manualmente.
Servidor 1:
Java 17
Servidor 2:
Java 11
Servidor 3:
Java 21
Resultado?
Caos.
Ferramentas como:
Ansible
Chef
Puppet
SaltStack
garantem que todos fiquem iguais.
Analogia Mainframe
Pense em PROCLIB.
PARMLIB.
IEASYSxx.
JES2PARM.
RACF.
Tudo precisa permanecer consistente.
A diferença é que hoje isso é automatizado.
8 — CI/CD novamente
A oitava imagem aprofunda o assunto.
Vale destacar uma diferença importante.
Continuous Integration
Sempre compila.
Sempre testa.
Sempre valida.
Mas nem sempre publica.
Continuous Delivery
Tudo pronto.
Apenas alguém aperta:
Deploy.
Continuous Deployment
Nem isso.
Terminou os testes?
Produção automaticamente.
Bancos normalmente fazem:
CI
+
Continuous Delivery
Poucos usam Continuous Deployment completo.
Por razões regulatórias.
9 — IaC novamente
Agora aparecem ferramentas.
Terraform.
CloudFormation.
Pulumi.
Ansible.
Para um programador COBOL
A ideia é simples.
Você não administra servidores.
Você administra código que administra servidores.
É um novo nível de abstração.
10 — DevOps Culture
Essa é provavelmente a imagem mais importante.
Porque DevOps NÃO é ferramenta.
É cultura.
Imagine:
Desenvolvimento culpa Infraestrutura.
Infraestrutura culpa Banco.
Banco culpa Segurança.
Segurança culpa Rede.
Rede culpa Middleware.
Middleware culpa COBOL.
COBOL culpa CICS.
CICS culpa Db2.
Resultado?
Ninguém resolve.
DevOps diz:
Todos são responsáveis.
O objetivo
Eliminar silos.
Criar colaboração.
Automatizar tarefas repetitivas.
Aprender continuamente.
Compartilhar conhecimento.
O que muda para um Programador COBOL Padawan?
Antigamente bastava dominar:
COBOL
JCL
CICS
DB2
VSAM
Hoje isso continua essencial, mas não é suficiente em muitos projetos de modernização. Um profissional de IBM Z passa a ganhar vantagem competitiva quando também compreende:
Git e GitHub
GitFlow e Pull Requests
Jenkins, GitHub Actions ou Azure DevOps
UrbanCode Deploy ou ISPW Pipelines
SonarQube para análise estática
Docker e conceitos de Containers (mesmo que não execute COBOL dentro deles)
Kubernetes e OpenShift para entender onde vivem as APIs modernas
Ansible para automação de tarefas no z/OS
APIs REST e JSON
z/OS Connect Enterprise Edition
Observabilidade com Instana, OMEGAMON e OpenTelemetry
Segurança integrada com RACF, certificados digitais, OAuth2, JWT e TLS
Integração contínua de aplicações COBOL com pipelines automatizadas
A Grande Lição do Mestre
Quando um Padawan olha para CI/CD, Kubernetes, Infrastructure as Code ou DevOps, pode parecer que tudo isso pertence apenas ao mundo Linux e à Cloud. Mas um profissional experiente de IBM Z percebe algo diferente: esses conceitos representam uma evolução natural de princípios que o ecossistema mainframe já aplicava há décadas — padronização, automação, controle de mudanças, alta disponibilidade, rastreabilidade e confiabilidade.
A grande transformação não está em abandonar o COBOL. Está em conectá-lo a um ecossistema moderno de desenvolvimento contínuo, APIs, automação e observabilidade. O futuro do programador COBOL não é escolher entre "mainframe" ou "DevOps"; é dominar ambos e entender como fazer o IBM Z conversar com o restante da arquitetura corporativa.
No fim das contas, DevOps não substitui o conhecimento de um programador COBOL. Ele amplia esse conhecimento, permitindo que aplicações críticas continuem evoluindo com velocidade, segurança e qualidade — exatamente o que os maiores bancos do mundo esperam de seus sistemas mais importantes.
Sem comentários:
Enviar um comentário