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

terça-feira, 23 de dezembro de 2025

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


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