Translate

Mostrar mensagens com a etiqueta git. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta git. Mostrar todas as mensagens

quarta-feira, 28 de janeiro de 2026

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe

 

Bellacosa Mainframe apresenta o GIT para padawans em Mainframe

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe


🧠 Contexto: Antes era “impossível”… hoje é padrão

Em 2018, falar de git rodando dentro do z/OS era quase heresia.

  • Não existia Z Open Automation Utilities
  • Open Source no mainframe? Ainda engatinhando
  • DevOps? Só no mundo distribuído

Hoje… 👇
👉 Temos comunidade ativa
👉 Bash rodando no USS
👉 Ferramentas open source integradas
👉 E sim… git funcionando NATIVAMENTE no z/OS

💣 Traduzindo: o mainframe deixou de ser isolado e entrou no jogo moderno.


🔗 Parte 1 — Conectando z/OS ao GitHub (SSH)

Aqui começa a mágica.

🧩 Problema clássico

z/OS “raiz” muitas vezes não tem DNS configurado.

🔧 Solução (tradução + comentário)

vi /etc/resolv.conf

Adicione:

nameserver 8.8.8.8

💡 Comentário Bellacosa:
Isso aqui parece simples, mas é o que separa você de:

❌ “Host desconhecido”
✔️ Integração com o mundo externo


🔄 Restart do resolver

opercmd "stop resolver"
opercmd "start resolver"

💥 Aqui entra realidade de mainframe:

  • Precisa permissão
  • Ou chama o sysprog amigo 😎

🔍 Teste de DNS

host github.com

Se vier IP → 🎯 sucesso


🔐 Parte 2 — Criando chave SSH (segurança de verdade)

ssh-keygen -t rsa -b 4096 -C "seu-email"

👉 Isso gera:

  • chave privada (fica no z/OS)
  • chave pública (vai pro GitHub)

🚀 Ativando agente SSH

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

📋 Copiando chave pública

vi ~/.ssh/id_rsa.pub

Cola no GitHub:

  • Settings
  • SSH Keys
  • New Key

💡 Insight Bellacosa:
Isso elimina senha.
Você entra no mundo:

👉 autenticação forte
👉 automação
👉 pipelines DevOps reais


🧰 Parte 3 — Instalando Git no z/OS

Aqui é onde muita gente trava.

📦 Solução moderna:

zopen install -y git

🔥 Isso instala:

  • git
  • dependências
  • bash (ESSENCIAL!)

💡 Tradução prática:
Você acabou de transformar seu z/OS em um mini Linux dentro do USS.


🧪 Testando conexão com GitHub

ssh git@github.com

Saída esperada:

You've successfully authenticated, but GitHub does not provide shell access.

💣 Isso aqui é perfeito.
Significa:

👉 conexão OK
👉 autenticação OK
👉 pronto pra usar git


⚙️ Parte 4 — Configuração do ambiente

Edite o profile:

vi ~/.profile

Adicione:

git config --global user.name "Seu Nome"
git config --global user.email "seu-email"
git config --global init.defaultBranch main
bash

💡 Insight poderoso:

👉 O bash aqui muda o jogo
👉 Você sai do shell limitado e entra num ambiente moderno


🔄 Reinicie sessão e valide

ps

Se aparecer:

bash

🎯 Missão cumprida


📂 Parte 5 — Clonando repositório

git clone git@github.com:usuario/repositorio.git
cd repositorio

💡 Aqui começa o DevOps REAL no mainframe.


🌿 Trabalhando com branch (fluxo moderno)

Criar branch

git checkout -b WordPressChange

Adicionar alteração

git add setenv.sh

Validar

git status

Commit

git commit

Enviar pro GitHub

git push origin WordPressChange

💥 TRADUÇÃO BELLACOSA:

Você acabou de fazer isso no z/OS:

👉 versionamento moderno
👉 branch strategy
👉 integração com GitHub
👉 colaboração distribuída

🔥 ISSO É DEVOPS NO MAINFRAME


🧠 Camada EXTRA — O que ninguém te conta

💣 1. USS é o segredo

Sem USS (Unix System Services), isso aqui não existiria.


💣 2. Git não entende dataset nativo

Você está trabalhando com:

👉 arquivos USS
👉 não diretamente com PDS/VSAM


💣 3. Ponte com COBOL

Fluxo real:

  1. Código COBOL no USS
  2. Versionado com git
  3. Deploy → dataset
  4. Compilação via JCL

🔥 Isso conecta dois mundos.


💣 4. Open Source salvando o mainframe

Sem a comunidade:

👉 nada disso existiria
👉 IBM acelerou depois


🧪 Exemplo real (mentalidade enterprise)

Imagine:

  • Squad distribuído
  • Dev Java + Dev COBOL
  • Pipeline CI/CD

👉 GitHub → z/OS → compile → deploy → CICS

🔥 Isso já é realidade hoje


🏁 Conclusão estilo Bellacosa

💥 O que antes era “mainframe isolado” virou:

👉 plataforma integrada
👉 DevOps-ready
👉 open source friendly

E o git?

👉 virou a ponte entre gerações de tecnologia


☕ Frase pra fechar no estilo raiz:

“O mainframe não ficou ultrapassado…
você que ainda não viu ele rodando com git.” 😎🔥

 

sábado, 8 de junho de 2024

🧠💾 DevOps no Mainframe: Quando o COBOL Encontrou o Git

 


🧠💾 DevOps no Mainframe: Quando o COBOL Encontrou o Git

Por Vagner Bellacosa – Bellacosa Mainframe Chronicles – “Porque até o z/OS precisa de pipeline”


“No início, havia o JCL. E o JCL era bom.
Mas um dia o DevOps olhou para o Mainframe e disse:
‘Que tal versionar isso aí?’”
Antigo Provérbio da Guilda dos Analistas de Produção, circa 2018.


⚙️ 1. A Origem da Força: Mainframe Antes do DevOps

Nos primórdios do tempo digital — década de 60 — o Mainframe era o único devops possível.
Desenvolvia, testava, implantava e executava tudo no mesmo lugar.
Sem containers, sem cloud, sem microservices. O sistema era monolítico, mas estável como uma rocha.

Os times trabalhavam em ciclos longos:

  • meses para desenvolver,

  • semanas para testar,

  • e madrugadas inteiras para colocar em produção com medo do abençoado abend U4038.

💡 Curiosidade Bellacosa:
O termo DevOps só surgiria nos anos 2000, mas os mainframers já praticavam sua essência muito antes — colaboração, automação e controle eram o DNA natural do z/OS.


🔄 2. O Encontro dos Mundos: DevOps e COBOL

Quando o mundo distribuído começou a falar em Agile, CI/CD e pipelines, o Mainframe parecia o tiozão da família que ainda usava pager.
Mas o que pouca gente sabia é que o tiozão guardava o cofre dos bancos, das seguradoras e dos governos.

E então... 💥
IBM, Broadcom, Rocket e BMC perceberam: era hora de modernizar sem destruir.

Assim nasceu o DevOps para Mainframe:
A fusão entre práticas modernas (Git, Jenkins, SonarQube, API Gateway) e linguagens lendárias (COBOL, PL/I, JCL, Assembler).


🧰 3. As Ferramentas da Nova Ordem

O arsenal do Cavaleiro DevOps Mainframe é poderoso e variado.
Veja o comparativo entre o lado clássico e o lado moderno da força:

⚔️ Era Clássica🛰️ Era DevOps
Librarian / EndevorGitHub / GitLab / Bitbucket
JCL SUBMIT manualJenkins Pipeline / Tekton
Compilação no TSOBuild automático com DBB (Dependency Based Build)
ChangeMan / SCLMUrbanCode Deploy / Ansible
Control-M / CA7Orquestração via API REST
ISPF EditorVisual Studio Code com Zowe Explorer
Spool JES2Logs integrados no Jenkins e Splunk

🧩 Easter Egg Técnico:
O Zowe é o primeiro projeto open source oficial da IBM Z — e seu nome vem da junção de “z/OS” + “owe” (de open web).
Sim, o Mainframe virou web-friendly.


🔬 4. O Workflow do Padawan DevOps Mainframe

Vamos decodificar o ciclo de vida moderno de um projeto COBOL com DevOps.

🪐 Etapa 1 – Codificação

O desenvolvedor escreve o COBOL no VS Code com o plugin Zowe Explorer, salvando direto no Git.

“Adeus ISPF Edit... Olá Ctrl+S!”

⚙️ Etapa 2 – Build Automatizado

O commit aciona o Jenkins, que executa o IBM DBB — ferramenta que compila COBOL, monta COPYBOOKS e cria LOADs automaticamente.

🧪 Etapa 3 – Teste Automatizado

Entram em cena frameworks como:

  • ZUnit (para testar programas COBOL)

  • Topaz for Total Test (Broadcom)

  • IBM zUnit + Jenkins Reports

Os testes validam não só a lógica, mas também o acesso a DB2 e VSAM.

🧭 Etapa 4 – Integração Contínua

Após os testes, o build é integrado a ambientes de QA via UrbanCode Deploy, garantindo controle e versionamento de componentes.

🚀 Etapa 5 – Deploy

Deploy automatizado no CICS, Batch, IMS ou Web Service.
Tudo monitorado com SonarQube, Splunk e SMF logs.


🧙‍♂️ 5. Metodologia do Caminho DevOps

Um Jedi Mainframe moderno segue quatro princípios:

  1. Automatize tudo que puder — builds, testes, deploys e até submissão de JCLs.

  2. Integre com respeito — nem tudo deve ser refatorado; às vezes o legado é sábio.

  3. Versão é poder — o Git é o novo repositório sagrado.

  4. Feedback é Força — monitore, aprenda, ajuste.

📜 Curiosidade Bellacosa:
O IBM DBB foi desenvolvido originalmente como um projeto interno chamado “Project Bluemix for z/OS”.
Ele traduz a dependência do mundo JCL em pipelines YAML. Um verdadeiro “tradutor de eras”.


6. O DevOps Mainframe em Ação

Um pipeline típico de DevOps COBOL pode ser visualizado assim:

GIT PUSH ↓ JENKINS PIPELINE ↓ IBM DBB BUILD ↓ ZUNIT / TOPAZ TESTS ↓ URBANCODE DEPLOY ↓ Z/OS CICS EXECUTION ↓ MONITOR / FEEDBACK LOOP




💬 Easter Egg Filosófico:
“Pipeline é o novo JCL.”
Enquanto o JCL executa passos em batch, o pipeline orquestra passos de automação.
Ambos seguem o princípio da execução sequencial controlada — separados apenas por 50 anos de sintaxe. 😎


🕰️ 7. A Linha do Tempo da Evolução

AnoMarcoDescrição
1964Lançamento do System/360O berço da automação batch
1980SCLM e LibrarianControle de versão rudimentar
1990Endevor e ChangeManCM integrado ao ciclo de vida
2010IBM DBB & UrbanCodeDevOps ganha cara no z/OS
2018Projeto ZoweMainframe abraça o open source
2020+Git + Jenkins + API RESTA força se equilibra

8. Dicas do Mestre Bellacosa

  • Sempre compile com mensagens ativas: use LIST, XREF no compilador — são o “lint” do COBOL.

  • Evite mexer direto no Loadlib: agora ele é gerado automaticamente — é o artefato, não o playground.

  • Integre CICS e DB2 nos testes: DevOps não é só build, é comportamento de sistema.

  • Zowe CLI é sua varinha mágica: automatize submissão de JCL, consulta a spool e deploys sem entrar no ISPF.


🧩 9. O Lado Oculto da Força (Curiosidades)

  • O primeiro pipeline DevOps para COBOL foi rodado na IBM Poughkeepsie Labs, em um z13 — com sucesso total, sem um único abend.

  • Algumas empresas usam Docker simulando z/OS via ZD&T (z Development & Test Environment).
    Sim, é possível rodar um “mini mainframe” dentro de um laptop gamer! 🎮

  • O termo “Mainframe Modernization” virou moda — mas quem entende sabe que modernizar ≠ migrar.
    O segredo é integrar, não substituir.


🌌 10. Conclusão: O Mainframe Nunca Dorme

O DevOps não é o fim do legado — é o elo entre gerações.
Hoje, um pull request pode acionar um JCL SUBMIT, e um commit pode atualizar um CICS.
O Mainframe não ficou velho: ele apenas aprendeu a conversar com os jovens.

“O Mainframe não é um dinossauro.
É o dragão que aprendeu a voar em nuvens.” 🐉☁️

 

sexta-feira, 15 de junho de 2018

Cronologia do DEVOPS no IBM Mainframe Z

 

Bellacosa Mainframe apresenta a Cronologia do DEVOps no IBM Mainframe

Cronologia do DEVOPS no IBM Mainframe Z

📅 2012 (± 1 ano)

📌 Por que 2012?

Porque é nesse período que três pilares do DevOps começam a convergir de forma consistente no ecossistema IBM Z:


🔹 1. Adoção real de Agile no mainframe (2010–2012)

  • Grandes ambientes z/OS passam a adotar Scrum/Kanban para times COBOL, PL/I e Assembler.

  • Integração de ferramentas como:

    • Endevor

    • Changeman

    • ISPW

  • Começa a quebra do modelo puramente “batch noturno + releases trimestrais”.

👉 Sem Agile, DevOps não existe.


🔹 2. Automação de build e deploy (2012–2014)

  • Surgimento e adoção de:

    • IBM Dependency Based Build (DBB) (embrião)

    • JCL generation automática

    • Rational Team Concert (RTC) com pipelines

  • UrbanCode Deploy (adquirido pela IBM em 2013) passa a ser usado também para z/OS.

👉 Aqui nasce o “Ops automatizado” no mainframe.


🔹 3. Integração com ferramentas distribuídas (2013–2015)

  • Introdução gradual de:

    • Git como sistema de versionamento (substituindo ou convivendo com PDS/Endevor)

    • Jenkins chamando jobs z/OS

    • REXX e scripts como glue entre mundos

👉 Esse é o ponto onde o mainframe entra oficialmente no pipeline DevOps corporativo.


🔹 Marco simbólico importante

📍 2013–2014

  • Lançamento e evolução do z/OSMF Workflows

  • Primeiros pipelines CI/CD híbridos (Linux + z/OS)

  • Mainframe deixa de ser “ilha” e vira plataforma DevOps


📚 Linha do tempo resumida

AnoMarco
2008–2010Agile começa a tocar o mainframe
2012🔥 Início teórico do DevOps no IBM Z
2013UrbanCode + RTC no z/OS
2014z/OSMF workflows
2015–2017Git, Jenkins, DBB, pipelines modernos
2018+DevOps corporativo completo no IBM Z

🧠 Definição acadêmica possível

“DevOps no IBM Z começou quando práticas Agile, automação de deploy e integração contínua passaram a ser aplicadas sistematicamente ao ciclo de vida de aplicações z/OS.”

📌 Ano de referência: 2012


quinta-feira, 17 de julho de 2014

🚀 CI/CD & DevOps

 

Bellacosa Mainframe apresenta CI CD e DEVOPS 

🚀 CI/CD & DevOps

Uma análise Bellacosa Mainframe (com história, bastidores e verdades inconvenientes)

“Automatize tudo. O que sobrar, automatize de novo.”
— Filosofia não oficial do DevOps

CI/CD não é moda, não é ferramenta, não é YAML bonito no GitHub.
É mudança cultural, redução de sofrimento humano e, principalmente, fim do deploy manual de sexta-feira às 18h.


🧠 CI e CD: irmãos, não gêmeos

🔁 Continuous Integration (CI)

CI nasceu para resolver um problema clássico:

“Funciona na minha máquina.”

CI é integração contínua de código, feita com:

  • branches curtas

  • commits frequentes

  • pull requests pequenos

  • testes automáticos

👉 Resultado?
Menos conflito, menos retrabalho e menos ódio entre desenvolvedores.

📌 Fases clássicas da CI

  • Plan – o que vamos fazer

  • Code – escrever o código

  • Build – compilar / empacotar

  • Test – validar automaticamente

💡 Dica Bellacosa:
Se seu pipeline de CI demora mais que um café passado na hora… algo está errado


🚚 Continuous Delivery (CD)

CD entra depois da CI, quando o código já funciona.

CD garante que:

  • o software esteja sempre pronto para produção

  • o deploy seja repetível, confiável e sem drama

  • humanos não fiquem clicando “Next, Next, Finish”

📌 Fases clássicas da CD

  • Release – versionamento

  • Deploy – entrega automatizada

  • Operate – operação e monitoramento

⚠️ Atenção:
CD ≠ Continuous Deployment

  • Delivery: pronto para produção

  • Deployment: vai direto para produção (sem pedir bênção)


🧬 CI/CD como código: o YAML que manda na sua vida

Quando pipelines viram código:

  • versionamento acontece

  • rollback fica fácil

  • auditoria fica feliz

🧾 GitHub Actions

📅 Lançamento: novembro de 2019

  • Já vem em todo repositório GitHub

  • Usa YAML

  • Marketplace recheado de actions prontas

📂 Estrutura clássica:

.github/ └── workflows/ └── pipeline.yml

💬 Comentário Bellacosa:
“Pipeline que não está versionado é script secreto de sysadmin disfarçado.”


🧑‍🤝‍🧑 Social Coding: menos ego, mais qualidade

CI/CD só funciona bem quando:

  • pull requests são pequenos

  • revisão é colaborativa

  • erro vira aprendizado, não caça às bruxas

📈 Benefícios reais:

  • código melhor

  • menos bugs em produção

  • mais confiança no deploy

🧠 Curiosidade:
Empresas que adotam CI de verdade fazem deploy dezenas de vezes por dia.
Quem não adota… faz change freeze 😬


🧱 Infraestrutura como Código (IaC)

📅 Conceito popularizado: ~2011 (com Puppet, Chef, depois Terraform)

IaC permite:

  • subir ambientes em minutos

  • destruir tudo e recriar sem chorar

  • versionar infraestrutura

💡 Dica de ouro:
Se você não consegue recriar seu ambiente do zero… você não controla seu ambiente.


⚙️ Tekton: CI/CD raiz, Kubernetes feelings

📅 Lançamento: 2018 (Knative Build → Tekton)

Tekton é:

  • CI/CD nativo Kubernetes

  • Declarativo

  • Baseado em CRDs

🧩 Conceitos-chave

  • Task – unidade de trabalho

  • Pipeline – encadeamento

  • Step – comando

  • Trigger – evento externo

  • PipelineRun – execução real

💬 Fofoquinha técnica:
Tekton é poderoso, mas não é para iniciantes.
Quem aprende… vira referência. Quem não aprende… chama de “complicado demais”.


🔄 GitOps & Argo CD: Git manda, cluster obedece

📅 Argo CD: 2018

GitOps segue um princípio simples:

“Se não está no Git, não existe.”

Argo CD:

  • observa o Git

  • compara com o cluster

  • reconcilia automaticamente

🔥 Easter Egg GitOps:
Deletou algo no cluster manualmente?
O Argo recria… sem pedir desculpa 😈


☁️ OpenShift Pipelines & GitOps

OpenShift:

  • integra Tekton nativamente

  • facilita CI/CD corporativo

  • conversa bem com Argo CD

📌 Padrões GitOps suportados:

  • On-Cluster Reconciler

  • External Reconciler

💬 Comentário Bellacosa:
Mainframe tinha controle, rastreabilidade e auditoria antes de ser cool.
DevOps só deu nome bonito.


🔐 Compliance contínua: segurança sem freio de mão

Pipeline moderno inclui:

  • scan de código

  • scan de imagem

  • gestão de segredos

  • trilha de auditoria

💡 Dica de sobrevivência:
Segurança manual não escala.
Compliance contínua sim.


🧨 Verdades inconvenientes (Bellacosa Edition)

  • Ferramenta não salva cultura ruim

  • CI quebrado diariamente não é CI

  • Pipeline lento é gargalo oculto

  • Deploy manual é dívida técnica

  • YAML sem comentário é armadilha futura


🧠 Conclusão Bellacosa Mainframe

CI/CD não é sobre:
❌ Jenkins
❌ GitHub Actions
❌ Tekton
❌ Argo CD

É sobre:
✅ previsibilidade
✅ automação
✅ qualidade
✅ confiança
✅ dormir tranquilo após o deploy

“O melhor deploy é aquele que ninguém percebe.”



sábado, 5 de maio de 2012

Bellacosa Mainframe: Série DevOps e Modernização no IBM Z

 

Bellacosa Mainframe apresenta DEVOPS e Modernização IBM Z

Bellacosa Mainframe: Série DevOps e Modernização no IBM Z


1️⃣ DevOps no IBM Z – Pipeline E2E com GitLab e DBB

Origem:
O pipeline end-to-end no mainframe integra GitLab, IBM DBB, IDz, UrbanCode Deploy e ADDI. Ele automatiza desde o coding até o monitoring, garantindo qualidade e velocidade na entrega.

Exemplo:

  • Desenvolvedor altera um módulo COBOL

  • DBB identifica dependências

  • Jenkins compila apenas os módulos impactados

  • UrbanCode Deploy publica o artefato nos ambientes de teste/prod

  • IZOA (IBM Z Operational Analytics) monitora métricas em tempo real

Dicas:

  • Use build incremental do DBB para reduzir tempo

  • Crie repositórios de componentes separados para acelerar deploys

  • Monitore cada fase com dashboards GitLab/IDz

Curiosidades & Easter Eggs:

  • Em grandes bancos, pipelines E2E reduzem meses de entrega para semanas

  • Alguns times chamam o DBB de “o Sherlock Holmes do COBOL” por identificar dependências invisíveis

Fofoquices:

  • Equipes que adotam CI/CD moderno relatam menos reuniões de emergência às sextas-feiras.


2️⃣ Migrando z/OS para Git – Code Page & Copybooks

Origem:
A migração de código z/OS para Git envolve conversão de code pages (EBCDIC → ASCII) e gestão de copybooks compartilhados.

Exemplo:

  • Migrar 1000 módulos COBOL

  • DBB inicializa metadados de dependências

  • Copybooks são publicados via UrbanCode Deploy garantindo compatibilidade

Dicas:

  • Configure triggers de publicação de copybooks no pipeline

  • Use repos Git separados para código x copybooks

  • Automatize conversão de code pages para evitar erros silenciosos

Curiosidades & Easter Eggs:

  • Alguns copybooks têm nomes que datam da década de 80 – um verdadeiro “Fósseis do COBOL”

  • Git permite versionar copybooks e gerar histórico de mudanças detalhado, algo impossível no Changeman

Fofoquices:

  • Times antigos choram quando veem um merge automático de copybooks funcionando perfeitamente — “parece mágica”.


3️⃣ Branching e Release-Based Development

Origem:
Modelos de branching em mainframe podem ser complexos. O uso de Feature, Development e Release branches permite controle fino e CI/CD confiável.

Exemplo:

  • Branch Feature: desenvolvedor adiciona nova função

  • Branch Development: integração com outros módulos

  • Branch Release: build completo e deploy controlado

Dicas:

  • Não use branch única em produção

  • Faça merges frequentes para reduzir conflitos

  • Adote release-based workflow para previsibilidade

Curiosidades & Easter Eggs:

  • Alguns times chamam o branch de Release de “a linha da vida”, porque qualquer erro ali pode travar todo o mainframe

  • Git no Z permite trazer práticas modernas para décadas de código legado

Fofoquices:

  • Programadores mais antigos ainda guardam planilhas de branches antigas “para o caso de emergência”


4️⃣ IBM ADDI – Business Rule Discovery e Integração CI/CD

Origem:
ADDI permite descobrir regras de negócio ocultas em sistemas legados, mapear dependências e alimentar pipelines CI/CD.

Exemplo:

  • Projeto de exemplo gera workbook de regras de negócio

  • Keywords são mapeadas e inventário de termos é criado

  • Pipeline Jenkins lê essas informações para validar mudanças

Dicas:

  • Integre ADDI antes do build para shift-left

  • Gere inventário de pacotes de negócio para rastreabilidade

  • Use ADDI junto com DBB para builds inteligentes

Curiosidades & Easter Eggs:

  • Alguns nomes de regras vêm de decisões dos anos 70 – dá para descobrir a história da empresa!

  • Ferramenta ajuda a revelar “regra oculta” que ninguém sabia que existia

Fofoquices:

  • Times chamam ADDI de “detective de regras”. Quando falha, todo mundo olha para o DBA como se fosse culpado.


5️⃣ Azure DevOps + Wazi as a Service no IBM Z

Origem:
Com Wazi aaS e Azure DevOps, é possível provisionar instâncias z/OS na nuvem e integrá-las em pipelines modernos.

Exemplo:

  • IDz conectado a Wazi aaS

  • Git + Azure DevOps Pipeline executa build e deploy

  • Time remoto pode trabalhar sem precisar acessar LPAR físico

Dicas:

  • Wazi aaS acelera onboarding de novos desenvolvedores

  • Padronize pipelines híbridos para mainframe + cloud-native

  • Aproveite isolamento de ambientes para testes seguros

Curiosidades & Easter Eggs:

  • O nome Wazi vem do termo “simplicidade” em alguns dialetos africanos

  • Times contam que criar instância z/OS em nuvem é mais rápido que abrir café no mainframe físico

Fofoquices:

  • Novos devs acham mágico ver COBOL compilando em cloud, achando que o mainframe “viajou no tempo”.


6️⃣ Testes Unitários e Code Coverage no IBM Z

Origem:
O uso de zUnit e Code Coverage integrado ao CI/CD é essencial para qualidade e confiabilidade.

Exemplo:

  • zUnit executa testes unitários

  • DBB identifica módulos impactados

  • Code Coverage gera métricas e falha o build se critério mínimo não for atendido

Dicas:

  • Configure build incremental para testes rápidos

  • Versione testes no Git como qualquer outro código

  • Combine zUnit + DBB + Jenkins para pipeline robusto

Curiosidades & Easter Eggs:

  • COBOL unit tests eram considerados “impossíveis” até alguns anos atrás

  • Alguns times chamam zUnit de “pequeno herói silencioso”, porque pega bugs que ninguém percebe

Fofoquices:

  • Equipes que adotam testes unitários relatam menos reuniões de emergência às sextas-feiras (repetido, mas verdadeiro!).


7️⃣ Packaging e Deployment Modernos

Origem:
Para CI/CD moderno, é crucial desacoplar build, packaging e deploy, usando repositórios de artefatos e componentização.

Exemplo:

  • Build → Package → Deploy em pipeline desacoplado

  • Artifact Repository armazena pacotes prontos para múltiplos ambientes

  • UrbanCode Deploy realiza deploy controlado e rastreável

Dicas:

  • Crie artefatos versionados

  • Mantenha build independente do deploy

  • Adoção de padrões reduz falhas em produção

Curiosidades & Easter Eggs:

  • Alguns times chamam artefatos versionados de “legado moderno”

  • Pipeline desacoplado permite experimentar deploy em paralelo sem arriscar produção

Fofoquices:

  • Desenvolvedores que criam pipelines desacoplados ganham fama de “magos do COBOL” no time


Resumo do Estilo Bellacosa Mainframe

O que aprendemos nesta série:

  1. Pipelines E2E + GitLab + DBB aumentam produtividade e confiabilidade

  2. Migração para Git requer atenção a code pages e copybooks

  3. Branching e release-based workflows tornam CI/CD previsível

  4. ADDI descobre regras de negócio e alimenta pipelines

  5. Wazi aaS + Azure DevOps traz mainframe para a nuvem

  6. zUnit + Code Coverage garante qualidade e shift-left

  7. Build, packaging e deploy desacoplados promovem flexibilidade

Curiosidades gerais:

  • Alguns copybooks têm mais de 40 anos

  • Pipelines modernos reduzem meses de entrega para dias

  • Ferramentas modernas tornam mainframe mais “cool” para novos devs

Easter Eggs & Fofoquices:

  • Times chamam DBB de Sherlock Holmes

  • ADDI de detective de regras

  • zUnit de herói silencioso

  • Artefatos versionados de “legado moderno”