📘 Apostila DevOps Mainframe Jenkins, Ansible, UrbanCode Deploy e o renascimento do z/OS

 

📘 Apostila DevOps Mainframe

Jenkins, Ansible, UrbanCode Deploy e o renascimento do z/OS

Há quem ainda acredite que DevOps nasceu na cloud.
Quem viveu mainframe sabe: o mainframe sempre foi DevOps, só não chamava assim.

Muito antes de YAML, pipelines e dashboards coloridos, o IBM mainframe já praticava:

• automação,

• segregação de ambientes,

• controle rigoroso de mudanças,

• rollback planejado,

• auditoria completa.

A diferença é que tudo isso era feito com JCL, PROCs, schedulers e disciplina operacional.
Hoje, Jenkins, Ansible e UrbanCode Deploy apenas vestem roupa nova numa mentalidade antiga e sólida.

---

🏛️ Um pouco de história (para colocar as coisas no lugar)

Nos anos 70, 80 e 90, o ciclo de vida de uma aplicação COBOL era rígido por necessidade:

• DEV não era QA

• QA não era PROD

• PROD era sagrado

Cada passo deixava rastro. Cada job tinha dono. Cada erro custava caro.

Quando o mundo distribuído descobriu o caos de “funciona na minha máquina”, o mainframe já tinha aprendido — na dor — que processo salva sistemas.

O DevOps moderno surge tentando recuperar essa disciplina, agora com ferramentas novas.

---

🔧 Onde entram Jenkins, Ansible e UrbanCode no mainframe?

Jenkins — o orquestrador inquieto

No mundo IBM mainframe, o Jenkins não compila COBOL.
Ele manda o mainframe trabalhar.

Seu papel é:

• detectar mudanças no Git,

• iniciar pipelines,

• submeter JCL via Zowe,

• validar RC,

• organizar o fluxo.

📌 Easter egg Bellacosa:
Jenkins é, na prática, um scheduler nervoso, menos paciente que o Control-M, mas muito mais falador.

---

Ansible — o bibliotecário organizado

Ansible traz para o z/OS algo que o mainframe sempre gostou: padronização.

Com playbooks YAML, ele:

• copia datasets,

• executa comandos,

• submete jobs,

• garante que ambientes estejam no estado correto.

📌 Curiosidade:
Para quem vem de REXX e JCL, Ansible lembra um EXECIO com esteróides, só que multiplataforma.

---

UrbanCode Deploy — o velho auditor que agora usa terno novo

O IBM UrbanCode Deploy (UCD) é onde o mainframe se sente em casa.

Ele entende:

• ambientes,

• promoção controlada,

• aprovação,

• rollback,

• compliance.

UCD não é “mais um Jenkins”.
Ele é o guardião do PROD, aquele colega sisudo que pergunta:

“Tem aprovação? Tem plano de volta?”

📌 Easter egg corporativo:
Em muitos bancos, o UCD é o novo CMF disfarçado de DevOps.

---

🧠 Aplicação real no mundo IBM Mainframe

Um pipeline típico hoje funciona assim:

1. COBOL versionado em Git

2. Jenkins dispara a integração contínua

3. JCL compila e link-edita no z/OS

4. Ansible prepara datasets e ambientes

5. UCD promove DEV → QA → PROD

6. Tudo auditado, versionado e rastreável

Nada disso quebra o mainframe.
Pelo contrário: valoriza sua arquitetura.

---

📋 Dicas práticas de quem já viu produção cair

✔ YAML orquestra, JCL executa
✔ Nunca coloque lógica de negócio no pipeline
✔ RC é lei — ignore RC e aprenda pelo incidente
✔ PROD não é laboratório
✔ Rollback não é opcional
✔ Automação sem governança é só caos rápido

---

🐣 Easter eggs para os atentos

• Jenkins + Zowe é o novo Submit Job com esteroides

• Ansible no z/OS é o primo moderno do REXX batch

• UCD herdou o espírito do change management clássico

• DevOps não “modernizou” o mainframe — apenas o reencontrou

---

🧾 Conclusão Bellacosa

O IBM mainframe não precisa ser salvo pelo DevOps.
Ele precisa apenas ser bem apresentado às ferramentas certas.

Jenkins traz velocidade.
Ansible traz ordem.
UrbanCode traz governo.
O z/OS continua fazendo o que sempre fez melhor: rodar o mundo sem cair.

E quem domina essa integração não está preso ao passado —
está segurando o futuro com as duas mãos.

 

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

Ano	Marco
2008–2010	Agile começa a tocar o mainframe
2012	🔥 Início teórico do DevOps no IBM Z
2013	UrbanCode + RTC no z/OS
2014	z/OSMF workflows
2015–2017	Git, 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

 

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