 |
| Bellacosa Mainframe e o ci/cd para iniciantes, uma santa charada |
☕ Um Café no Bellacosa Mainframe
CI/CD sem Mistérios para Programadores COBOL
Quando Batman, Robin, GitHub Actions e Tekton Descobriram que um JOB JCL Também Pode Vestir uma Capa
"POW!"
"BAM!"
"ZAP!"
Imagine que você entrou em um Data Center da IBM em 1978.
De repente, a porta explode.
Surge Batman correndo pelos corredores do CPD.
Robin grita:
"Santo Pipeline, Batman! Alguém fez um deploy direto em produção!"
Batman olha para o console 3270.
Na tela aparece:
ABEND=S0C7
Batman suspira.
— Robin... alguém ignorou o CI.
Robin responde:
— E também esqueceu o CD...
Batman abaixa a cabeça.
— Chamem o Comissário Gordon.
Só que o Comissário Gordon, em 2026, atende pelo nome de GitHub Actions.
O verdadeiro vilão nunca foi o Git
Durante anos muitos programadores COBOL acreditaram que aprender Git era o grande desafio.
Depois vieram Docker.
Depois Kubernetes.
Depois YAML.
Depois Tekton.
Depois GitHub Actions.
Até que descobriram uma verdade curiosa.
Nenhuma dessas ferramentas é realmente difícil.
O difícil é entender como elas conversam entre si.
É exatamente isso que aprendemos ao longo do curso de Continuous Integration and Continuous Delivery (CI/CD).
E curiosamente...
Tudo faz muito sentido para quem já viveu dentro de um mainframe.
CI é apenas um JCL moderno
Essa frase costuma assustar desenvolvedores web.
Mas para quem programa COBOL...
Ela faz todo sentido.
Imagine um JOB.
STEP001
STEP002
STEP003
STEP004
Cada STEP depende do anterior.
Se um falha...
O JOB termina.
Agora troque:
STEP001 → Checkout
STEP002 → Compile
STEP003 → Teste
STEP004 → Deploy
Parabéns.
Você acabou de entender um Pipeline.
GitHub Actions é o novo JES2
No curso inteiro existe uma ferramenta protagonista.
GitHub Actions.
Ela observa o repositório.
Sempre que alguém faz:
git push
Ela acorda.
Como o JES2 recebendo um JOB.
Ela pega um arquivo chamado:
.github/workflows/workflow.yml
E executa exatamente o que está escrito ali.
Não pensa.
Não interpreta.
Não improvisa.
Ela apenas executa.
Como qualquer bom scheduler.
O Workflow
No curso aprendemos que todo Workflow precisa de quatro partes.
Evento
push
ou
pull_request
É o equivalente ao operador apertando ENTER.
Runner
ubuntu-latest
É a máquina onde tudo acontece.
Pense nela como um LPAR temporário.
Steps
Cada Step é um mini programa.
Exemplo:
Checkout
↓
Setup Node
↓
npm install
↓
ESLint
↓
Jest
No mainframe seria quase:
IEFBR14
↓
COBOL
↓
LINKEDIT
↓
TESTE
↓
EXECUÇÃO
O primeiro inimigo
Durante nosso projeto apareceu um erro curioso.
Recebemos nota zero.
Mas...
O CI estava verde.
Como isso era possível?
Batman chamou Alfred.
Alfred olhou cuidadosamente.
E respondeu:
"Mestre Bruce...
o problema não era o código.
Era o link."
Exatamente isso.
O Coursera esperava:
.github/workflows/workflow.yml
Nós enviamos:
workflow/
Resultado:
Zero.
Moral da história?
No mundo DevOps...
Caminhos importam.
Muito.
O AI Grader é como um compilador COBOL
Essa foi provavelmente a maior descoberta.
O avaliador automático não "entende" intenção.
Ele faz matching.
Se procura:
SERVICERUNNING
e você escreveu:
SERVICE RUNNING
Você perde ponto.
Mesmo estando correto.
Lembra bastante um compilador COBOL.
MOVE ZERO TO WS-TOTAL
é diferente de
MOVE ZEROS TO WS-TOTAL
Um detalhe muda tudo.
A importância dos Logs
Outro erro clássico.
Mandamos o log do GitHub Actions.
Mas a questão queria:
oc logs
Ou seja...
Logs da aplicação.
Não do pipeline.
Batman diria:
"Robin...
não investigue o Batmóvel quando o crime aconteceu dentro do Banco de Gotham."
O mistério do PVC
Durante o laboratório apareceu outro personagem.
pipeline-pvc
Muita gente acha que é apenas um volume.
Mas ele é muito mais.
É o HD temporário do Pipeline.
Imagine um SORT usando um dataset intermediário.
Sem ele...
O STEP seguinte não encontra nada.
No Tekton acontece igual.
Cada Task compartilha arquivos usando Workspaces.
E quem sustenta isso?
O PVC.
Tekton
Se GitHub Actions faz CI...
Tekton faz CD.
Ele possui três personagens.
Task
Uma única ação.
Como:
Lint
ou
Test
Pipeline
O roteiro completo.
Cleanup
↓
Git Clone
↓
ESLint
↓
Jest
↓
Buildah
↓
Deploy
PipelineRun
A execução.
Pense nela como:
SUBMIT JOB
Buildah
Muitos imaginam que Buildah é parecido com Docker.
Na prática...
Ele fabrica imagens OCI.
No curso ele aparece depois do Jest.
Porque primeiro validamos.
Depois construímos.
Nunca o contrário.
Deploy
A última etapa.
oc set image
troca a imagem do Deployment.
É o equivalente moderno do:
NEW LOAD MODULE
no mainframe.
Plano de Estudos para um Programador COBOL Júnior
Semana 1 — Git e GitHub
Objetivo:
Repositórios
Branches
Commits
Pull Requests
Prática:
Criar um repositório de exemplo.
Fazer commits pequenos e descritivos.
Aprender a resolver conflitos simples.
Semana 2 — GitHub Actions
Objetivo:
Workflow
Runner
Jobs
Steps
Exercício:
Criar um Workflow que execute:
npm install
↓
npm run lint
↓
npm test
Analogia mainframe:
Cada Step é como um EXEC em um JOB JCL.
Semana 3 — Testes Automatizados
Objetivo:
Jest
Cobertura
Qualidade
Prática:
Escrever testes para funções simples.
Corrigir falhas até obter pipeline verde.
Semana 4 — YAML
Objetivo:
Sintaxe
Indentação
Estruturas
Dica:
YAML não perdoa espaços errados.
Assim como JCL não perdoa colunas erradas.
Semana 5 — OpenShift
Objetivo:
Projetos (Namespaces)
Pods
Deployments
Services
Routes
Prática:
Implantar uma aplicação simples.
Consultar logs com
oc logs.Explorar recursos com
oc geteoc describe.
Semana 6 — Tekton
Criar:
✔ Task
✔ Pipeline
✔ PipelineRun
Depois:
Cleanup
↓
Clone
↓
Lint
↓
Test
↓
Build
↓
Deploy
Semana 7 — Observabilidade
Aprender:
oc logs
oc describe
oc get pods
oc get pvc
oc get pipelineruns
Um bom DevOps passa mais tempo lendo logs do que escrevendo YAML.
Semana 8 — Projeto Final
Monte seu próprio pipeline.
Colete evidências.
Revise links.
Valide nomes de arquivos.
Simule a submissão.
E só então envie.
Dicas de Ouro
Faça commits pequenos e frequentes.
Nunca envie um pipeline sem executá-lo.
Leia cuidadosamente o texto das questões: muitas reprovações acontecem por responder com um link quando era pedido um log, ou vice-versa.
Use nomes consistentes para arquivos e Tasks.
Guarde capturas de tela e saídas de terminal conforme o laboratório exige.
Easter Eggs Bellacosa Mainframe
Bat-Sinal = GitHub Actions: quando há um
push, o sinal acende e o pipeline entra em ação.Robin = Jest: sempre conferindo se Batman não esqueceu de testar.
Alfred = ESLint: discreto, elegante e sempre apontando os pequenos defeitos antes que virem um desastre.
Comissário Gordon = OpenShift Console: mostra a situação da cidade (ou do cluster) em tempo real.
Batmóvel = PipelineRun: é ele que coloca toda a operação em movimento.
Caverna do Batman = Data Center: cheia de equipamentos, monitores e automação.
Coringa = Deploy direto em produção sem testes: divertido por alguns segundos... até tudo explodir.
A Grande Lição
O curso de CI/CD ensina ferramentas, mas a verdadeira habilidade adquirida é pensar em automação, repetibilidade e qualidade.
Para um programador COBOL, isso não é um mundo totalmente novo. É uma evolução natural de conceitos que já existem há décadas em ambientes corporativos: execução em etapas, validações, logs, artefatos, controle de versões e disciplina operacional.
Quando você percebe isso, GitHub Actions deixa de ser uma novidade assustadora. Tekton deixa de parecer um enigma. YAML deixa de ser apenas uma linguagem cheia de espaços.
Você passa a enxergar que, por trás das tecnologias modernas, continuam existindo os mesmos princípios que fizeram o mainframe sobreviver por mais de sessenta anos: planejamento, confiabilidade, automação e controle.
E talvez seja esse o maior "POW!", "BAM!" e "ZAP!" desta aventura: descobrir que o herói nunca foi a ferramenta. O verdadeiro herói sempre foi o profissional que entende o processo inteiro e faz com que ele funcione de forma previsível, segura e elegante — seja em um terminal 3270, em um pipeline do GitHub Actions ou em um cluster OpenShift.
Sem comentários:
Enviar um comentário