DevOps no mainframe já avançou o suficiente para mudar a principal questão da área. Em vez de perguntar apenas como inserir o código em uma pipeline, o foco agora é responder: quais critérios garantem que esse código tem qualidade para seguir adiante sem depender de um revisor humano?
A pesquisa de mainframe da BMC de 2025 ajuda a dimensionar essa mudança. Entre mais de mil profissionais e stakeholders consultados, 67% afirmaram utilizar DevOps no mainframe, contra 63% no ano anterior.
Ao mesmo tempo, 53% disseram priorizar DevOps especificamente para melhorar a eficiência do desenvolvimento de aplicações. Entre os benefícios mais citados estão maior estabilidade da infraestrutura, melhoria da qualidade das aplicações implantadas e aumento da automação.
Esses números sugerem uma etapa importante de maturidade. Quando a automação deixa de ser exceção, qualidade também precisa deixar de depender exclusivamente da capacidade de uma pessoa perceber um problema durante a revisão.
Em aplicações críticas, boas práticas de COBOL e SQL podem deixar de ser apenas conhecimento compartilhado entre desenvolvedores experientes e se transformar em políticas verificadas sistematicamente durante o ciclo de desenvolvimento.
É nesse ponto que o controle de qualidade começa a se aproximar da governança de engenharia.
O revisor não deveria ser o único lugar onde a regra existe
Toda organização madura possui padrões de desenvolvimento, ainda que parte deles nunca tenha sido formalizada completamente.
Não utilizar determinada construção COBOL. Evitar padrões que possam comprometer a estabilidade. Escrever consultas SQL de determinada forma. Observar certos critérios antes de promover um programa. Tratar algumas violações como alerta e outras como impeditivas.
O problema aparece quando essas regras existem principalmente na experiência das pessoas.
Um desenvolvedor mais antigo conhece os padrões porque participou de incidentes anteriores. Um DBA identifica rapidamente uma consulta que pode gerar consumo excessivo. Um especialista COBOL percebe uma construção que já causou retrabalho em outros projetos. Na revisão, esse conhecimento funciona como uma espécie de memória operacional da organização.
Isso tem valor e continuará tendo, mas também cria uma dependência difícil de escalar.
Quanto maior a frequência de mudanças, mais código precisa ser revisado. Quanto maior o número de equipes, maior a possibilidade de interpretações diferentes sobre o mesmo padrão. E quanto mais rápido o pipeline, menor deveria ser a dependência de controles que só acontecem quando alguém encontra tempo para olhar cada caso.
A questão, portanto, não é eliminar o revisor. É evitar que regras conhecidas precisem ser redescobertas manualmente a cada revisão.
Há uma diferença importante entre documentar uma regra e incorporá-la ao processo.
Uma organização pode escrever que determinada prática SQL deve ser evitada. Pode manter padrões COBOL em documentos internos. Pode promover treinamentos e fazer revisões periódicas. Ainda assim, nada garante que a mesma verificação acontecerá em todas as mudanças.
Quando essa regra passa a ser inspecionada automaticamente antes da promoção do código, ela muda de natureza.
Deixa de ser apenas recomendação e começa a funcionar como política de engenharia.
Essa lógica já é comum em outras camadas de tecnologia. Pipelines verificam dependências, testes precisam passar antes de um merge, políticas de segurança podem impedir determinados deployments e infraestrutura como código pode ser validada automaticamente antes de ser aplicada.
Código mainframe pode seguir o mesmo princípio.
O Eccox Application Quality Control for COBOL analisa o programa-fonte a partir de regras alinhadas aos padrões da organização. Entre os critérios previstos pela solução estão otimização de recursos, estabilidade do ambiente, padrões de codificação e redução de retrabalho. O resultado da inspeção identifica violações que podem ser tratadas ainda durante o desenvolvimento.
O ponto mais importante não é simplesmente encontrar um erro. É tornar a aplicação daquela regra sistemática.
SQL correto não é necessariamente SQL adequado
Essa discussão ganha outra dimensão quando chega ao Db2.
SQL é uma linguagem flexível. Duas construções diferentes podem produzir o mesmo resultado funcional e, ainda assim, apresentar comportamentos bastante diferentes em termos de CPU, I/O e custo de execução.
Para o usuário da aplicação, ambas “funcionam”. Para uma operação de missão crítica executada milhões de vezes, a diferença pode ser significativa.
O Eccox Application Quality Control for DB2 foi desenvolvido paraautomatizar a inspeção da codificação SQL no ambiente z/OS, verificando tanto aspectos de performance quanto aderência a padrões e regras previamente estabelecidos pela organização.
A solução pode ser incorporada às etapas de compilação e promoção e integrada a ferramentas de gerenciamento do ciclo de vida como Endevor e Changeman.
Isso desloca a análise para um momento importante: antes de o código inadequado chegar à produção.
A diferença é semelhante à existente entre monitorar um problema de performance depois do deployment e impedir que uma condição já conhecida avance pelo processo de desenvolvimento.
São controles complementares, mas atuam em momentos diferentes.
Observabilidade mostra o que está acontecendo com o sistema em operação. Quality gates procuram evitar que determinadas condições conhecidas cheguem até lá.
Transformar qualidade em política também resolve um problema menos visível: continuidade do conhecimento.
Mainframes normalmente sustentam aplicações que passaram por várias gerações de profissionais. Nesse período, equipes mudam, fornecedores entram e saem, padrões evoluem e novas pessoas precisam compreender sistemas construídos muito antes de sua chegada.
Se uma parte importante das práticas de qualidade depende apenas de quem conhece historicamente o ambiente, a saída ou indisponibilidade dessas pessoas também representa perda de controle.
Quando os critérios são formalizados em regras verificáveis, parte desse conhecimento deixa de existir somente na cabeça dos especialistas e passa a fazer parte da própria engenharia.
Isso não significa que toda decisão possa ser convertida em regra.
Uma inspeção automática não compreende sozinha todas as implicações de arquitetura, contexto de negócio ou intenção de uma mudança. Também não substitui code review, testes ou análise de impacto.
O ganho está em outra coisa: automatizar aquilo que já sabemos que deve ser verificado, preservando o tempo humano para as decisões que realmente exigem julgamento.
DevOps rápido sem governança apenas entrega problemas mais rápido
À medida que DevOps amadurece no mainframe, essa distinção fica mais importante.
Uma pipeline mais eficiente reduz o tempo entre desenvolvimento e produção. Isso é desejável, mas também reduz o intervalo disponível para encontrar problemas.
Se os controles permanecem completamente manuais enquanto o restante do processo acelera, eles podem se transformar no próximo gargalo ou simplesmente ser contornados em nome do prazo.
A resposta não deve ser escolher entre velocidade e qualidade. Deve ser automatizar parte da qualidade para que ela consiga acompanhar a velocidade.
Isso ajuda a colocar ferramentas como o EQC em outra categoria de discussão.
O EQC COBOL e o EQC DB2 não precisam ser vistos apenas como ferramentas de otimização de código. Eles podem participar de uma arquitetura de governança do desenvolvimento, na qual os critérios definidos pela organização são incorporados ao fluxo e aplicados consistentemente antes da promoção.
Uma determinada violação pode gerar orientação. Outra pode exigir correção. Critérios e modos de operação podem variar conforme as políticas estabelecidas para aquele ambiente.
No caso do EQC DB2, também conhecido por EQD, a própria Eccox descreve o produto como um filtro de qualidade capaz de impedir que código inadequado seja promovido ao ambiente produtivo.
Essa capacidade torna o controle menos dependente da eventualidade de alguém perceber o problema.
Qualidade também pode ser infraestrutura do desenvolvimento
Durante muito tempo, qualidade de código foi tratada principalmente como uma característica do desenvolvedor: bons profissionais escrevem bom código, revisores experientes encontram problemas e equipes maduras seguem boas práticas.
Tudo isso continua verdadeiro, mas organizações que operam sistemas críticos precisam de algo além da competência individual.
Precisam garantir que o padrão continue sendo aplicado quando aumenta o número de desenvolvedores, quando muda a equipe, quando cresce a frequência de releases e quando a pressão por entrega também aumenta.
É aí que qualidade deixa de ser apenas comportamento e começa a funcionar como infraestrutura.
As regras da organização tornam-se parte do processo. A inspeção ocorre antes da promoção. Violações conhecidas são identificadas sistematicamente. O conhecimento dos especialistas não desaparece: ele é usado para definir e aperfeiçoar os critérios que serão aplicados a todos.
Esse talvez seja um dos próximos passos do DevOps no mainframe: Depois de automatizar build, testes e deployment, automatizar a aplicação das próprias políticas de engenharia.
Porque uma pipeline madura não deveria avaliar apenas se o código está pronto para avançar, mas se ele atende aos critérios de qualidade e às políticas de engenharia definidos pela organização.
About Post Author
