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