Bellacosa Mainframe apresenta o jenkins

☕ Um Café no Bellacosa Mainframe

🧪 RICK SANCHEZ E O JENKINSFILE DA DIMENSÃO C-137

Jenkins Pipelines, Git, agentes, artefatos, containers, quality gates, rollback, observabilidade — e o dia em que Rick descobriu que o verdadeiro monstro da produção não era um alienígena, mas um deploy manual de sexta-feira.

Nota de estilo: este artigo usa Rick Sanchez como lente humorística e paródica. A explicação técnica, porém, é bem terrestre — e perigosamente aplicável à produção.

---

🎬 PRÓLOGO — MORTY, QUEM FEZ DEPLOY DIRETO EM PRODUÇÃO?

Imagine a cena.

03:17 da madrugada.

O celular toca.

Produção caiu.

CICS está respondendo.

Db2 está de pé.

MQ aparentemente está normal.

CPU está em 34%.

Nenhum LPAR está pegando fogo.

Mesmo assim, clientes não conseguem concluir transações.

Rick olha para Morty.

— Morty... o que você mudou?

— Nada, Rick!

— Morty, todo programador que diz "nada" às 03:17 acabou de alterar alguma coisa.

Cinco minutos depois descobrimos:

Mudança emergencial
      ↓
Compilação manual
      ↓
Load module copiado manualmente
      ↓
Produção
      ↓
"Funcionou aqui"

Rick pega a portal gun.

Não para fugir.

Para mandar o responsável para uma dimensão na qual toda implantação precisa ser feita manualmente pelo resto da eternidade.

E aqui começa nossa história.

Porque Jenkins Pipeline não é simplesmente uma ferramenta para "automatizar compilação".

Estamos falando de algo conceitualmente muito maior:

SOURCE
   ↓
BUILD
   ↓
TEST
   ↓
QUALITY
   ↓
SECURITY
   ↓
PACKAGE
   ↓
APPROVAL
   ↓
DEPLOY
   ↓
VERIFY
   ↓
OBSERVE

O Jenkins ajuda a transformar o processo de entrega do software em software.

A própria documentação do Jenkins define Pipeline como uma maneira de modelar o processo de entrega como código; um Jenkinsfile pode ficar junto ao código-fonte, permitindo revisão, histórico de auditoria e uma fonte comum da definição da pipeline. (Jenkins)

E para quem passou décadas no mainframe existe algo deliciosamente familiar nisso tudo.

---

🧪 CAPÍTULO 1 — RICK DESCOBRE QUE O JENKINS NÃO FAZ QUASE NADA

Esse é um dos primeiros conceitos que eu ensinaria para alguém começando em DevOps:

Jenkins não é a fábrica. Jenkins é o maestro da fábrica.

O Jenkins não precisa ser o compilador.

Não precisa ser o scanner de vulnerabilidades.

Não precisa ser o repositório Git.

Não precisa ser o repositório de artefatos.

Não precisa ser Kubernetes.

Ele coordena ferramentas que executam essas funções.

Pense:

                    ┌─────────────┐
                    │   JENKINS   │
                    │ ORCHESTRATOR│
                    └──────┬──────┘
                           │
        ┌──────────────────┼──────────────────┐
        ↓                  ↓                  ↓
       Git              Compiler          Tests
        │                  │                  │
        └──────────┬───────┴─────────┬────────┘
                   ↓                 ↓
             Security Scan      Artifact Repo
                   │                 │
                   └────────┬────────┘
                            ↓
                         Deploy
                            ↓
                       Production

Rick provavelmente resumiria:

"Morty, Jenkins não constrói a nave. Ele manda cada idiota da garagem fazer sua parte na ordem certa."

E isso é importante porque muita arquitetura ruim nasce quando Jenkins vira uma espécie de Deus DevOps.

Jenkins chama Docker.

Docker constrói uma imagem.

Jenkins publica a imagem em um registry.

Uma ferramenta de deployment ou Kubernetes executa essa imagem.

São responsabilidades diferentes.

---

🧠 CAPÍTULO 2 — O JENKINSFILE É O JCL DO DEVOPS?

Calma.

Antes que alguém arremesse um manual do JES2 na minha cabeça:

não tecnicamente.

Mas pedagogicamente a comparação é excelente.

Para um programador COBOL entrando em Jenkins, podemos imaginar:

Mundo mainframe	Jenkins/DevOps
JOB	Pipeline
STEP	Stage/Step
EXEC	execução de ferramenta
RC	exit status
SYSOUT	logs
load module	artifact
PROCLIB	lógica reutilizável/shared library
scheduler	parte da orquestração

Não são equivalências arquitetônicas 1:1.

São pontes mentais.

Veja um JCL:

//BELLACOS JOB ...
//COMPILE EXEC PGM=IGYCRCTL
//LINK    EXEC PGM=IEWL
//TEST    EXEC PGM=TESTPGM

Agora uma pipeline extremamente simplificada:

pipeline {
    agent any

    stages {
        stage('Compile') {
            steps {
                sh './compile.sh'
            }
        }

        stage('Test') {
            steps {
                sh './test.sh'
            }
        }

        stage('Package') {
            steps {
                sh './package.sh'
            }
        }
    }
}

Um mainframer olha isso e pensa:

"Vocês inventaram STEP de novo."

😂

Mas existe uma evolução importantíssima.

O Jenkinsfile pode estar dentro do mesmo repositório Git da aplicação.

Portanto:

programa mudou
pipeline mudou
teste mudou
configuração mudou

Tudo isso pode passar pelo mesmo mecanismo de versionamento e revisão.

O Jenkins recomenda manter o Jenkinsfile no source control, justamente por benefícios como revisão, auditabilidade e uma fonte comum da definição da pipeline. (Jenkins)

---

🛸 CAPÍTULO 3 — CONTROLLER E AGENTS: RICK NÃO FAZ O TRABALHO PESADO

Imagine Rick administrando cem Mortys.

Rick recebe os pedidos.

Decide prioridades.

Escolhe quem executará cada tarefa.

Coordena tudo.

Mas seria absurdo Rick pessoalmente pegar cada programa, compilar, testar, empacotar e instalar.

No Jenkins existe uma ideia semelhante:

             JENKINS CONTROLLER
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   AGENT-01     AGENT-02     AGENT-03
    Linux        z/OS         Docker

O controller administra a coordenação.

Os agents fornecem ambientes onde o trabalho efetivamente é executado.

Um agent poderia possuir:

Java
Maven
Git
Docker
Python
Node.js

Outro poderia possuir ferramentas específicas.

No universo IBM Z, podemos ter integração com ferramentas e processos executados no próprio z/OS.

E novamente surge uma analogia útil com mainframe.

JES2 recebe trabalho, gerencia filas e participa da seleção/execução conforme recursos e classes.

Não significa que Jenkins seja "um JES moderno".

Não é.

Mas o conceito de separar orquestração do trabalho de execução do trabalho certamente não provoca choque cultural em quem conhece mainframe.

---

🧬 CAPÍTULO 4 — O PIPELINE DE PRODUÇÃO NÃO É BUILD → DEPLOY

Essa simplificação é perigosa:

BUILD → DEPLOY

Uma pipeline de produção madura se parece muito mais com:

COMMIT
   ↓
CHECKOUT
   ↓
DEPENDENCY ANALYSIS
   ↓
BUILD
   ↓
UNIT TEST
   ↓
STATIC ANALYSIS
   ↓
SECURITY SCAN
   ↓
QUALITY GATE
   ↓
PACKAGE
   ↓
PUBLISH ARTIFACT
   ↓
DEPLOY DEV
   ↓
INTEGRATION TEST
   ↓
DEPLOY SIT
   ↓
DEPLOY UAT
   ↓
APPROVAL
   ↓
DEPLOY PROD
   ↓
VERIFY
   ↓
OBSERVE

Cada estágio deveria responder a uma pergunta.

Build: conseguimos construir?

Test: o comportamento conhecido continua correto?

Security: introduzimos riscos conhecidos?

Quality Gate: atingimos os critérios mínimos?

Deploy: conseguimos instalar?

Verify: o software realmente iniciou e responde?

Observe: continua saudável sob tráfego real?

É aí que aparece uma das frases mais importantes deste artigo:

🚨 DEPLOY SUCCESS ≠ SYSTEM HEALTHY

Morty vê isto:

DEPLOY ........ SUCCESS

e comemora.

Rick pergunta:

"E as transações?"

Silêncio.

---

💳 CAPÍTULO 5 — O SISTEMA ESTÁ VERDE, MAS O NEGÓCIO ESTÁ MORTO

Vamos trazer isso para Cards & Payments.

Imagine um programa COBOL:

AUTHORIZATION

Antes do deploy:

Approval Rate: 87%
CICS Response: 120 ms
CPU: 32%
Db2: NORMAL
MQ: NORMAL

Depois:

Approval Rate: 41%
CICS Response: 118 ms
CPU: 31%
Db2: NORMAL
MQ: NORMAL

Dashboard de infraestrutura:

🟢 CPU

🟢 Memória

🟢 CICS

🟢 Db2

🟢 MQ

Dashboard do negócio:

🔥🔥🔥🔥🔥🔥🔥

A aplicação está respondendo perfeitamente...

e recusando clientes perfeitamente.

Isso nos conduz a uma evolução importantíssima de observabilidade:

TECHNICAL HEALTH
        +
BUSINESS HEALTH
        =
PRODUCTION HEALTH

Para uma autorização de cartões poderíamos acompanhar:

approval rate
decline rate
timeout rate
reversal rate
duplicate transactions
average authorization latency
transactions/minute

Isso é infinitamente mais poderoso do que perguntar apenas:

"A JVM está viva?"

Ou:

"O CICS está UP?"

---

🧪 CAPÍTULO 6 — QUALITY GATES: RICK PROÍBE MORTY DE APERTAR O BOTÃO

Imagine:

Compile       OK
Unit Tests    OK
Coverage      42%
Security      CRITICAL
Quality       FAILED

Morty pergunta:

— Posso mandar para produção?

Rick:

— Claro. E depois podemos testar se respirar no espaço sem capacete realmente mata.

Quality Gates transformam regras organizacionais em controles executáveis.

Podemos determinar:

IF compilation failed
    STOP

IF mandatory tests failed
    STOP

IF critical vulnerability exists
    STOP

IF artifact is invalid
    STOP

Isso é fail fast.

Descobriu cedo?

Pare cedo.

Porque existe uma matemática cruel:

erro descoberto no desenvolvimento
        ↓
barato

erro descoberto no teste
        ↓
mais caro

erro descoberto em produção
        ↓
War Room + pizza + café + 03:17

---

🔐 CAPÍTULO 7 — MORTY COLOCOU A SENHA NO JENKINSFILE

Rick abre o repositório:

environment {
    USER = "PRODADMIN"
    PASSWORD = "Morty123"
}

Silêncio.

Rick olha para Morty.

Morty olha para Rick.

Rick abre o portal.

😂

Segredos não devem ser hardcoded no código da pipeline.

Jenkins oferece mecanismos de credentials que permitem trabalhar com diferentes tipos de segredo e vinculá-los durante a execução. A documentação também alerta para os cuidados necessários com interpolação e exposição acidental em logs. (Jenkins)

Mas existe uma pegadinha.

Mascarar uma senha no log não transforma uma arquitetura insegura em arquitetura segura.

Precisamos combinar:

Secure storage
      +
Least privilege
      +
Credential scope
      +
Log hygiene
      +
Rotation
      +
Access control

Outra distinção importante:

ENVIRONMENT VARIABLE ≠ SECRET

Uma variável de ambiente pode conter um segredo.

Mas isso não significa que qualquer environment variable seja um mecanismo seguro para armazenamento de segredo.

---

📦 CAPÍTULO 8 — BUILD ONCE, PROMOTE MANY

Aqui aparece uma ideia maravilhosa.

Imagine:

DEV
 ↓
build A

TEST
 ↓
build B

UAT
 ↓
build C

PROD
 ↓
build D

Rick imediatamente perguntaria:

"Então exatamente o que vocês testaram?"

Essa pergunta destrói a arquitetura.

Porque se eu reconstruí o software entre ambientes, existe a possibilidade de diferenças em:

compiler
dependencies
configuration
timestamps
build environment
scripts
libraries

O modelo muito mais forte é:

SOURCE
   ↓
BUILD
   ↓
ARTIFACT X
   ↓
DEV
   ↓
TEST
   ↓
UAT
   ↓
PROD

O mesmo artefato vai sendo promovido.

A documentação atual da IBM para CI/CD em z/OS descreve explicitamente o artifact repository como peça que desacopla SCM dos ambientes de runtime e possibilita a prática de "Build once, deploy many". (IBM)

Agora conseguimos dizer:

APP       AUTHORIZATION
VERSION   4.7.2
COMMIT    a73fc91
BUILD     1842
ARTIFACT  auth-4.7.2-1842

Isso é rastreabilidade.

---

🧬 CAPÍTULO 9 — MAS COBOL TEM DEPENDÊNCIAS, RICK!

Exatamente.

Imagine:

COPY CARDREC.
COPY AUTHRESP.

O desenvolvedor altera:

CARDREC

Quem precisa ser recompilado?

É justamente aqui que o problema fica interessante no mainframe.

A IBM descreve o Dependency Based Build como solução para aplicações tradicionais z/OS, incluindo COBOL e PL/I, capaz de rastrear dependências e realizar builds integrados a workflows Git e ferramentas como Jenkins. (IBM)

Assim podemos imaginar:

Git commit
     ↓
Jenkins
     ↓
DBB
     ↓
Dependency Analysis
     ↓
Programs impacted
     ↓
Compile
     ↓
Link-edit
     ↓
Test

Em vez de:

"Alterou COPYBOOK? Compila tudo e reza."

A documentação IBM para DevOps em z/OS inclui no conceito de build justamente dependências, compilação, link-edit e testes unitários; ela posiciona DBB como ferramenta principal para essa parte específica do fluxo z/OS. (IBM)

---

🧙 CAPÍTULO 10 — O PIPELINE COBOL DA DIMENSÃO C-137

Agora podemos construir mentalmente algo muito interessante:

             DEVELOPER
                 │
                 ↓
                Git
                 │
              Webhook
                 │
                 ↓
              Jenkins
                 │
                 ↓
        Dependency Analysis
                 │
                 ↓
             IBM DBB
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
     COBOL      PL/I    Copybooks
       │
       ↓
    Compile
       │
       ↓
   Link-edit
       │
       ↓
   Unit Tests
       │
       ↓
 Static Analysis
       │
       ↓
 Security Gate
       │
       ↓
 Artifact Repository
       │
       ↓
       SIT
       │
       ↓
       UAT
       │
       ↓
 Approval Gate
       │
       ↓
  PRODUCTION
       │
       ↓
 Verification
       │
       ↓
 Observability

Isso não é "tirar o mainframe do passado".

É justamente o contrário.

É integrar IBM Z ao processo corporativo moderno.

A própria orientação IBM sobre DevOps para Z apresenta uma pipeline CI/CD baseada em componentes como serviço Git e DBB, buscando alinhar ferramentas, práticas e resultados com as demais plataformas da empresa. (IBM)

---

🛑 CAPÍTULO 11 — O BOTÃO VERMELHO CHAMADO APPROVAL

Automação não significa:

ninguém controla nada

Esse é outro mito.

Uma pipeline pode chegar até:

Deploy Production

e parar:

╔══════════════════════════════════════╗
║       PRODUCTION APPROVAL           ║
║                                    ║
║ Tests.................... PASSED    ║
║ Security................. PASSED    ║
║ Quality.................. PASSED    ║
║ Artifact................. SIGNED    ║
║ Change Ticket............ VALID     ║
║                                    ║
║       [ APPROVE ] [ REJECT ]        ║
╚══════════════════════════════════════╝

Isso é especialmente relevante em ambientes regulados.

Governança não precisa significar:

planilha
+
e-mail
+
telefonema
+
reunião
+
"quem tem a senha?"

Governança também pode virar código e evidência.

---

🚀 CAPÍTULO 12 — ROLLING, BLUE-GREEN E CANARY

Agora Rick abre três portais.

Rolling

Temos:

V1 V1 V1 V1

Vamos substituindo gradualmente:

V2 V1 V1 V1
V2 V2 V1 V1
V2 V2 V2 V1
V2 V2 V2 V2

Útil quando a arquitetura suporta substituição gradual.

Blue-Green

Temos dois ambientes:

BLUE  → V1 → ACTIVE

GREEN → V2 → READY

Testamos Green.

Depois:

TRAFFIC
   ↓
 GREEN

Se houver problema e as condições permitirem retorno:

TRAFFIC
   ↓
 BLUE

Canary

Liberamos V2 para pequena parcela:

95% → V1
 5% → V2

Observamos.

Depois:

75% → V1
25% → V2

Depois:

50 / 50

até eventualmente:

100% → V2

No mainframe, não devemos copiar esses modelos cegamente como se CICS fosse Kubernetes.

Mas princípios semelhantes podem ser implementados, dependendo da arquitetura, usando regiões, roteamento, APIs, gateways, feature flags, LPARs ou segmentação de tráfego.

---

💥 CAPÍTULO 13 — ROLLBACK NÃO É CTRL+Z

Aqui mora um monstro.

Aplicamos:

PROGRAM V1
       ↓
PROGRAM V2

Deu problema.

Então:

PROGRAM V1

Resolvido?

Talvez.

Agora imagine que V2 também mudou:

COPYBOOK
DB2 SCHEMA
MQ MESSAGE
CONFIGURATION
API CONTRACT
DATA

O programa antigo pode não entender mais o estado atual.

Por exemplo:

V1:
01 CUSTOMER.
   05 ID      PIC 9(08).
   05 STATUS  PIC X.

V2:

01 CUSTOMER.
   05 ID      PIC 9(08).
   05 STATUS  PIC X.
   05 RISK    PIC 9(03).

Dependendo de onde e como esse contrato é utilizado, voltar somente o executável pode criar outro problema.

Portanto:

Rollback é propriedade da arquitetura, não apenas comando da ferramenta de deployment.

Precisamos pensar em:

Code rollback
Data rollback
Schema rollback
Configuration rollback
Infrastructure rollback
Contract compatibility

Rick não inventaria o plano de fuga depois que a dimensão começasse a explodir.

Nós também não deveríamos.

---

🔥 CAPÍTULO 14 — RETRY NÃO É CURA UNIVERSAL

Pipeline falhou?

Alguém imediatamente propõe:

retry(5)

Rick pergunta:

"Por quê?"

Excelente pergunta.

Retry pode fazer sentido para uma falha transitória:

network timeout
temporary API failure
registry temporarily unavailable

Mas imagine:

COBOL COMPILATION ERROR

Retry.

Erro.

Retry.

Erro.

Retry.

Erro.

Você não criou resiliência.

Criou um computador extremamente persistente em provar cinco vezes que seu código está errado.

😂

Podemos pensar:

TRANSIENT FAILURE
      ↓
    RETRY

DETERMINISTIC FAILURE
      ↓
    INVESTIGATE

---

🕵️ CAPÍTULO 15 — RICK SANCHEZ VIRA ANALISTA DE ABEND

Pipeline:

FAILED

Isso é praticamente inútil sozinho.

Precisamos perguntar:

Onde?
Quando?
Qual stage?
Qual command?
Qual return code?
Qual agent?
Qual commit?
Qual artifact?
Qual dependency?

É exatamente a disciplina que o mainframer já conhece.

Imagine:

JOB FAILED

Tá.

E daí?

Queremos:

JOB
 ↓
STEP
 ↓
ABEND
 ↓
S0C7
 ↓
PROGRAM
 ↓
OFFSET
 ↓
FIELD
 ↓
RECORD
 ↓
ORIGIN

Ou seja:

SYMPTOM ≠ ROOT CAUSE

Um pipeline maduro precisa fornecer evidência suficiente para transformar:

"deu pau"

em:

Security stage failed
      ↓
dependency scan
      ↓
library X
      ↓
critical vulnerability
      ↓
version Y
      ↓
introduced by commit Z

Isso é investigação.

---

📊 CAPÍTULO 16 — OBSERVE A PRÓPRIA PIPELINE

Aqui existe um nível acima.

Não monitoramos apenas a aplicação.

Monitoramos a fábrica que produz a aplicação.

Podemos acompanhar:

Pipeline Success Rate
Build Duration
Queue Waiting Time
Deployment Frequency
Failure Rate
Rollback Rate
Mean Recovery Time
Flaky Tests
Agent Utilization
Approval Waiting Time

Imagine:

Checkout .......... 1 min
Build ............. 8 min
Tests ............ 14 min
Security .......... 5 min
Package ........... 2 min
Approval ..........32 min
Deploy ............ 7 min
Verify ............ 5 min

Tempo total:

74 minutos

Qual é o gargalo?

Compilador?

Não.

Jenkins?

Não.

Mainframe?

Não.

32 minutos esperando alguém aprovar.

Agora DevOps deixa de ser conversa sobre ferramenta e começa a revelar problemas do fluxo organizacional.

Isso é poderoso.

---

🧠 CAPÍTULO 17 — O QUE ESTAMOS REALMENTE VERSIONANDO?

Nos velhos tempos poderíamos pensar:

SOURCE CODE

Hoje estamos caminhando para algo muito maior:

Source Code
+
Build Definition
+
Tests
+
Infrastructure
+
Security Policies
+
Deployment Rules
+
Observability

Ou seja:

Não estamos versionando apenas o programa. Estamos tentando versionar o processo pelo qual esse programa nasce, é validado, autorizado, implantado e observado.

Esse é um dos aspectos mais interessantes de Pipeline as Code.

A documentação Jenkins trata o Jenkinsfile justamente como parte versionável do projeto, enquanto a IBM descreve pipelines z/OS combinando Git, DBB e outros componentes de CI/CD. (Jenkins)

---

🧓 CAPÍTULO 18 — O MAINFRAMER DE 1985 ENTRA NA GARAGEM DO RICK

Agora vem meu Easter Egg favorito.

Coloque um mainframer veterano diante destas expressões:

Pipeline as Code
Infrastructure as Code
Policy as Code
Immutable Artifact
Return Code
Dependency Management
Automated Scheduling
Audit Trail
Separation of Duties
Repeatable Build

Ele talvez fique alguns segundos em silêncio.

Tome um gole de café.

Olhe para Rick.

E diga:

"Então vocês passaram quarenta anos distribuindo tudo para finalmente descobrir que processos declarativos, controlados, auditáveis, repetíveis e cheios de return codes eram uma boa ideia?"

Rick olha para Morty.

Morty olha para Rick.

E ninguém responde.

☕😂

Naturalmente, mainframe tradicional e DevOps moderno são arquiteturas e ecossistemas profundamente diferentes.

Mas existe uma continuidade filosófica fascinante:

REPETIBILIDADE
CONTROLE
AUTOMAÇÃO
RASTREABILIDADE
EVIDÊNCIA

Isso sempre teve enorme valor em sistemas críticos.

---

🧪 EPÍLOGO — A PIPELINE NÃO TERMINA NO DEPLOY

Aqui está o erro que eu mais gostaria que um Junior Engineer evitasse.

Pensar:

DEPLOY SUCCESS

          FIM

Não.

Eu redesenharia mentalmente a última página do notebook assim:

                 SOURCE
                    ↓
                   GIT
                    ↓
                 JENKINS
                    ↓
             BUILD + TEST
                    ↓
                SECURITY
                    ↓
              QUALITY GATE
                    ↓
                ARTIFACT
                    ↓
              ENVIRONMENTS
                    ↓
                APPROVAL
                    ↓
               PRODUCTION
                    ↓
                 VERIFY
                    ↓
              OBSERVABILITY
                    ↓
          ┌───────────────────┐
          │ SYSTEM HEALTHY ?  │
          └─────────┬─────────┘
              YES   │   NO
               ↓    │    ↓
             DONE   │ RECOVERY
                    │    ↓
                    │ INVESTIGATION
                    │    ↓
                    │ ROOT CAUSE
                    │    ↓
                    └──→ FIX

Porque entregar software não significa apenas copiar um binário.

Significa conseguir demonstrar:

qual código foi utilizado, qual versão foi construída, quais testes foram executados, quais controles foram satisfeitos, qual artefato foi promovido, quem autorizou a mudança, onde ele foi implantado e o que aconteceu depois que usuários reais começaram a utilizá-lo.

É aí que Jenkins deixa de ser "aquele negócio que roda script".

Torna-se parte de uma cadeia de engenharia.

E quando trazemos isso para IBM Z, COBOL, CICS, Db2, MQ e sistemas de pagamentos, percebemos algo ainda mais interessante: não precisamos jogar fora décadas de disciplina operacional para adotar DevOps.

Podemos fazer justamente o contrário.

Podemos combinar:

DISCIPLINA DO MAINFRAME
          +
AUTOMAÇÃO DEVOPS
          +
PIPELINE AS CODE
          +
OBSERVABILIDADE
          =
ENTREGA MODERNA DE SISTEMAS CRÍTICOS

A documentação IBM atual recomenda uma abordagem CI/CD para z/OS que integra SCM baseado em Git, DBB e ferramentas corporativas de pipeline; DBB, inclusive, integra-se a Jenkins por CLI e suporta aplicações tradicionais COBOL e PL/I. (IBM)

E essa talvez seja a grande lição que Rick deixaria antes de desaparecer pelo portal:

"Morty, qualquer idiota consegue automatizar um deploy. Engenharia é automatizar as evidências de que aquilo deveria ter sido implantado — e saber exatamente como reagir quando não deveria."

☕🧪

No Bellacosa Mainframe, eu resumiria em uma frase ainda mais simples:

A PIPELINE NÃO TERMINA QUANDO O DEPLOY TERMINA.

Ela termina quando temos evidências suficientes de que a versão correta foi construída, testada, autorizada, implantada e continua funcionando corretamente em produção.

E se alguém discordar...

Rick já está carregando a portal gun. 🛸