 |
| Bellacosa Mainframe e o portal stargata para adentrar no novo mundo do desenvolvimento mainframe |
☕ Um Café no Bellacosa Mainframe
O Portal Stargate do IBM Z
Quando um Programador COBOL Descobre que Git, DevOps e CI/CD Não São Tecnologias Alienígenas... São os Endereços para Viajar Entre Galáxias de Software
"Há milhares de anos, os Antigos construíram uma rede capaz de conectar mundos instantaneamente. No século XXI, engenheiros criaram outra rede capaz de conectar milhares de aplicações corporativas espalhadas pelo planeta. Seu nome não é Stargate... é Pipeline DevOps."
Prólogo — O Chevron Número Sete
O relógio marcava 03:27 da madrugada.
No Centro de Processamento de Dados, apenas o z16 permanecia acordado.
Milhões de transações cruzavam seus canais FICON.
Cartões eram autorizados.
PIX eram liquidados.
Voos eram confirmados.
Hospitais consultavam prontuários.
Bolsa de valores processava ordens.
E, em algum lugar daquele universo invisível, um jovem programador COBOL fazia sua primeira alteração em um COPYBOOK.
Ele acreditava que bastava alterar o código.
Mas o veterano apenas sorriu.
— Você ainda acha que um programa vive sozinho...
Naquele instante, uma enorme estrutura metálica começou a girar.
Não era um Stargate.
Era uma Pipeline.
Os chevrons começaram a travar.
Git...
DBB...
GitLab...
Jenkins...
ZUnit...
Deployment...
Produção.
O portal foi ativado.
E a verdadeira aventura começou.
Episódio 1 — O IBM Z é um Planeta
Em Stargate SG-1, cada planeta possui sua própria civilização.
No mundo IBM Z acontece exatamente o mesmo.
Cada ambiente é praticamente um planeta independente.
Desenvolvimento
↓
Integração
↓
Homologação
↓
Pré-Produção
↓
Produção
Cada um possui:
regras
segurança
bases de dados
usuários
aplicações
auditoria
monitoramento
Mover software entre esses mundos nunca foi simples.
Durante décadas isso era feito manualmente.
Hoje quem controla os portais é o DevOps.
Episódio 2 — O DHD Chama-se Git
Em Stargate existe um equipamento chamado DHD (Dial Home Device).
Ele controla o portal.
Sem ele, ninguém viaja.
No desenvolvimento moderno existe um equivalente.
Seu nome é Git.
Muitos iniciantes pensam que Git serve apenas para "guardar arquivos".
Isso seria como dizer que o DHD serve apenas para acender luzes.
Git controla praticamente toda a história da aplicação.
Ele registra:
quem alterou
quando alterou
por que alterou
quem aprovou
qual versão entrou em produção
qual versão voltou (rollback)
Cada commit representa um novo endereço gravado na memória do portal.
Curiosidade Bellacosa ☕
Em projetos antigos, a "verdade absoluta" era um PDS ou um Endevor.
Hoje, em arquiteturas modernas, a verdade oficial normalmente reside no repositório Git. Os datasets do z/OS continuam essenciais para compilação e execução, mas o histórico e a colaboração passam a ser organizados pelo controle de versão.
Episódio 3 — A Linguagem dos Antigos
Existe um problema que todo iniciante descobre cedo ou tarde.
Mainframe fala EBCDIC.
O restante do planeta fala ASCII ou UTF-8.
Imagine Daniel Jackson tentando traduzir uma inscrição dos Antigos.
Se errar um símbolo...
Toda a tradução muda.
O mesmo acontece durante uma migração para Git.
Sem conversão correta podemos encontrar situações como:
Antes
AÇÃO
Depois
AÇÃO
Parece pequeno.
Na prática pode causar:
conflitos de merge
comentários ilegíveis
documentação perdida
comparações falsas
arquivos inutilizados
Por isso existe toda uma estratégia de conversão de code pages.
É um dos assuntos mais importantes do curso.
Episódio 4 — O SGC Chama-se GitLab
No universo Stargate existe o Stargate Command.
É dali que todas as missões são coordenadas.
No DevOps existe um equivalente.
GitLab.
Ele não é apenas um servidor Git.
Ele funciona como uma base operacional.
Ali encontramos:
Issues
Merge Requests
Pipelines
Releases
Segurança
Artefatos
Auditoria
Quando um desenvolvedor envia um commit...
É como uma equipe SG retornando de uma missão.
Tudo será analisado.
Episódio 5 — O Iris é a Pipeline
No Stargate existe um Iris.
Ele impede que qualquer coisa atravesse o portal sem autorização.
No DevOps existe um Iris muito parecido.
A Pipeline.
Ela verifica automaticamente:
✔ O código compila?
✔ Os testes passaram?
✔ Existe vulnerabilidade?
✔ O padrão foi respeitado?
✔ Há aprovação?
Se alguma resposta for negativa...
O portal permanece fechado.
Nenhum software chega à produção.
Episódio 6 — Os Asgard Chamam-se DBB
Os Asgard eram extremamente inteligentes.
Criavam tecnologia capaz de resolver problemas gigantescos.
O DBB (Dependency Based Build) faz algo semelhante.
Imagine um banco com:
18.000 programas COBOL
6.000 COPYBOOKS
centenas de mapas BMS
milhares de JCLs
Você altera apenas um COPYBOOK.
A pergunta é inevitável.
Quem precisa ser recompilado?
Todos?
Claro que não.
O DBB investiga as dependências.
Ele descobre:
Programa A
↓
COPY X
↓
Programa B
↓
Programa C
↓
Programa D
Somente quem realmente depende daquela alteração será recompilado.
Isso economiza:
CPU
MIPS
tempo
dinheiro
Easter Egg ☕
Assim como os Asgard dominavam conhecimento acumulado durante milênios, o DBB concentra décadas de experiência em engenharia de build para IBM Z. O verdadeiro "superpoder" não é compilar mais rápido, mas evitar compilar o que não mudou.
Episódio 7 — Thor Apresenta o zAppBuild
O DBB precisa de alguém dizendo como construir a aplicação.
Esse papel pertence ao zAppBuild.
Ele funciona como um roteiro.
Compile
↓
Link
↓
Bind Db2
↓
Package
↓
Deploy
Sem improviso.
Sem dezenas de JCL diferentes.
Tudo padronizado.
Episódio 8 — O Antigo Conhecimento Perdido
Imagine encontrar um programa COBOL criado em 1987.
Ninguém sabe:
quem chama
quem utiliza
quais tabelas acessa
quais COPYBOOKS dependem dele
É exatamente aí que entra o ADDI.
Application Discovery and Delivery Intelligence.
Ele funciona como Daniel Jackson.
Escava.
Relaciona.
Traduz.
Reconstrói.
Mostra mapas gigantescos das dependências.
Você finalmente entende uma aplicação criada há quarenta anos.
Episódio 9 — A Equipe SG-1 Chama-se Jenkins
Em Stargate cada missão possui uma equipe.
No DevOps quem coordena diversas missões pode ser o Jenkins.
Ele recebe a ordem.
Executa.
Compila.
Chama scripts.
Executa testes.
Publica resultados.
Tudo automaticamente.
Em muitos ambientes ele trabalha lado a lado com GitLab, Azure DevOps ou outras plataformas de automação.
Episódio 10 — Outros Mundos: Azure e Wazi
O IBM Z já não vive isolado.
Hoje conversa naturalmente com:
Azure
OpenShift
Kubernetes
GitHub
GitLab
APIs REST
microsserviços
O Wazi as a Service demonstra exatamente isso.
Você pode desenvolver aplicações IBM Z utilizando ferramentas modernas hospedadas em nuvem.
É como atravessar o Stargate para outro planeta...
Sem abandonar seu idioma.
Episódio 11 — O Campo de Treinamento Tok'ra
Uma civilização não evolui sem treinamento.
Durante muito tempo acreditava-se que COBOL não fazia testes unitários.
Isso mudou.
Com o ZUnit podemos automatizar testes de programas COBOL.
Imagine uma alteração aparentemente simples.
Antes:
Alterar
↓
Compilar
↓
Mandar para homologação
Hoje:
Commit
↓
Build
↓
ZUnit
↓
Resultado
↓
Deploy
Se algum teste falhar...
A missão é cancelada.
Dica do Coronel O'Neill
"Confiar apenas porque compilou é como atravessar um Stargate sem verificar o planeta de destino."
Teste sempre.
Episódio 12 — O Conselho dos Antigos
Chega o momento do Deployment.
Aqui muitos iniciantes imaginam que basta copiar datasets.
Não.
Deployment moderno envolve:
empacotamento
aprovação
auditoria
versionamento
rollback
rastreabilidade
Cada release recebe identidade própria.
Nada entra em produção sem deixar um rastro.
Episódio 13 — As Coordenadas Galácticas (Branches)
Em Stargate cada planeta possui um endereço formado por chevrons.
No Git acontece algo parecido.
Cada branch representa um caminho de desenvolvimento.
main
├── develop
├── release
├── feature
└── hotfix
Cada uma possui finalidade específica.
Misturar tudo seria como discar símbolos aleatórios no Stargate.
Você provavelmente chegaria ao planeta errado.
Episódio 14 — A Cidade Perdida dos Antigos
Muitas empresas possuem aplicações criadas nos anos 1970.
Décadas de evolução.
Milhões de linhas COBOL.
Esses sistemas lembram Atlantis.
Imensos.
Poderosos.
Pouco compreendidos.
Ferramentas como o ADDI ajudam a revelar sua arquitetura, permitindo que equipes modernas façam mudanças com muito mais segurança.
Episódio 15 — O Oráculo da Performance
No fim da jornada surge outro personagem importante.
O APA (Application Performance Analyzer).
Compilar não basta.
Executar também não.
É preciso executar bem.
O APA mostra:
consumo de CPU
hotspots
chamadas excessivas
gargalos
desperdícios
É como um sensor Asgard analisando cada detalhe de uma nave antes da decolagem.
A Grande Missão DevOps
Quando unimos todas as tecnologias do curso, obtemos uma cadeia contínua de entrega de software:
Programador COBOL
│
▼
VS Code / IDz
│
▼
Git
│
▼
Merge Request
│
▼
GitLab / Jenkins
│
▼
DBB + zAppBuild
│
▼
Build
│
▼
ZUnit
│
▼
ADDI
│
▼
Empacotamento
│
▼
Deploy Automatizado
│
▼
CICS • Batch • Db2 • IMS
│
▼
APA • Monitoramento
Observe como praticamente tudo ocorre de maneira automática. O desenvolvedor continua sendo indispensável, mas passa a dedicar mais tempo ao desenho da solução e menos às tarefas repetitivas.
Passo a Passo para o Iniciante
Se você está começando agora no mundo IBM Z, esta é uma sequência de estudos que faz muito sentido:
Aprenda bem COBOL, JCL, TSO/ISPF e os fundamentos do z/OS.
Entenda VSAM, Db2, CICS e como uma aplicação corporativa é estruturada.
Estude Git profundamente: commits, branches, merge, rebase e revisão de código.
Aprenda conceitos de CI/CD antes de decorar ferramentas específicas.
Conheça DBB e zAppBuild para compreender como builds modernos funcionam.
Estude ZUnit e incorpore testes automatizados desde cedo.
Explore o ADDI para entender impacto de mudanças em aplicações legadas.
Aprenda uma plataforma de orquestração, como GitLab ou Jenkins.
Entenda estratégias de deployment, rollback e versionamento.
Finalmente, aprofunde-se em performance, observabilidade e engenharia de plataformas.
Essa sequência faz com que cada etapa tenha um propósito claro e evita a sensação de aprender tecnologias desconectadas.
Curiosidades que Pouca Gente Conhece
O maior desafio de uma pipeline IBM Z normalmente não é compilar COBOL, mas entender corretamente as dependências entre milhares de componentes.
Muitos bancos executam centenas ou milhares de pipelines diariamente sem que clientes percebam que há mudanças em produção.
Um único COPYBOOK compartilhado pode impactar centenas de programas diferentes.
Ferramentas de descoberta de aplicações, como o ADDI, ajudam equipes que nunca participaram do desenvolvimento original a compreender sistemas com décadas de evolução.
O movimento Open Mainframe Project acelerou a integração entre tecnologias abertas e o ecossistema IBM Z, aproximando práticas modernas de engenharia de software do ambiente corporativo tradicional.
Conclusão — O Oitavo Chevron
No último episódio de muitas temporadas de Stargate, descobrimos que o verdadeiro objetivo nunca foi apenas atravessar portais.
Era compreender uma rede inteira de civilizações.
O mesmo acontece com o IBM Z.
O programador iniciante costuma acreditar que aprender COBOL é suficiente.
Depois percebe que existe Db2.
Em seguida descobre CICS.
Depois VSAM.
Mais tarde encontra Git.
Pipeline.
DBB.
GitLab.
Jenkins.
ZUnit.
ADDI.
Deployment.
Performance.
Observabilidade.
Cada tecnologia parece um novo planeta.
Mas, pouco a pouco, surge uma revelação: todas fazem parte de uma única galáxia.
O verdadeiro arquiteto não conhece apenas uma linguagem de programação. Ele entende como cada componente conversa com os demais, como uma alteração percorre toda a cadeia de entrega e como manter sistemas que processam bilhões de transações com segurança e previsibilidade.
No fim, o maior portal nunca foi o Stargate.
Foi a mudança de mentalidade.
Quando você deixa de enxergar um simples programa COBOL e passa a visualizar todo o ecossistema que o cerca, o oitavo chevron finalmente trava... e uma nova galáxia de oportunidades se abre diante de você.
Easter Egg Bellacosa: se um dia você ouvir um veterano dizer "o programa compilou, mas a pipeline não deixou passar", lembre-se do Iris do Stargate. O código pode estar pronto para atravessar o portal, mas somente aplicações que sobreviverem a todas as verificações chegam ao destino final: a produção do IBM Z.
