CI/CD no Mainframe: o que funciona, o que é mito e o que ninguém te contou

por El Jefe – Midnight Lunch

Durante anos, falar de CI/CD e mainframe na mesma frase era quase heresia.
De um lado, o discurso moderno: Git, pipelines, YAML, automação total.
Do outro, o mundo real: COBOL, JCL, CICS, batch crítico, auditoria, SLA e medo justificado de quebrar produção.

A boa notícia?
CI/CD é possível no mainframe.
A má notícia?
Não do jeito que a galera cloud imagina.

Este artigo não é evangelização. É sobrevivência técnica.

---

Antes de tudo: CI/CD não é ferramenta, é disciplina

O maior erro ao tentar “modernizar” o mainframe é achar que CI/CD é instalar Jenkins, Tekton ou OpenShift.

CI/CD é:

• controle rigoroso de mudanças

• builds reproduzíveis

• rastreabilidade

• automação com governança

• rollback possível (e rápido)

Curiosamente, o mainframe sempre fez isso — só não chamava assim.

Endevor, ChangeMan, ISPW:

• controlam versão

• impõem fluxo

• exigem aprovação

• deixam rastro para auditoria

Ou seja:
o mainframe não está atrasado — ele só não usa camiseta preta escrito DevOps.

---

Onde o Git entra (e onde ele não manda)

Git é excelente para:

• versionar código-fonte

• colaboração entre times

• automação de gatilhos (webhooks)

• integração com pipelines modernos

Mas Git não substitui:

• controle de promoção entre ambientes críticos

• segregação de funções exigida por auditoria

• governança de produção Z/OS

Por isso, o modelo que funciona não é Git versus Endevor.
É Git + Endevor.

Modelo realista (e profissional)

• Git → source of collaboration

• Endevor → source of control

• Pipeline → ponte automatizada

Quem tenta matar o Endevor normalmente aprende da pior forma:
na auditoria… ou no incidente.

---

CI no mainframe: sim, dá — e dá bem

Integração Contínua em mainframe significa:

1. Commit COBOL no Git

2. Pipeline dispara:

   • análise estática (ex: Sonar, AppScan)

   • build automatizado (DBB)

   • compilação com dependências reais

3. Geração de artefatos rastreáveis

4. Publicação de evidências

Ferramentas comuns:

• IBM Dependency Based Build (DBB)

• Jenkins / Tekton

• Scripts Z/OS

• Analisadores estáticos

Nada mágico.
Nada “low-code milagroso”.
Só engenharia.

---

CD no mainframe: aqui mora o respeito

Entrega Contínua no mainframe não é deploy automático em produção.

É:

• promoção controlada

• aprovação explícita

• janela operacional

• rollback testado

O pipeline:

• prepara

• valida

• evidencia

Quem promove para produção continua sendo:

• o change

• a operação

• o processo

E isso não é atraso — é responsabilidade.

---

YAML no mainframe: vilão ou aliado?

YAML não é moda.
É apenas uma forma declarativa de dizer:

“este é o pipeline, nesta ordem, com estas regras”

Ele não substitui JCL.
Ele orquestra.

YAML:

• define pipelines

• descreve estágios

• integra ferramentas

JCL:

• executa trabalho pesado

• fala direto com o Z

Quem confunde os dois costuma quebrar um ou outro.

---

GitOps: ótimo… com limites claros

GitOps funciona muito bem para:

• Kubernetes

• ambientes declarativos

• infra elástica

No mainframe:

• GitOps não governa produção

• GitOps não substitui change

• GitOps não remove segregação

Mas ele ajuda:

• na camada distribuída

• no controle de pipelines

• na padronização

Argo CD conversa com OpenShift.
O OpenShift conversa com pipelines.
O pipeline conversa com o mainframe.

Esse é o desenho correto.

---

O anti-pattern clássico (e perigoso)

“Vamos colocar produção Z controlada direto por Git”

Tradução:

• auditoria reprovada

• operação em pânico

• arquiteto desempregado

Modernizar não é destruir o que funciona.
É integrar com inteligência.

---

O verdadeiro estado da arte

Hoje, ambientes maduros fazem:

• Git para código

• Pipeline CI automatizado

• DBB para build real

• Endevor para promoção

• Evidência para compliance

• Observabilidade para melhoria contínua

Sem hype.
Sem discurso de palco.
Com produção estável.

---

Conclusão: CI/CD no mainframe é engenharia adulta

Mainframe não precisa virar cloud.
Precisa conversar com ela.

CI/CD no Z:

• é possível

• é poderoso

• exige respeito ao contexto

Quem entende isso não briga com a plataforma.
E quem não entende… escreve post chamando o mainframe de legado morto.

Nós sabemos quem continua pagando o salário no fim do mês.

---

🕛 El Jefe – Midnight Lunch
Onde DevOps encontra o mundo real e sobrevive.

UrbanCode DBB: Controle de Versionamento no Mainframe, do Jeito Certo

Se você já trabalhou em mainframe, sabe que cada linha de código é sagrada. Um erro de versionamento e você pode acordar com todo o departamento olhando para você como se tivesse errado o compilador na sexta-feira à tarde. Foi justamente pensando nisso que nasceu o UrbanCode DBB, o guardião do código COBOL, PL/I, Assembler, JCL e tudo mais que roda em z/OS.

História e Origem

O DBB, que significa Dependency Based Build, começou sua vida nos laboratórios da IBM como uma forma de modernizar o build de aplicações mainframe. A ideia era simples: parar de depender de scripts complicados de JCL e REXX espalhados pelo servidor e criar algo que entendesse as dependências reais do seu código.

Em 2016, o UrbanCode comprou a tecnologia e integrou no seu portfólio de DevOps, transformando o DBB numa peça central para mainframe moderno, pronto para integração com pipelines CI/CD, Git, Jenkins e até o mundo do container e cloud.

Para que serve e por que usar

Imagine o seu sistema legado com dezenas de programas COBOL interdependentes. Alterou um copybook ou uma tabela DB2? Então você precisa recompilar tudo que depende disso, mas somente o que realmente depende. Aqui entra o DBB:

• Detecção de dependências: Ele analisa seu código e entende as relações entre programas, módulos e copybooks.

• Build incremental inteligente: Só recompila o que precisa, economizando horas de batch.

• Integração DevOps: Pode ser chamado por Jenkins, GitLab, UrbanCode Deploy, tornando o mainframe parte do fluxo ágil.

Em resumo: DBB é o cupido do build, unindo o que mudou com o que precisa mudar.

Como usar: dicas práticas

1. Estrutura de projetos: Organize seu código como projetos, módulos e pacotes. DBB adora clareza.

2. Dependência declarativa: Marque copybooks, DB2 DDL e includes. Quanto mais informação ele tiver, mais eficiente será o build.

3. Log e rastreabilidade: Sempre revise os logs. DBB é detalhista — ele te conta cada recompilação que fez.

4. Pipeline CI/CD: Integre DBB ao Jenkins ou UrbanCode Deploy para builds automáticos e consistentes.

Exemplo básico

Imagine que você tem um programa PAYROLL que depende de EMPLOYEE e SALARY. Se você altera apenas SALARY, DBB identifica que apenas PAYROLL precisa de recompilação, poupando tempo e evitando que outros programas sejam recompilados desnecessariamente.

PROJECT PAYROLL
   MODULE EMPLOYEE
   MODULE SALARY
   MODULE PAYROLL
   DEPENDS_ON SALARY, EMPLOYEE
ENDPROJECT

Simples, mas poderoso.

Curiosidade e Easter Egg

Você sabia que o DBB foi inspirado em técnicas de build usadas em ambientes UNIX? A diferença é que ele traduziu essas ideias para o z/OS, entendendo a complexidade do JCL, copybooks e DB2.

E o easter egg? Se você examinar os logs detalhados, verá pequenos comentários de debug deixados pelos engenheiros: mensagens como "Aqui mora o fantasma do COBOL" ou "Não acorde o compilador antes do café"… só quem vive de batch entende.

Comentários finais

O DBB é um salvavidas para equipes que querem DevOps sem abandonar o mainframe. Ele reduz erros, agiliza deploys e ainda preserva aquela aura mística de que o código mainframe “funciona sozinho, mas precisa de respeito”.

Se você ainda não experimentou, vale a pena. Modernizar builds não é apenas um luxo, é sobre manter a sanidade e ganhar tempo para o café da tarde.