 |
| Bellacosa Mainframe e o guia do devops para mainframe |
☕ Um Café no Bellacosa Mainframe
DevOps no Mainframe: O Guia Definitivo para Quem Programa em COBOL e Quer Entrar no Mundo da Entrega Contínua
"DevOps não é instalar uma ferramenta. É mudar a forma como pensamos sobre desenvolvimento, testes, implantação e operação. E sim... isso também vale para COBOL."
Se você trabalha com IBM Mainframe há alguns anos, provavelmente já ouviu alguém dizer:
"Mainframe não precisa de DevOps."
Ou então:
"DevOps é coisa de Java, Kubernetes e Cloud."
Nada poderia estar mais distante da realidade.
Hoje, os maiores bancos, seguradoras, empresas de cartão de crédito, telecomunicações e governos do mundo utilizam práticas de DevOps justamente nos ambientes mais críticos: os sistemas IBM Z.
A verdade é simples:
O código COBOL continua excelente. O processo de desenvolvimento é que evoluiu.
Neste café vamos entender, de maneira prática, o que é DevOps, como funciona, quais ferramentas existem, como começar do zero e como implantar esse modelo em uma fábrica de software Mainframe.
Pegue seu café.
Vamos conversar.
Antes de tudo: o que é DevOps?
A palavra DevOps vem da união de duas áreas:
Development (Desenvolvimento)
Operations (Operação)
Durante décadas essas equipes trabalharam separadas.
O desenvolvedor escrevia código.
O operador implantava.
O suporte resolvia problemas.
Quando dava errado...
Todo mundo culpava o outro.
DevOps nasceu justamente para eliminar esse conflito.
O objetivo é fazer todos trabalharem juntos durante todo o ciclo de vida do software.
O ciclo tradicional
Durante muitos anos o fluxo era parecido com isto:
Analista
↓
Programador COBOL
↓
Testes
↓
Homologação
↓
Mudança
↓
Produção
Tudo manual.
Muito e-mail.
Planilhas.
Checklist.
JCL executado manualmente.
Libraries copiadas.
Muitas chances de erro humano.
O ciclo DevOps
Agora imagine outro cenário.
Programador
↓
Git
↓
Build automático
↓
Testes automáticos
↓
Deploy automático
↓
Homologação
↓
Produção
↓
Monitoramento
Tudo rastreado.
Tudo versionado.
Tudo auditável.
Esse é o objetivo do DevOps.
DevOps não é uma ferramenta
Este talvez seja o maior erro dos iniciantes.
DevOps não é:
Jenkins
Git
GitHub
Azure DevOps
GitLab
Essas são ferramentas.
DevOps é uma cultura.
As ferramentas apenas ajudam.
 |
| Bellacosa Mainframe e o devops para iniciante mainframe |
Os pilares do DevOps
Podemos resumir DevOps em seis grandes pilares.
1. Planejamento
Toda mudança começa aqui.
Exemplo:
Nova funcionalidade
Correção de bug
Mudança legal
Novo produto
Ferramentas:
Jira
Azure Boards
Trello
ServiceNow
2. Desenvolvimento
Aqui entra o programador COBOL.
Ele escreve código.
Exemplo:
Programa COBOL
+
JCL
+
PROC
+
Copybooks
+
DB2
+
CICS
Tudo precisa ficar versionado.
3. Integração Contínua (CI)
Sempre que alguém altera o código...
O sistema automaticamente:
compila
executa testes
verifica qualidade
gera relatórios
Sem intervenção humana.
4. Testes
Não basta compilar.
É necessário testar.
Tipos comuns:
teste unitário
teste funcional
teste integração
teste regressão
teste performance
No Mainframe isso pode envolver:
ZUnit
IBM Debug
File Manager
stubs
dados mascarados
5. Deploy
Depois da aprovação:
o sistema promove automaticamente os artefatos entre ambientes.
DEV
↓
QA
↓
HML
↓
PRD
Sem copiar datasets manualmente.
6. Monitoramento
Depois da implantação...
O trabalho continua.
Monitoramos:
CPU
tempo de resposta
erros
logs
abends
consumo
throughput
 |
| Bellacosa Mainframe e ferramentas para implementar o devops |
O famoso CI/CD
Você verá muito essa sigla.
CI
Continuous Integration
CD
Continuous Delivery
ou
Continuous Deployment.
A diferença é simples.
Continuous Delivery
O deploy fica pronto.
Mas alguém aprova.
Continuous Deployment
O deploy acontece automaticamente.
Como isso funciona no Mainframe?
Imagine um programa COBOL.
Você altera uma linha.
Ao salvar:
Git
↓
Pipeline
↓
Compilação
↓
Link-edit
↓
Testes
↓
Deploy
↓
Homologação
Tudo automático.
Ferramentas mais usadas
Vamos conhecer as principais.
Git
O coração do DevOps.
Ele controla versões.
Permite:
histórico
branches
merge
rollback
Hoje praticamente todo projeto moderno usa Git.
Inclusive Mainframe.
GitHub
Hospeda repositórios Git.
Possui:
Pull Request
Code Review
Actions
Issues
Muito usado em projetos open source.
GitLab
Além do Git...
Possui pipeline integrada.
Muito utilizado em empresas.
Azure DevOps
Muito comum em bancos.
Possui:
Boards
Repos
Pipelines
Artifacts
Test Plans
Integra muito bem com ambientes corporativos.
Jenkins
Uma das ferramentas de automação mais famosas.
Ele executa:
compilação
testes
deploy
scripts
Tudo automaticamente.
IBM Dependency Based Build (DBB)
Ferramenta criada pela IBM para Mainframe.
Ela entende:
COBOL
PL/I
Assembler
JCL
Copybooks
Excelente para pipelines IBM Z.
IBM Developer for z/OS (IDz)
Substitui boa parte do ISPF.
Integra:
Git
Debug
Build
Pipeline
Zowe
Talvez a maior revolução dos últimos anos.
Permite acessar o Mainframe usando:
VS Code
APIs
CLI
Explorer
É praticamente uma ponte entre o mundo distribuído e o IBM Z.
VS Code
Hoje muitos programadores COBOL utilizam VS Code.
Com extensões adequadas é possível:
editar COBOL
enviar código
acessar datasets
executar comandos
Ansible
Automação de infraestrutura.
Pode automatizar:
configuração
deploy
instalação
tarefas repetitivas
SonarQube
Analisa qualidade do código.
Detecta:
duplicação
complexidade
bugs
vulnerabilidades
Inclusive existem plugins para COBOL.
JFrog Artifactory
Gerencia artefatos.
Armazena:
builds
binários
versões
Um pipeline simples
Imagine este fluxo.
Programador
↓
Git Commit
↓
Pipeline
↓
Compilar COBOL
↓
Executar testes
↓
Quality Gate
↓
Deploy DEV
↓
Deploy QA
↓
Deploy HML
↓
Produção
Sem copiar datasets manualmente.
Sem FTP.
Sem e-mail.
Como implantar DevOps em um sistema Mainframe?
Aqui está um roteiro simples.
Etapa 1
Mapeie o processo atual.
Pergunte:
Como o programa chega em produção?
Quem aprova?
Quem compila?
Quem faz bind?
Quem copia load modules?
Quem altera CICS?
Quem agenda o Job?
Etapa 2
Versione tudo.
Não apenas programas COBOL.
Também:
JCL
PROC
Copybooks
SQL
DDL
Scripts
Documentação
Etapa 3
Padronize.
Todos devem usar:
Mesmo padrão.
Mesmo fluxo.
Mesmo processo.
Etapa 4
Automatize a compilação.
Em vez de:
Editar
Compilar
Link
Testar
Faça:
Commit
↓
Pipeline
↓
Compilação automática
Etapa 5
Automatize testes.
Quanto mais testes...
Maior a confiança.
Etapa 6
Automatize deploy.
Reduza:
intervenção humana
erros
esquecimentos
Etapa 7
Monitore.
Depois do deploy acompanhe:
SMF
RMF
JES
SDSF
logs
CICS
DB2
Roadmap para quem está começando
Nível 1
Aprenda:
Git
GitHub
Branch
Merge
Pull Request
Nível 2
Aprenda:
Jenkins
Azure DevOps
GitLab CI
Nível 3
Aprenda:
Pipeline
YAML
Build
Nível 4
Aprenda:
Zowe CLI
VS Code
REST APIs
Nível 5
Aprenda:
DBB
IDz
SonarQube
Nível 6
Aprenda:
Docker (conceitos)
Kubernetes (conceitos)
OpenShift
Mesmo trabalhando apenas com Mainframe.
Nível 7
Aprenda observabilidade.
Conheça:
Grafana
Prometheus
Elastic
OpenTelemetry
Mesmo que parte do monitoramento do IBM Z utilize soluções específicas da IBM.
Quanto custa implantar?
A resposta depende do ambiente.
Há soluções gratuitas e corporativas.
Gratuitas
Git
GitHub (planos gratuitos)
VS Code
Jenkins
Zowe
SonarQube Community
O investimento principal será tempo de implantação, treinamento e adaptação dos processos.
Corporativas
Dependendo da empresa podem existir licenças para:
IBM Dependency Based Build
IBM Developer for z/OS
Azure DevOps
GitHub Enterprise
GitLab Enterprise
JFrog Artifactory
UrbanCode Deploy (ou soluções equivalentes)
ferramentas de testes automatizados
Além das licenças, considere:
infraestrutura
treinamento
consultoria
integração com RACF, CICS, DB2 e sistemas legados
manutenção contínua
Apesar do investimento inicial, a redução de retrabalho e de falhas costuma compensar em projetos de médio e grande porte.
Quais são os riscos?
Toda mudança traz desafios.
Os principais são:
Resistência cultural
O maior obstáculo raramente é técnico.
É comum ouvir:
"Sempre fizemos assim."
Sem apoio da liderança, a adoção perde força.
Automação mal planejada
Automatizar um processo ruim apenas faz o erro acontecer mais rápido.
Primeiro simplifique.
Depois automatize.
Falta de testes
Um pipeline sem testes é apenas um "copiador automático" de problemas.
Invista em testes desde o início.
Controle de acesso
Automações precisam respeitar políticas de segurança.
Integração com RACF, auditoria e segregação de funções são indispensáveis.
Dependência de poucas pessoas
Evite que apenas um especialista conheça o pipeline. Documente, treine a equipe e compartilhe conhecimento.
As grandes vantagens
Os benefícios aparecem rapidamente.
Menos erros manuais.
Entregas mais rápidas.
Maior rastreabilidade.
Rollback simplificado.
Melhor colaboração entre desenvolvimento e operações.
Qualidade de código mais alta.
Testes executados com frequência.
Auditoria facilitada.
Processos padronizados.
Redução do tempo de implantação.
Mais confiança para liberar novas versões.
Maior integração entre Mainframe e plataformas distribuídas.
Para ambientes regulados, como bancos e seguradoras, isso também significa maior conformidade e facilidade em auditorias.
E as desvantagens?
Nem tudo são flores.
Curva de aprendizado inicial.
Mudança cultural pode gerar resistência.
Necessidade de treinamento.
Tempo para configurar pipelines.
Investimento em ferramentas corporativas, quando necessário.
Ajustes em processos antigos.
Necessidade de governança para evitar pipelines desorganizados.
A boa notícia é que esses desafios diminuem à medida que a equipe ganha experiência.
Um exemplo prático
Imagine que uma alteração fiscal exige mudanças em um programa COBOL.
Sem DevOps:
Desenvolvedor altera o código.
Envia por e-mail.
Outro profissional compila.
Um terceiro faz o BIND.
Alguém copia o módulo para homologação.
Os testes são executados manualmente.
A documentação é atualizada depois (ou esquecida).
A implantação depende de uma janela operacional.
Com DevOps:
O desenvolvedor cria uma branch.
Implementa a alteração.
Abre um Pull Request.
O código passa por revisão.
O pipeline compila automaticamente.
Testes unitários e de integração são executados.
A qualidade é validada pelo SonarQube.
Após aprovação, o deploy é promovido para homologação.
Com a autorização final, a mesma pipeline promove a versão para produção.
Todo o processo fica registrado para auditoria.
Perceba que o COBOL continua sendo COBOL. O que mudou foi a forma de entregar software.
Conclusão
Durante muito tempo, DevOps foi visto como algo exclusivo do mundo Linux, Java e Cloud. Hoje sabemos que essa visão ficou no passado.
O IBM Z evoluiu. Ferramentas como Git, Zowe, IBM Dependency Based Build, Azure DevOps, Jenkins e pipelines de CI/CD permitem que aplicações COBOL participem do mesmo ciclo moderno de desenvolvimento utilizado nas demais plataformas da empresa.
Se você é um Padawan COBOL, não tente aprender tudo de uma vez. Comece pelo essencial: Git, versionamento, revisão de código e conceitos de integração contínua. Em seguida, avance para pipelines, automação de testes e deploy. Com essa base, ferramentas específicas do Mainframe farão muito mais sentido.
Lembre-se: DevOps não substitui o conhecimento de COBOL, JCL, CICS ou DB2. Ele potencializa esse conhecimento, reduzindo erros, aumentando a qualidade e permitindo que sistemas críticos evoluam com segurança.
No fim das contas, o maior legado do DevOps não é uma ferramenta nem um pipeline. É uma mudança de mentalidade: desenvolver, testar, implantar e operar como um único time, entregando valor continuamente para o negócio.
E esse, meu amigo Padawan, é um princípio que nunca ficará obsoleto.
Sem comentários:
Enviar um comentário