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.”

 

🔥 JCL como Pipeline DevOps

Conhecimento básico sobre aplicações distribuídas para mainframers

---

☕ Midnight Lunch no CPD (agora com YAML na mesa)

Era madrugada. Café forte. JES2 organizando a fila com mais elegância do que muito orquestrador moderno.
Um arquiteto cloud visita o CPD e comenta:

“Hoje fazemos tudo com pipeline DevOps.”

O mainframer olha para o JCL rodando há 20 anos e responde em silêncio:
👉 “Engraçado… eu faço isso desde antes de chamar assim.”

Este artigo é sobre isso:
JCL como pipeline DevOps, explicado para quem já domina batch, job, step, CC e restart — e quer entender aplicações distribuídas sem abandonar a alma mainframe.

---

🧠 Pipeline DevOps, em português mainframe

No mundo moderno, um pipeline DevOps:

• Compila

• Testa

• Executa

• Publica

• Reprocessa em caso de falha

• Controla recursos

• Gera logs

No mundo mainframe, isso sempre foi:

//JOBNAME JOB ...
//STEP01  EXEC ...
//STEP02  EXEC ...
//STEP03  EXEC ...

📌 Pipeline DevOps = Job bem escrito.

---

🕰️ Um pouco de história (spoiler: nada é novo)

Antes de:

• Jenkins

• GitLab CI

• GitHub Actions

• Argo

• Airflow

Já existia:

• JES

• JCL

• PROCs

• COND

• RESTART

• SMF

💡 Curiosidade Bellacosa:
O JCL nasceu automatizando fluxo de trabalho. Exatamente o que DevOps promete até hoje.

---

🧩 Mapeamento direto: JCL ↔ DevOps

DevOps Pipeline	JCL
Stage	STEP
Pipeline file	JOB
Agent	Initiator
Retry	RESTART
Conditional	COND
Resource limit	TIME / REGION
Logs	SYSOUT / SMF
Scheduling	JES

👉 A diferença é sintaxe, não conceito.

---

⚙️ JOB Statement: o manifesto DevOps original

Hoje você descreve tudo em YAML.
No mainframe, isso sempre existiu:

//PIPEJOB JOB 'BELLACOSA',
/*        CLASS=A,
          MSGCLASS=X,
          TIME=0,
          REGION=0M,
          PRTY=15 */

Isso define:

• Prioridade

• Limite (ou não) de CPU

• Memória

• Classe de execução

• Comportamento operacional

💡 Easter Egg:
PRTY=15 é o “run ASAP” do DevOps raiz 😎

---

🔀 Steps como stages de pipeline

Cada STEP é um stage isolado, previsível e rastreável:

//BUILD   EXEC PGM=IGYCRCTL
//TEST    EXEC PGM=TESTRUN
//DEPLOY  EXEC PGM=LOADMOD

📌 Isso é:

• Build

• Test

• Deploy

Só que sem marketing.

---

❌ COND: o if/else que evita desperdício

DevOps fala em:

“Não execute se o estágio anterior falhar.”

JCL já resolvia:

COND=(4,GT)

Tradução:

“Se algo deu ruim, nem continua.”

👉 Economia de CPU, custo e paciência.

---

🔄 RESTART: o sonho de todo pipeline moderno

Quantos pipelines cloud ainda fazem restart de verdade?

No mainframe:

//JOB JOB ...,RESTART=STEP03

• Nada de reprocessar tudo

• Nada de gambiarra

• Nada de “vamos rodar de novo desde o começo”

💡 Curiosidade:
RESTART idempotente é disciplina de projeto. O mainframe sempre exigiu isso.

---

🌐 JCL e aplicações distribuídas

Hoje, um pipeline DevOps pode:

• Chamar APIs

• Publicar eventos

• Rodar batch

• Integrar sistemas

No mundo híbrido:

• JCL dispara batch

• Batch chama MQ

• MQ aciona microserviço

• Microserviço chama CICS

• CICS grava no DB2

• SMF registra tudo

👉 JCL vira o maestro do ambiente distribuído.

---

📊 Observabilidade: antes era obrigação

Hoje falam:

• Observability

• Tracing

• Metrics

No JCL:

• SYSOUT

• SMF

• RMF

• JES logs

📌 Se não tem log, não roda.
📌 Se não mede, não entra em produção.

Mainframe ensinou isso cedo.

---

🪜 Passo a passo mental para o mainframer virar “DevOps”

1. Veja jobs como pipelines

2. Veja steps como stages

3. Veja JES como scheduler

4. Veja SMF como observabilidade

5. Veja RESTART como retry inteligente

6. Ignore o hype, foque nos princípios

---

📚 Guia de estudo (com cérebro mainframe)

🔹 Estude:

• CI/CD

• Pipelines

• Event-driven

• Observabilidade

🔹 Faça paralelos:

• JCL ↔ YAML

• JES ↔ Orquestrador

• COND ↔ if/else

• RESTART ↔ rerun from failure

🔹 Exercício clássico:

“Esse pipeline sobreviveria a um batch noturno de verdade?”

---

🏁 Conclusão – El Jefe fecha o pipeline

DevOps não inventou:

• Orquestração

• Automação

• Governança

• Resiliência

Ele renomeou.

O JCL já fazia tudo isso:

• Sem buzzword

• Sem framework da moda

• Sem quebrar a cada release

Por isso, quando alguém diz:

“Pipeline moderno é coisa nova”

O mainframer responde, calmamente, com o café na mão:

“Novo é o nome.
O conceito… eu já rodei em produção.” ☕🔥

 

 

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”