Git, GitHub e DevOps para Profissionais IBM Z Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

 

Bellacosa Mainframe e o Git Github e DevOps para Mainframers

☕🚀 Um Café no Bellacosa Mainframe

Git, GitHub e DevOps para Profissionais IBM Z

Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

"Deleted your code by mistake? Without Git, it's gone forever."

Confesso que, ao observar aqueles infográficos coloridos sobre Git e DevOps, senti algo curioso.

Em poucos segundos eles conseguiram condensar uma transformação tecnológica que levou quase quarenta anos para acontecer.

Para muitos jovens desenvolvedores, Git sempre existiu.

Para nós, veteranos do Mainframe, sabemos que não foi assim.

Nós vivemos outra realidade.

Vivemos a era dos datasets PDS.

Vivemos a era dos backups manuais.

Vivemos a era do Panvalet.

Do Librarian.

Do Endevor.

Do Changeman.

Do SCLM.

Do ISPW.

Do membro COBOL001.

Do COBOL001.BKP.

Do COBOL001.OLD.

Do COBOL001.TESTE.

Do COBOL001.NOVO.

Do COBOL001.NOVO2.

Do COBOL001.NOVO3.

E, inevitavelmente, do lendário:

COBOL001.FINAL

COBOL001.FINAL2

COBOL001.FINAL_DEFINITIVO

COBOL001.FINAL_DEFINITIVO_OK

COBOL001.AGORA_VAI

Parece piada.

Mas muitos de nós trabalhamos exatamente dessa maneira.

E foi justamente para resolver esse caos que surgiu uma das ferramentas mais importantes da história da Engenharia de Software.

Git.

E não estou exagerando.

Git talvez seja tão revolucionário para o desenvolvimento moderno quanto o JES2 foi para processamento batch, quanto o CICS foi para processamento online ou quanto o DB2 foi para persistência transacional.

Git mudou a maneira como produzimos software.

Bellacosa Mainframe e a evolucao da gestao dos fontes

A primeira geração do controle de versões

Antes do Git existiam várias abordagens.

RCS.

SCCS.

CVS.

Visual SourceSafe.

Subversion.

ClearCase.

Perforce.

Cada um tentou resolver o mesmo problema.

Como permitir que múltiplas pessoas trabalhem no mesmo código sem destruir o trabalho umas das outras?

No Mainframe, resolvemos isso de forma diferente.

Panvalet.

Librarian.

Endevor.

ISPW.

Changeman.

Essas ferramentas foram brilhantes.

E continuam sendo.

Especialmente em ambientes regulados.

Bancos.

Seguradoras.

Governo.

Utilities.

Mas havia uma diferença.

Grande parte delas era centralizada.

Tudo dependia de um servidor.

Git mudou isso.

Git é distribuído.

E isso altera completamente a arquitetura do desenvolvimento.

O que realmente é Git?

A maioria dos cursos ensina:

Git é um sistema de versionamento.

Tecnicamente está correto.

Mas é uma definição pobre.

Git é muito mais.

Git é um banco de dados.

Git é uma máquina do tempo.

Git é um mecanismo de auditoria.

Git é uma ferramenta de colaboração.

Git é um sistema de rastreabilidade.

Git é um gatilho para automação.

Git é praticamente o sistema nervoso central do DevOps moderno.

Cada commit registra:

Quem alterou.

Quando alterou.

Por que alterou.

Qual requisito atendeu.

Qual incidente corrigiu.

Qual sprint participou.

Qual história de usuário foi implementada.

Qual vulnerabilidade foi mitigada.

Git não apenas salva arquivos.

Git preserva conhecimento organizacional.

O segredo escondido do Git

Poucos profissionais conhecem sua arquitetura interna.

Git não armazena arquivos.

Git armazena objetos.

Blob.

Tree.

Commit.

Tag.

Blob representa dados.

Tree representa diretórios.

Commit representa estados.

Tag representa marcos.

Cada commit possui um hash.

Durante muitos anos SHA-1.

Hoje caminhando para SHA-256.

Um commit não é uma diferença.

Ele é uma fotografia completa.

Um snapshot.

É por isso que Git consegue voltar meses no passado.

Como um SMF para código-fonte.

Aliás...

Talvez essa seja a analogia perfeita para um sysprog.

Git é quase um SMF de desenvolvimento.

Cada alteração gera um registro permanente.

O Sysprog e o Git

Talvez alguns sysprogs pensem:

"Mas Git é coisa de desenvolvedor."

Não.

Não mais.

Hoje praticamente toda infraestrutura está migrando para Infrastructure as Code.

Parmlibs.

Policies.

WLM.

NetView.

SA z/OS.

Ansible.

Terraform.

Scripts REXX.

Procedures.

JCL.

USS scripts.

Tudo pode estar em Git.

Imagine uma alteração em uma política WLM.

Antigamente:

Editar.

Salvar.

Copiar.

Torcer.

Hoje:

Criar branch.

Modificar.

Commit.

PR.

Review.

Merge.

Deploy automatizado.

Rollback imediato.

A governança melhora absurdamente.

O Sysadmin moderno também virou desenvolvedor

Existe uma transformação interessante acontecendo.

Sysadmins estão programando.

Desenvolvedores estão automatizando infraestrutura.

DBAs escrevem pipelines.

Sysprogs utilizam APIs REST.

Todos começam a convergir.

A linha entre operações e desenvolvimento desaparece.

Foi exatamente isso que criou DevOps.

DevOps não é ferramenta

Essa talvez seja a maior confusão do mercado.

DevOps não é Jenkins.

Não é GitHub.

Não é Kubernetes.

Não é Docker.

Não é Ansible.

DevOps é cultura.

É reduzir silos.

Eliminar burocracias.

Aproximar pessoas.

Automatizar processos.

Aumentar feedback.

Reduzir tempo de entrega.

No Mainframe isso é extremamente relevante.

Porque o Mainframe sempre teve uma cultura muito compartimentalizada.

Equipe COBOL.

Equipe DB2.

Equipe CICS.

Equipe Storage.

Equipe RACF.

Equipe Sysprog.

Equipe Operações.

Equipe Middleware.

Equipe Rede.

Equipe Segurança.

DevOps propõe outra visão.

Todos trabalham pelo mesmo objetivo.

Entregar valor ao negócio.

GitHub não é Git

Muitos iniciantes confundem.

Git é tecnologia.

GitHub é plataforma.

GitLab é plataforma.

Bitbucket é plataforma.

Azure DevOps é plataforma.

Git continua sendo Git.

Independentemente da hospedagem.

GitHub adicionou uma camada extremamente poderosa.

Issues.

Actions.

Codespaces.

Security.

Dependabot.

Packages.

Container Registry.

Wiki.

Pull Requests.

Tudo integrado.

Pull Request: a maior revolução social do desenvolvimento

Eu particularmente considero Pull Request uma das melhores invenções da engenharia moderna.

Porque ela resolve algo difícil.

Compartilhar conhecimento.

Imagine um desenvolvedor COBOL júnior.

Ele escreve:

MOVE WS-CPF TO WS-TEMP

Um desenvolvedor sênior comenta:

"Poderíamos validar antes."

Outro comenta:

"Talvez usar EVALUATE seja melhor."

Outro:

"Precisamos mascarar LGPD."

Resultado?

O código melhora.

O profissional melhora.

A equipe melhora.

A empresa melhora.

PR é mentoria embutida.

O medo do merge conflict

Todo desenvolvedor já sentiu frio na barriga.

git pull

CONFLICT

Automatic merge failed.

Para iniciantes parece um desastre.

Para equipes maduras é rotina.

Conflitos indicam colaboração.

Duas pessoas trabalharam na mesma área.

Git apenas pede ajuda.

Ele não consegue decidir sozinho.

Você decide.

Git apenas documenta.

Git Flow versus GitHub Flow

Durante anos utilizamos Git Flow.

Main.

Develop.

Feature.

Release.

Hotfix.

Funciona muito bem.

Especialmente em bancos.

Porém empresas modernas começaram simplificar.

GitHub Flow.

Main.

Feature.

PR.

Merge.

Deploy.

Google foi além.

Trunk Based Development.

Branches curtíssimas.

Commits pequenos.

Integração contínua.

Menos divergência.

Menos conflitos.

Mais velocidade.

Git para COBOL Developers

Aqui entramos em um ponto fascinante.

Durante muito tempo dizia-se:

COBOL não combina com Git.

Hoje isso é completamente falso.

IBM DBB.

IBM Dependency Based Build.

zAppBuild.

Z Open Editor.

Rocket Git.

Git Integration for Endevor.

ISPW Git Integration.

IDz.

Wazi Developer.

VS Code.

Tudo isso mudou o cenário.

Hoje um desenvolvedor COBOL pode trabalhar assim.

Abrir VS Code.

Editar programa COBOL.

Executar testes.

Commit.

Push.

Criar PR.

Executar pipeline.

Compilar.

Linkedit.

DB2 Bind.

Newcopy CICS.

Deploy.

Exatamente como Java.

Exatamente como Python.

Exatamente como Node.

Jenkins: o operador automático

Se Git é o cérebro.

Jenkins é o operador.

Ele observa commits.

Dispara builds.

Executa testes.

Compila COBOL.

Gera relatórios.

Aciona SonarQube.

Publica artefatos.

Executa deploy.

Notifica equipes.

No fundo, Jenkins faz o papel que muitos operadores humanos executavam.

Só que 24 horas por dia.

Sem esquecer etapas.

Sem distrações.

GitOps: talvez a próxima revolução

GitOps é simples.

Tudo é Git.

Deseja mudar um cluster Kubernetes?

Commit.

Deseja alterar firewall?

Commit.

Deseja atualizar pipeline?

Commit.

Deseja modificar política?

Commit.

Git torna-se a fonte única da verdade.

Single Source of Truth.

Isso é extremamente poderoso.

Porque elimina configurações manuais.

Elimina servidores "snowflake".

Elimina ambientes misteriosos.

Tudo fica reproduzível.

E a segurança?

Segurança também mudou.

DevSecOps nasceu justamente aqui.

SAST.

DAST.

Dependency Scan.

Secrets Detection.

SBOM.

Tudo integrado ao pipeline.

O desenvolvedor faz commit.

Ferramentas verificam.

Bibliotecas vulneráveis.

Credenciais expostas.

Falhas conhecidas.

Antes de chegar em produção.

No Mainframe isso pode incluir:

RACF reviews.

JCL analysis.

CICS security checks.

DB2 privilege validation.

SMF auditing.

O papel do Sysprog em 2026

Antigamente o Sysprog era apenas administrador.

Hoje é arquiteto.

Automatizador.

Consultor.

Especialista em APIs.

Especialista em observabilidade.

Especialista em pipelines.

Especialista em integração.

Especialista em segurança.

Sysprog moderno entende:

Git.

GitHub.

GitLab.

Ansible.

Python.

REXX.

Jenkins.

OpenShift.

Containers.

z/OSMF.

Zowe.

REST APIs.

Porque o Mainframe deixou de ser uma ilha.

Ele tornou-se parte do ecossistema corporativo.

O novo profissional IBM Z

Acredito que o profissional IBM Z de maior valor em 2026 possui uma característica interessante.

Ele pensa como um desenvolvedor.

Age como um administrador.

Automatiza como um engenheiro DevOps.

Protege como um especialista em segurança.

E governa como um arquiteto.

Ele consegue conversar com:

Desenvolvedor Java.

Equipe Cloud.

Kubernetes.

Segurança.

Storage.

Networking.

Data Science.

IA.

Sem abandonar aquilo que torna o Mainframe único.

Confiabilidade.

Escalabilidade.

Disponibilidade.

Integridade transacional.

Processamento massivo.

Pensando durante o café

Talvez a grande mensagem escondida por trás daqueles simpáticos desenhos coloridos seja esta:

Git não substitui o conhecimento Mainframe.

Git potencializa o conhecimento Mainframe.

Ele não aposenta COBOL.

Ele amplia o alcance do COBOL.

Ele não elimina o Sysprog.

Ele transforma o Sysprog em um engenheiro de plataforma.

Ele não mata operações.

Ele automatiza operações repetitivas.

A próxima geração de profissionais IBM Z provavelmente não conhecerá Panvalet.

Talvez nunca utilize Librarian.

Possivelmente jamais veja um Changeman clássico.

Mas certamente abrirá um Pull Request.

Criará uma branch.

Executará uma pipeline.

Fará deploy automatizado.

E continuará processando bilhões de transações por dia em um IBM Z.

Porque, no final das contas, o objetivo nunca foi Git.

Nunca foi GitHub.

Nunca foi Jenkins.

Nunca foi Kubernetes.

O objetivo sempre foi o mesmo desde os tempos do System/360.

Entregar software confiável.

Mais rápido.

Mais seguro.

Mais auditável.

Mais sustentável.

E, se possível, com uma boa xícara de café ao lado do teclado 3270.

Neo COBOL : Como Git, VS Code, APIs, Zowe, DevOps e Inteligência Artificial Estão Transformando o Desenvolvimento Mainframe

Bellacosa Mainframe e o que há de mais moderno no COBOL

☕💣🚀 PADAWAN, O COBOL FUGIU DO TERMINAL VERDE!

Como Git, VS Code, APIs, Zowe, DevOps e Inteligência Artificial Estão Transformando o Desenvolvimento Mainframe

Existe uma pergunta que aparece em praticamente toda palestra sobre Mainframe.

Ela normalmente vem de alguém que nunca trabalhou com IBM Z.

Às vezes é um estudante.

Às vezes é um programador Java.

Às vezes é um gerente recém-chegado ao mundo corporativo.

A pergunta é sempre a mesma:

— Mas COBOL ainda existe?

E eu sempre respondo:

— Não apenas existe. Ele movimenta boa parte da economia mundial enquanto você dorme.

O mais curioso é que o COBOL de hoje não se parece nem um pouco com a imagem que muita gente guarda na cabeça.

Quando alguém fala em COBOL, normalmente imagina uma sala escura, um operador digitando comandos em uma tela verde, um terminal 3270 piscando e um monte de programas escritos há cinquenta anos.

Essa imagem até possui um fundo de verdade.

Mas ela representa apenas uma pequena parte da história.

A realidade é que o Mainframe passou por uma transformação silenciosa que poucas pessoas fora do mercado IBM perceberam.

E talvez essa seja uma das maiores revoluções tecnológicas dos últimos anos.

---

O Gigante Invisível Nunca Foi Embora

Enquanto o mundo discutia startups, aplicativos móveis e computação em nuvem, o Mainframe continuava fazendo aquilo que sempre fez melhor:

Processar volumes absurdos de dados com segurança, disponibilidade e confiabilidade.

Hoje ele continua presente em:

• Bancos

• Seguradoras

• Bolsas de valores

• Governos

• Operadoras de cartão

• Empresas aéreas

• Sistemas de saúde

Bilhões de transações passam diariamente por sistemas COBOL.

Grande parte do dinheiro que circula pelo planeta toca algum programa COBOL em algum momento da jornada.

O curioso é que quase ninguém percebe isso.

Por isso costumo chamar o Mainframe de:

O Gigante Invisível da Computação.

---

O Dia em Que o Mainframe Conheceu o VS Code

Durante décadas o ambiente clássico de desenvolvimento foi dominado por ferramentas tradicionais como:

• ISPF

• TSO

• SDSF

• Editores 3270

Essas ferramentas continuam extremamente importantes.

Mas a nova geração de desenvolvedores cresceu usando interfaces gráficas, IDEs modernas e integração contínua.

A IBM percebeu isso.

O resultado foi uma mudança histórica.

Hoje um programador COBOL pode desenvolver utilizando:

• Visual Studio Code

• Git

• GitHub

• GitHub Actions

• APIs REST

• Zowe Explorer

Ou seja:

O desenvolvedor pode trabalhar em uma interface praticamente idêntica à utilizada por equipes Java, Python ou JavaScript.

A barreira psicológica que separava o Mainframe do restante da indústria começou a desaparecer.

---

Zowe: A Ponte Entre Dois Mundos

Talvez nenhuma ferramenta tenha simbolizado tanto essa transformação quanto o Zowe.

Criado sob o guarda-chuva do Open Mainframe Project, o Zowe funciona como uma ponte entre o universo moderno de desenvolvimento e o ambiente IBM Z.

Com ele é possível:

• Navegar em datasets

• Visualizar jobs

• Consultar JES

• Trabalhar com USS

• Automatizar tarefas

• Consumir APIs do z/OS

Tudo isso sem sair do VS Code.

Para quem cresceu usando ISPF, a experiência parece quase mágica.

Para quem veio do mundo distribuído, finalmente o Mainframe passa a parecer familiar.

---

Open Mainframe Project: O Movimento Que Mudou Tudo

Durante muitos anos existiu um mito.

O mito dizia que Mainframe era uma tecnologia fechada.

Que tudo era proprietário.

Que inovação só acontecia fora desse ambiente.

Então surgiu o Open Mainframe Project.

A iniciativa passou a reunir:

• IBM

• Bancos

• Universidades

• Comunidade Open Source

• Grandes empresas globais

O objetivo era simples:

Modernizar o ecossistema sem destruir aquilo que o tornou confiável.

Foi dessa iniciativa que nasceram diversos projetos fundamentais.

Entre eles:

• Zowe

• COBOL Check

• Z Open Editor

• Mentorship Programs

• Cursos gratuitos

O resultado foi um crescimento enorme da comunidade.

---

O Git Finalmente Chegou ao Mainframe

Antigamente o controle de versões era feito através de soluções corporativas específicas.

Hoje a realidade mudou.

Git tornou-se parte integrante do desenvolvimento Mainframe moderno.

Agora podemos:

• Criar branches

• Fazer merge

• Abrir pull requests

• Revisar código

• Automatizar validações

Exatamente como acontece no restante da indústria.

O Mainframe deixou de ser uma ilha.

Ele tornou-se mais um participante do ecossistema DevOps.

---

DevOps Não É Apenas Moda

Existe quem pense que DevOps é apenas uma palavra bonita para colocar em apresentações.

Não é.

DevOps representa uma mudança cultural profunda.

No passado era comum ver equipes divididas:

Desenvolvimento de um lado.

Operação do outro.

Cada grupo trabalhando isoladamente.

Hoje o objetivo é integração.

Automação.

Colaboração.

Velocidade.

Qualidade.

E o IBM Z abraçou completamente essa filosofia.

---

CI/CD Também Chegou ao COBOL

Um dos maiores choques para quem está entrando no mercado Mainframe é descobrir que existem pipelines CI/CD para COBOL.

Sim.

Pipelines completos.

O fluxo pode ser algo como:

Commit → Build → Testes → Deploy → Produção

Ferramentas modernas como:

• GitHub Actions

• Jenkins

• DBB

• UrbanCode

• Zowe CLI

permitem automatizar praticamente todo o ciclo de desenvolvimento.

O mesmo conceito utilizado em aplicações web agora pode ser aplicado a programas COBOL.

---

Testes Automatizados: O JUnit do Mainframe

Durante muito tempo existiu a falsa ideia de que COBOL não possuía testes unitários.

Hoje isso está completamente ultrapassado.

Ferramentas como COBOL Check permitem:

• Criar testes automatizados

• Validar regras de negócio

• Executar regressões

• Integrar com pipelines DevOps

O conceito é muito parecido com:

• JUnit

• NUnit

• PyTest

A diferença é que agora estamos falando de COBOL.

Isso reduz riscos.

Melhora qualidade.

E aumenta a confiança durante mudanças em sistemas críticos.

---

APIs: O Mainframe Conversa Com Tudo

Outro mito clássico:

"O Mainframe é isolado."

Errado.

O Mainframe moderno conversa com praticamente qualquer tecnologia.

Hoje é comum encontrar:

• APIs REST

• Serviços Web

• JSON

• XML

• Kafka

• MQ

• Cloud

Um programa COBOL pode ser chamado por:

• Aplicativos móveis

• Sites

• Microserviços

• Plataformas em nuvem

A integração tornou-se um dos pilares da modernização.

---

UTF-8: O COBOL Aprendeu Novos Idiomas

Durante décadas os sistemas corporativos lidaram principalmente com conjuntos de caracteres tradicionais.

Agora o mundo é global.

Precisamos lidar com:

• Português

• Japonês

• Chinês

• Árabe

• Emojis

O Enterprise COBOL evoluiu para suportar:

• UTF-8

• NATIONAL

• Dynamic-Length Items

Isso abre portas para aplicações verdadeiramente globais.

---

Multithreading e Performance

Outra área de enorme evolução foi a capacidade de execução paralela.

Recursos modernos permitem:

• Multithreading

• THREAD Compiler Option

• LOCAL-STORAGE

• THREADSAFE

Isso significa melhor aproveitamento dos recursos do hardware IBM Z.

E quando falamos de IBM Z, estamos falando de uma das plataformas mais poderosas já criadas para processamento transacional.

---

O Papel da Inteligência Artificial

Talvez estejamos entrando na fase mais interessante da história do Mainframe.

A Inteligência Artificial começou a chegar ao ambiente IBM Z.

Hoje já vemos:

• Assistentes de código

• Geração automática de documentação

• Explicação de programas legados

• Conversão de código

• Análise de impacto

• Apoio à modernização

Ferramentas como GitHub Copilot, Watsonx e soluções corporativas especializadas estão transformando a forma como trabalhamos.

O desenvolvedor deixa de gastar energia com tarefas repetitivas e passa a focar na lógica de negócio.

---

O Novo Programador Mainframe

O mercado mudou.

O profissional mais valorizado não é apenas aquele que conhece COBOL.

Nem apenas aquele que conhece DevOps.

O profissional mais procurado é aquele que consegue unir os dois mundos.

O desenvolvedor moderno entende:

• COBOL

• JCL

• DB2

• CICS

• Git

• APIs

• VS Code

• Zowe

• DevOps

• CI/CD

• Testes automatizados

Ele compreende o legado.

Mas também compreende a inovação.

E essa combinação é extremamente rara.

---

O Futuro Já Chegou

Muitas pessoas continuam esperando o fim do Mainframe.

Esperam isso há décadas.

Enquanto isso, o IBM Z continua evoluindo.

Continua processando bilhões de transações.

Continua movimentando bancos.

Continua sustentando governos.

Continua integrando-se com nuvem, APIs, DevOps e Inteligência Artificial.

Talvez a maior surpresa não seja que o Mainframe tenha sobrevivido.

Talvez a maior surpresa seja perceber que ele nunca esteve tão moderno.

E aqui está a lição mais importante desta história.

☕💣🚀

OPERADOR, O COBOL NÃO FICOU PRESO NO PASSADO.

ELE SIMPLESMENTE ESPEROU O RESTO DA INDÚSTRIA ALCANÇÁ-LO.

Este texto já está pronto para publicação no Blogspot, LinkedIn Articles ou newsletter "Um Café no Bellacosa Mainframe".

 

Bellacosa Mainframe apresenta o GIT para padawans em Mainframe

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe

---

🧠 Contexto: Antes era “impossível”… hoje é padrão

Em 2018, falar de git rodando dentro do z/OS era quase heresia.

• Não existia Z Open Automation Utilities
• Open Source no mainframe? Ainda engatinhando
• DevOps? Só no mundo distribuído

Hoje… 👇
👉 Temos comunidade ativa
👉 Bash rodando no USS
👉 Ferramentas open source integradas
👉 E sim… git funcionando NATIVAMENTE no z/OS

💣 Traduzindo: o mainframe deixou de ser isolado e entrou no jogo moderno.

---

🔗 Parte 1 — Conectando z/OS ao GitHub (SSH)

Aqui começa a mágica.

🧩 Problema clássico

z/OS “raiz” muitas vezes não tem DNS configurado.

🔧 Solução (tradução + comentário)

vi /etc/resolv.conf

Adicione:

nameserver 8.8.8.8

💡 Comentário Bellacosa:
Isso aqui parece simples, mas é o que separa você de:

❌ “Host desconhecido”
✔️ Integração com o mundo externo

---

🔄 Restart do resolver

opercmd "stop resolver"
opercmd "start resolver"

💥 Aqui entra realidade de mainframe:

• Precisa permissão
• Ou chama o sysprog amigo 😎

---

🔍 Teste de DNS

host github.com

Se vier IP → 🎯 sucesso

---

🔐 Parte 2 — Criando chave SSH (segurança de verdade)

ssh-keygen -t rsa -b 4096 -C "seu-email"

👉 Isso gera:

• chave privada (fica no z/OS)
• chave pública (vai pro GitHub)

---

🚀 Ativando agente SSH

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

---

📋 Copiando chave pública

vi ~/.ssh/id_rsa.pub

Cola no GitHub:

• Settings
• SSH Keys
• New Key

---

💡 Insight Bellacosa:
Isso elimina senha.
Você entra no mundo:

👉 autenticação forte
👉 automação
👉 pipelines DevOps reais

---

🧰 Parte 3 — Instalando Git no z/OS

Aqui é onde muita gente trava.

📦 Solução moderna:

zopen install -y git

🔥 Isso instala:

• git
• dependências
• bash (ESSENCIAL!)

---

💡 Tradução prática:
Você acabou de transformar seu z/OS em um mini Linux dentro do USS.

---

🧪 Testando conexão com GitHub

ssh git@github.com

Saída esperada:

You've successfully authenticated, but GitHub does not provide shell access.

💣 Isso aqui é perfeito.
Significa:

👉 conexão OK
👉 autenticação OK
👉 pronto pra usar git

---

⚙️ Parte 4 — Configuração do ambiente

Edite o profile:

vi ~/.profile

Adicione:

git config --global user.name  "Seu Nome"
git config --global user.email "seu-email"
git config --global init.defaultBranch main
bash

---

💡 Insight poderoso:

👉 O bash aqui muda o jogo
👉 Você sai do shell limitado e entra num ambiente moderno

---

🔄 Reinicie sessão e valide

ps

Se aparecer:

bash

🎯 Missão cumprida

---

📂 Parte 5 — Clonando repositório

git clone git@github.com:usuario/repositorio.git
cd repositorio

💡 Aqui começa o DevOps REAL no mainframe.

---

🌿 Trabalhando com branch (fluxo moderno)

Criar branch

git checkout -b WordPressChange

---

Adicionar alteração

git add setenv.sh

---

Validar

git status

---

Commit

git commit

---

Enviar pro GitHub

git push origin WordPressChange

---

💥 TRADUÇÃO BELLACOSA:

Você acabou de fazer isso no z/OS:

👉 versionamento moderno
👉 branch strategy
👉 integração com GitHub
👉 colaboração distribuída

🔥 ISSO É DEVOPS NO MAINFRAME

---

🧠 Camada EXTRA — O que ninguém te conta

💣 1. USS é o segredo

Sem USS (Unix System Services), isso aqui não existiria.

---

💣 2. Git não entende dataset nativo

Você está trabalhando com:

👉 arquivos USS
👉 não diretamente com PDS/VSAM

---

💣 3. Ponte com COBOL

Fluxo real:

1. Código COBOL no USS
2. Versionado com git
3. Deploy → dataset
4. Compilação via JCL

🔥 Isso conecta dois mundos.

---

💣 4. Open Source salvando o mainframe

Sem a comunidade:

👉 nada disso existiria
👉 IBM acelerou depois

---

🧪 Exemplo real (mentalidade enterprise)

Imagine:

• Squad distribuído
• Dev Java + Dev COBOL
• Pipeline CI/CD

👉 GitHub → z/OS → compile → deploy → CICS

🔥 Isso já é realidade hoje

---

🏁 Conclusão estilo Bellacosa

💥 O que antes era “mainframe isolado” virou:

👉 plataforma integrada
👉 DevOps-ready
👉 open source friendly

E o git?

👉 virou a ponte entre gerações de tecnologia

---

☕ Frase pra fechar no estilo raiz:

“O mainframe não ficou ultrapassado…
você que ainda não viu ele rodando com git.” 😎🔥

 

🐙 GitHub Copilot — o “estagiário Jedi” do código (inclusive no Mainframe)

 

Github Copilot em review para mainframers

☕ Um Café no Bellacosa Mainframe

Tema: 🐙GitHub Copilot — o “estagiário Jedi” do código (inclusive no Mainframe)

---

🤖 Afinal… o que é o GitHub Copilot?

Padawan, sente-se.
O GitHub Copilot é aquele colega que não dorme, não pede café e completa seu código antes de você terminar de digitar. Criado pelo GitHub em parceria com a OpenAI, ele é um assistente de programação baseado em IA, treinado com bilhões de linhas de código público.

Em termos simples (estilo operador de madrugada):

“Você começa a escrever… o Copilot adivinha o que vem depois.”

Ele funciona como um autocomplete turbinado, mas com cérebro. Não é só completar palavra — ele entende intenção, contexto, padrões e estilo.

---

O que faz o Github Copilot

🧠 O que o Copilot faz na prática?

• ✍️ Sugere linhas inteiras de código

• 🧩 Cria funções completas

• 🔄 Converte comentários em código

• 🧪 Ajuda a escrever testes

• 📚 Sugere uso de APIs e bibliotecas

• 🧹 Refatora código legado (sim, até aquele que ninguém quer mexer)

Tudo isso em tempo real, direto no editor.

---

🛠️ Onde ele funciona?

• VS Code (o queridinho)

• Visual Studio

• JetBrains (IntelliJ, PyCharm etc.)

• Neovim (para os monges do terminal 😄)

---

🎯 Exemplo simples (para Padawans)

Você digita:

# função que calcula fatorial

O Copilot responde:

def fatorial(n):
    if n == 0:
        return 1
    return n * fatorial(n-1)

Magia?
Não. Machine Learning com café industrial ☕⚙️

---

💡 Dicas Bellacosa Mainframe (anota no caderninho)

1. Comente bem o código
   → O Copilot AMA comentários claros.
   Comentário ruim = sugestão ruim.

2. Não aceite tudo no automático
   → Ele é um estagiário gênio, não o arquiteto.

3. Use como par de programação
   → Você pensa no “o quê”, ele sugere o “como”.

4. Excelente para aprender linguagens novas
   → Ideal para Padawans curiosos.

5. Ótimo para código repetitivo
   → CRUD, validação, parsing, boilerplate… ele faz sorrindo.

---

🥚 Easter Eggs & Curiosidades

• 🐙 O nome Copilot vem da aviação:
  Ele ajuda, mas não pilota sozinho.

• 👀 Ele aprende o estilo do seu projeto.

• 🤐 Não tem memória pessoal: cada sugestão é baseada no contexto atual.

• ⚠️ Já sugeriu código inseguro ou obsoleto — por isso, olho de sysprog!

---

🧓 E AGORA O QUE INTERESSA: GitHub Copilot no IBM Mainframe 😎

❓ “Bellacosa… isso funciona com COBOL?”

Resposta curta:
👉 SIM, MAS COM ASTERISCOS

Resposta longa (a que gostamos):

---

🖥️ Copilot + COBOL + Mainframe

✅ Onde ele ajuda MUITO

• 📄 Escrita de código COBOL padrão

  • PERFORM

  • IF/ELSE

  • READ / WRITE

  • Estrutura de PROGRAM-ID, WORKING-STORAGE, etc.

• 🧾 Conversão de lógica

  • Pseudocódigo → COBOL

  • Comentários → código

• 🔁 Refatoração de código legado

  • Reduz GOTO

  • Sugere PERFORMs mais limpos

• 🧪 Geração de programas de teste

  • Dados fictícios

  • Leitura sequencial simples

---

⚠️ Onde ele AINDA NÃO é Jedi Master

• ❌ Não conhece seu layout VSAM específico

• ❌ Não entende copybooks proprietários

• ❌ Não sabe suas regras de negócio bancárias dos anos 80

• ❌ Não substitui conhecimento de:

  • CICS

  • DB2 tuning

  • JCL complexo

  • RACF

  • Performance

👉 Aqui entra o Mainframer raiz 💪

---

📌 Exemplo prático COBOL

Você escreve:

* Ler arquivo de clientes e somar saldo

O Copilot pode sugerir algo como:

READ CLIENTES-FILE
    AT END
        MOVE 'S' TO EOF-FLAG
    NOT AT END
        ADD SALDO-CLIENTE TO TOTAL-SALDO
END-READ.

É perfeito?
Não.

É um ótimo ponto de partida?
👉 SIM.

---

🧠 Copilot NÃO substitui o Mainframer

E isso precisa ficar claro no El Jefe Midnight:

O Copilot não sabe o que é um ABEND S0C7 às 2h da manhã.
Você sabe.

Ele acelera, mas não decide.
Ele sugere, mas não responde ao auditor.
Ele gera código, mas não conhece o cliente.

---

☕ Conclusão Bellacosa Mainframe

• Para Padawans:
  👉 O Copilot é um mestre paciente, que ensina pelo exemplo.

• Para Mainframers:
  👉 É um acelerador brutal de produtividade, se usado com juízo.

• Para o futuro do Mainframe:
  👉 Uma ponte entre o legado respeitado e a nova geração.

O Mainframe não morreu.
Ele só ganhou um copiloto.

 

 

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

 

COBOL e os desafios do GITHUB e ECLIPSE

🔥 Challenges of Running COBOL with Git – Uma Observação Prática (com cheiro de sala-cofre) 🔥

Durante décadas, COBOL e z/OS viveram felizes no seu ecossistema fechado, previsível e extremamente confiável. ISPF, PDS/PDSE, JCL, compile noturno, café forte e aquele silêncio respeitoso do data center. Então alguém chegou dizendo:

“Agora tudo é Git. Branch, pull request, rebase e pipeline.”

🤔 Pause dramático de mainframer veterano.

Este artigo nasce de pesquisa, observação prática e muita conversa de corredor — aquele tipo de conhecimento que não aparece em Redbook, mas surge no café das 3h da manhã durante um IPL mal-humorado.

---

🧬 1. EBCDIC vs UTF-8 – A Guerra Invisível dos Bytes

Aqui começa o primeiro boss final.

Git assume UTF-8. COBOL em z/OS respira EBCDIC. Misture isso sem regras claras e você ganha:

• Literais corrompidos

• DISPLAY mostrando hieróglifos

• Compilação falhando sem erro “óbvio”

💡 Dica Bellacosa:
Defina conversão explícita e obrigatória no pipeline. Nada de “ah, o plugin cuida disso”. Ele não cuida.

🥚 Easter egg:
Muitos bugs “fantasma” em COBOL moderno não são lógicos — são encoding bugs disfarçados.

---

📚 2. Copybooks – O Efeito Dominó Silencioso

COBOL sem copybook é como mainframe sem SMF: tecnicamente existe, mas ninguém confia.

O problema?
Git não entende dependência semântica.

• Um copybook alterado

• 137 programas impactados

• 12 recompilados

• 125 esquecidos

• Produção quebra… só amanhã

💡 Dica de guerra:
Pipeline dependency-aware é obrigatório. Ferramentas como DBB, scripts de impacto ou metadados não são luxo — são sobrevivência.

🗣 Fofoquinha real:
Já vi incidente crítico porque “era só um copybook de comentário”. Spoiler: não era.

---

📐 3. Diffs, Colunas e a Maldade do Espaço em Branco

Git ama linhas.
COBOL ama colunas.

Um espaço fora do lugar vira:

• Diff gigante

• Merge impossível

• Revisão inútil

Comentários deslocados geram mais conflito que erro lógico.

💡 Dica Bellacosa raiz:

• Padronize formatação

• Use ferramentas de pretty-print COBOL

• Trate espaço em branco como código, não estética

🥚 Easter egg clássico:
Um MOVE perfeito na lógica pode falhar só porque começou na coluna errada. Git não entende isso. O compilador sim — e ele não perdoa.

---

⚙️ 4. Build, Compile e o “CI/CD de Verdade”

Aqui mora a grande ilusão moderna:

“Ah, só dar git push que compila.”

Não, não compila.

COBOL exige:

• Compile no z/OS

• Link-edit

• Bind DB2

• Execução JCL

• Controle de RC

• Logs rastreáveis

Sem automação real, Git vira apenas um repositório bonito.

💡 Dica prática:
Se o commit não dispara compile, bind e validação automática, você não tem CI/CD — só tem GitHub caro.

---

🧠 5. Cultura, Pessoas e o Choque de Gerações

Aqui não é tecnologia — é gente.

• Desenvolvedores COBOL dominam ISPF como ninguém

• Git traz conceitos novos: rebase, squash, branch strategy

• Sem cuidado, isso vira atrito desnecessário

💡 Dica de liderança técnica:
Não force Git “goela abaixo”. Traduza conceitos:

• Branch ≈ versão lógica

• Pull request ≈ revisão formal

• Pipeline ≈ JCL automático

🗣 Comentário de bastidor:
Os melhores times são híbridos: mainframers aprendendo Git e devops aprendendo z/OS. Quem só ensina e não aprende falha.

---

🔐 6. Segurança – RACF não é GitHub (e nunca será)

Git trabalha com:

• Usuário

• Token

• Repo

Mainframe trabalha com:

• Identidade

• Perfil

• Dataset

• Auditoria pesada

Alinhar RACF/ACF2/TSS com Git não é trivial, principalmente em ambientes regulados.

💡 Dica Bellacosa:
Auditoria e rastreabilidade devem nascer no pipeline, não serem “adaptadas depois”.

🥚 Easter egg corporativo:
Compliance sempre descobre o problema depois que o sistema já está em produção.

---

🧠 Pensamento Final – Git Funciona com COBOL?

Sim.
Mas não por mágica.

Git funciona com COBOL quando existe:

• Disciplina

• Ferramentas corretas

• Pipeline consciente

• Respeito à cultura mainframe

Sem isso, você só moderniza o problema — não a solução.

🔥 Provocação final do El Jefe:
Quantos ambientes “modernizados” hoje só trocaram o PDS por Git, mas mantiveram os mesmos riscos de 1989?