 |
| Bellacosa Mainframe apresenta ferramentas ci/cd para mainframers |
☕ Um Café no Bellacosa Mainframe
Ferramentas para Implementar CI/CD no Mainframe
Do Git ao IBM Z: Construindo uma Esteira Moderna para Aplicações COBOL
"O maior erro de um programador COBOL é imaginar que CI/CD significa apenas instalar Jenkins. O verdadeiro pipeline começa muito antes da primeira ferramenta e termina muito depois do deploy."
Durante muitos anos existiu um mito dentro das equipes de desenvolvimento IBM Z.
O mito dizia que DevOps era coisa de aplicações Java.
Que Docker era para Linux.
Que Git era para desenvolvedores Web.
Que CI/CD não fazia sentido para COBOL.
Enquanto isso, silenciosamente, bancos, seguradoras, bolsas de valores, empresas aéreas e grandes instituições financeiras começaram a automatizar praticamente todo o ciclo de desenvolvimento de aplicações Mainframe.
Hoje, um programa COBOL raramente percorre o caminho entre desenvolvimento e produção apenas pelas mãos de um operador. Em vez disso, ele passa por uma esteira automatizada composta por dezenas de ferramentas responsáveis por versionamento, compilação, análise de qualidade, testes, empacotamento, implantação, monitoramento e auditoria.
Se antigamente o programador entregava apenas um fonte COBOL, hoje ele entrega um conjunto de artefatos que precisam passar por um pipeline inteligente.
Neste café vamos conhecer as principais ferramentas que compõem esse ecossistema moderno.
O quebra-cabeça do CI/CD
Antes de falar de ferramentas, precisamos entender uma verdade importante.
Não existe uma ferramenta chamada CI/CD.
CI/CD é um conjunto de práticas.
Cada ferramenta resolve apenas uma parte do problema.
Imagine uma linha de montagem de automóveis.
Uma máquina solda.
Outra pinta.
Outra instala o motor.
Outra testa os freios.
Nenhuma delas constrói o carro sozinha.
No mundo DevOps acontece exatamente a mesma coisa.
O pipeline moderno
Um pipeline corporativo normalmente possui etapas como:
Git
↓
Merge
↓
Build
↓
Compile
↓
Static Analysis
↓
Unit Test
↓
Integration Test
↓
Artifact
↓
Deploy DEV
↓
Deploy QA
↓
Approval
↓
Deploy Production
↓
Monitoring
Cada etapa pode utilizar uma ferramenta diferente.
Git — O novo PDS do Coboleiro
A primeira ferramenta que todo desenvolvedor precisa conhecer é o Git.
Não importa se você trabalha com COBOL, PL/I, Assembler ou Java.
Sem controle de versões não existe CI/CD.
Git permite:
histórico completo;
rollback;
branches;
merge;
auditoria;
colaboração entre equipes.
Para quem vem do mundo IBM Z, uma boa analogia é pensar que o Git é um grande PDS inteligente que registra todas as alterações feitas em cada membro, preservando versões e identificando exatamente quem modificou cada linha de código.
GitHub, GitLab e Bitbucket
O Git controla versões localmente.
Já GitHub, GitLab e Bitbucket hospedam os repositórios e adicionam funcionalidades colaborativas.
Essas plataformas oferecem:
Pull Requests;
Code Review;
gestão de branches;
integração com pipelines;
controle de permissões;
rastreabilidade.
No dia a dia, um programador COBOL pode alterar um programa, abrir um Pull Request e aguardar a aprovação do líder técnico antes que o código seja integrado à branch principal.
Jenkins — O Maestro da Orquestra
Se o Git armazena o código, quem coordena a esteira?
Uma das respostas mais comuns é o Jenkins.
O Jenkins é um servidor de automação.
Sua função é executar tarefas automaticamente sempre que algum evento ocorre.
Por exemplo:
git push
↓
Executar Build
↓
Compilar
↓
Executar testes
↓
Publicar relatório
↓
Enviar e-mail
↓
Implantar
Para um coboleiro, o Jenkins lembra bastante um agendador de JOBs.
A diferença é que, em vez de executar apenas batchs, ele orquestra toda a cadeia de desenvolvimento.
GitHub Actions
Nos últimos anos, GitHub Actions tornou-se uma excelente alternativa ao Jenkins.
O pipeline fica descrito em arquivos YAML dentro do próprio repositório.
Exemplo simplificado:
Push
↓
Checkout
↓
Build
↓
Test
↓
Deploy
Toda alteração no código pode disparar automaticamente essa sequência.
GitLab CI
Quem utiliza GitLab encontra uma solução semelhante.
O arquivo .gitlab-ci.yml define as etapas do pipeline.
Cada etapa executa scripts específicos.
É uma excelente opção para organizações que desejam manter todo o ciclo DevOps em uma única plataforma.
Docker — O Ambiente que Viaja Junto
Talvez esta seja a ferramenta mais mal compreendida pelos desenvolvedores Mainframe.
Docker normalmente não executa aplicações z/OS.
Ele executa aplicações Linux.
Mas isso não significa que ele esteja distante do IBM Z.
Muito pelo contrário.
Imagine uma aplicação composta por:
Front-end React;
API Java;
Redis;
Kafka;
PostgreSQL;
COBOL no Mainframe.
Durante os testes, Docker pode subir automaticamente todos os componentes distribuídos, permitindo que apenas o Mainframe permaneça como ambiente externo.
Assim, o pipeline consegue validar toda a aplicação antes da entrega.
Easter Egg Bellacosa
Uma Docker Image lembra muito uma PROC catalogada.
Alguém preparou um ambiente padronizado.
Os demais apenas reutilizam.
Da mesma forma que uma PROC encapsula passos JCL reutilizáveis, uma imagem Docker encapsula bibliotecas, ferramentas e configurações.
IBM Dependency Based Build (DBB)
Agora entramos nas ferramentas específicas do mundo IBM Z.
O IBM Dependency Based Build foi criado para automatizar builds de aplicações Mainframe.
Seu grande diferencial é entender dependências entre:
programas COBOL;
COPYBOOKs;
JCLs;
BMS;
PL/I;
Assembler.
Imagine alterar um COPYBOOK.
Em vez de recompilar milhares de programas, o DBB identifica exatamente quais módulos dependem daquele componente.
Isso reduz drasticamente o tempo de build.
IBM Developer for z/OS (IDz)
Durante muitos anos o ISPF foi praticamente o único ambiente de desenvolvimento utilizado por programadores COBOL.
Hoje o IBM Developer for z/OS oferece recursos modernos:
edição inteligente;
autocomplete;
refatoração;
integração com Git;
depuração;
integração com pipelines.
Ele aproxima a experiência do desenvolvedor Mainframe daquela encontrada em IDEs modernas.
Zowe CLI
Poucas ferramentas revolucionaram tanto a integração entre Mainframe e DevOps quanto o Zowe.
O Zowe CLI permite executar comandos z/OS diretamente da linha de comando.
É possível:
enviar arquivos;
submeter JOBs;
consultar JES;
baixar datasets;
acessar USS;
manipular perfis.
Isso transforma o Mainframe em um participante natural dos pipelines modernos.
Um Jenkins pode executar comandos Zowe da mesma forma que executa comandos Linux.
z/OSMF
O z/OS Management Facility disponibiliza serviços REST para administração do ambiente.
Essas APIs permitem:
submeter JOBs;
consultar status;
manipular datasets;
automatizar operações.
Isso reduz a necessidade de scripts específicos e facilita a integração com ferramentas DevOps.
IBM UrbanCode Deploy
Quando falamos em implantação controlada, uma ferramenta bastante conhecida é o UrbanCode Deploy.
Ela oferece:
versionamento de pacotes;
promoção entre ambientes;
rollback;
aprovações;
auditoria;
histórico de deploys.
Em bancos, normalmente um pacote percorre DEV → QA → UAT → Produção obedecendo regras rígidas de governança.
SonarQube
Compilar não significa produzir código de qualidade.
É aí que entra o SonarQube.
Ele realiza análise estática identificando:
duplicação de código;
complexidade excessiva;
vulnerabilidades;
más práticas;
código morto.
No universo COBOL, também ajuda a localizar programas com manutenção difícil, excesso de GO TO ou baixa legibilidade.
Testes Automatizados
CI/CD sem testes automatizados é apenas automação de compilação.
Ferramentas como ZUnit permitem validar programas COBOL automaticamente.
Cada alteração dispara dezenas ou centenas de testes sem intervenção humana.
Isso reduz regressões e aumenta a confiança nas entregas.
Nexus e Artifactory
Após o build surge outra pergunta.
Onde armazenar os artefatos?
Ferramentas como Nexus Repository e JFrog Artifactory centralizam:
pacotes;
bibliotecas;
versões;
dependências.
Mesmo quando o artefato final é um LOAD Module, o pipeline pode armazenar documentação, scripts, relatórios e componentes auxiliares.
Ansible
Cada vez mais utilizado em ambientes híbridos.
Permite automatizar:
configuração;
implantação;
execução de comandos;
integração entre servidores Linux e Mainframe.
Com coleções específicas para IBM Z, torna-se possível executar tarefas administrativas repetitivas de forma padronizada.
OpenShift
Embora aplicações COBOL normalmente permaneçam no z/OS, muitos componentes modernos são executados em OpenShift.
APIs.
Microsserviços.
Monitoramento.
Dashboards.
Ferramentas de apoio ao pipeline.
Tudo isso pode coexistir com o Mainframe.
Monitoramento
Depois do deploy o trabalho não termina.
Ferramentas como:
Grafana;
Prometheus;
Elastic;
Splunk;
Dynatrace;
Instana.
permitem acompanhar métricas, logs e desempenho.
No IBM Z elas complementam informações provenientes de RMF, SMF e outras soluções tradicionais.
Segurança
Pipelines modernos também verificam:
credenciais;
certificados;
assinaturas;
vulnerabilidades;
conformidade.
O objetivo é impedir que software inseguro alcance produção.
Como tudo conversa?
Imagine o seguinte fluxo.
Git
↓
GitHub
↓
GitHub Actions
↓
Docker
↓
DBB
↓
Compile COBOL
↓
ZUnit
↓
SonarQube
↓
Artifact
↓
UrbanCode
↓
Produção IBM Z
Cada ferramenta executa apenas sua especialidade.
Juntas, constroem uma esteira extremamente confiável.
O erro mais comum
Muitas empresas acreditam que basta instalar Jenkins.
Não basta.
Sem:
versionamento;
testes;
padronização;
documentação;
governança;
o pipeline apenas automatiza problemas antigos.
Existe uma frase famosa no mundo DevOps:
"Automatizar um processo ruim apenas faz com que ele falhe mais rápido."
Como escolher as ferramentas?
Não existe resposta única.
Uma empresa pequena pode começar apenas com:
Git;
GitHub;
GitHub Actions;
Zowe.
Uma organização maior pode utilizar:
GitLab;
Jenkins;
DBB;
SonarQube;
UrbanCode;
ZUnit;
Artifactory;
OpenShift;
Ansible.
Tudo depende da maturidade do ambiente.
A jornada do Coboleiro Moderno
O desenvolvedor COBOL do futuro continuará escrevendo PROCEDURE DIVISION.
Continuará criando JCL.
Continuará utilizando Db2.
Continuará desenvolvendo CICS.
Mas também precisará compreender conceitos como:
Git;
Pull Request;
Merge;
Pipeline;
Docker;
YAML;
Testes Automatizados;
Quality Gates;
DevSecOps;
Observabilidade.
Isso não significa abandonar o Mainframe.
Significa ampliar suas competências.
Conclusão
Durante décadas, o IBM Z foi visto como uma ilha tecnológica, separado do restante da engenharia de software. Hoje essa visão já não corresponde à realidade. As ferramentas modernas de CI/CD demonstram que é possível integrar aplicações COBOL aos mesmos processos de automação, qualidade e governança utilizados no desenvolvimento distribuído, preservando toda a confiabilidade que tornou o Mainframe indispensável para os negócios.
O segredo não está em substituir tecnologias tradicionais, mas em conectá-las de forma inteligente. Git não elimina o conhecimento sobre bibliotecas PDS; Docker não substitui o z/OS; Jenkins não toma o lugar do JES2; Zowe não elimina o ISPF. Cada ferramenta complementa o ambiente e amplia a capacidade de entrega das equipes.
Para o COBOL Jr, dominar esse ecossistema representa uma enorme vantagem competitiva. Ele deixa de ser apenas um programador que compila programas e passa a compreender toda a jornada do software, desde o primeiro commit até o monitoramento da aplicação em produção. Essa visão sistêmica é cada vez mais valorizada em bancos, seguradoras e empresas que executam milhares de transações por segundo no IBM Z.
No universo Bellacosa Mainframe, a mensagem é simples: o COBOL continua sendo o motor dos negócios, mas o CI/CD é a esteira invisível que mantém esse motor evoluindo com velocidade, qualidade e segurança. O profissional que aprender a combinar a robustez do Mainframe com as práticas modernas de DevOps estará preparado para construir a próxima geração de aplicações críticas, onde tradição e inovação caminham lado a lado.
Sem comentários:
Enviar um comentário