DevOps en mainframe ya ha avanzado lo suficiente como para cambiar la principal pregunta del área. En lugar de preguntarse solamente cómo insertar el código en un pipeline, el foco ahora está en responder: ¿qué criterios garantizan que ese código tiene la calidad necesaria para seguir avanzando sin depender de un revisor humano?
La encuesta de mainframe de BMC de 2025 ayuda a dimensionar este cambio. Entre más de mil profesionales y stakeholders consultados, el 67% afirmó utilizar DevOps en mainframe, frente al 63% del año anterior.
Estas cifras sugieren una etapa importante de madurez. Cuando la automatización deja de ser la excepción, la calidad también debe dejar de depender exclusivamente de la capacidad de una persona para detectar un problema durante la revisión.
En aplicaciones críticas, las buenas prácticas de COBOL y SQL pueden dejar de ser simplemente conocimiento compartido entre desarrolladores experimentados y convertirse en políticas verificadas sistemáticamente durante el ciclo de desarrollo.
Es en este punto donde el control de calidad comienza a acercarse a la gobernanza de ingeniería.
El revisor no debería ser el único lugar donde existe la regla
Toda organización madura cuenta con estándares de desarrollo, aunque una parte de ellos nunca haya sido formalizada por completo.
No utilizar determinada construcción COBOL. Evitar patrones que puedan comprometer la estabilidad. Escribir consultas SQL de determinada manera. Observar ciertos criterios antes de promover un programa. Tratar algunas violaciones como advertencias y otras como bloqueantes.
El problema aparece cuando estas reglas existen principalmente en la experiencia de las personas.
Un desarrollador con más tiempo en la organización conoce los estándares porque participó en incidentes anteriores. Un DBA identifica rápidamente una consulta que puede generar un consumo excesivo. Un especialista en COBOL detecta una construcción que ya provocó retrabajo en otros proyectos. Durante la revisión, ese conocimiento funciona como una especie de memoria operativa de la organización.
Eso tiene valor y seguirá teniéndolo, pero también genera una dependencia difícil de escalar.
Cuanto mayor es la frecuencia de los cambios, más código necesita ser revisado. Cuanto mayor es el número de equipos, mayor es la posibilidad de interpretaciones diferentes sobre un mismo estándar. Y cuanto más rápido es el pipeline, menor debería ser la dependencia de controles que solo ocurren cuando alguien encuentra tiempo para analizar cada caso.
Por lo tanto, la cuestión no es eliminar al revisor. Es evitar que reglas ya conocidas tengan que ser redescubiertas manualmente en cada revisión.
Existe una diferencia importante entre documentar una regla e incorporarla al proceso.
Una organización puede establecer por escrito que determinada práctica SQL debe evitarse. Puede mantener estándares COBOL en documentos internos. Puede ofrecer capacitaciones y realizar revisiones periódicas. Aun así, nada garantiza que la misma verificación se produzca en todos los cambios.
Cuando esa regla pasa a ser inspeccionada automáticamente antes de la promoción del código, cambia de naturaleza.
Deja de ser únicamente una recomendación y comienza a funcionar como política de ingeniería.
Esta lógica ya es común en otras capas de tecnología. Los pipelines verifican dependencias, las pruebas deben superarse antes de un merge, las políticas de seguridad pueden impedir determinados deployments y la infraestructura como código puede validarse automáticamente antes de ser aplicada.
El código mainframe puede seguir el mismo principio.
Eccox Application Quality Control for COBOL analiza el programa fuente a partir de reglas alineadas con los estándares de la organización. Entre los criterios contemplados por la solución se encuentran la optimización de recursos, la estabilidad del entorno, los estándares de codificación y la reducción de retrabajo. El resultado de la inspección identifica violaciones que pueden abordarse todavía durante el desarrollo.
El punto más importante no es simplemente encontrar un error. Es hacer que la aplicación de esa regla sea sistemática.
Un SQL correcto no es necesariamente un SQL adecuado
Esta discusión adquiere otra dimensión cuando llega a Db2.
SQL es un lenguaje flexible. Dos construcciones diferentes pueden producir el mismo resultado funcional y, aun así, presentar comportamientos bastante distintos en términos de CPU, I/O y costo de ejecución.
Para el usuario de la aplicación, ambas “funcionan”. Para una operación de misión crítica ejecutada millones de veces, la diferencia puede ser significativa.
Eccox Application Quality Control for DB2 fue desarrollado para automatizar la inspección de la codificación SQL en el entorno z/OS, verificando tanto aspectos de rendimiento como la adherencia a estándares y reglas previamente establecidos por la organización.
La solución puede incorporarse a las etapas de compilación y promoción e integrarse con herramientas de gestión del ciclo de vida como Endevor y Changeman.
Esto desplaza el análisis hacia un momento clave: antes de que el código inadecuado llegue a producción.
La diferencia es similar a la que existe entre monitorear un problema de rendimiento después del deployment e impedir que una condición ya conocida avance a lo largo del proceso de desarrollo.
Son controles complementarios, pero actúan en momentos diferentes.
La observabilidad muestra lo que está ocurriendo con el sistema en operación. Los quality gates buscan evitar que determinadas condiciones conocidas lleguen hasta allí.
Convertir la calidad en política también resuelve un problema menos visible: la continuidad del conocimiento.
Los mainframes normalmente sostienen aplicaciones que han atravesado varias generaciones de profesionales. Durante ese tiempo, los equipos cambian, los proveedores entran y salen, los estándares evolucionan y nuevas personas necesitan comprender sistemas construidos mucho antes de su llegada.
Si una parte importante de las prácticas de calidad depende únicamente de quienes conocen históricamente el entorno, la salida o indisponibilidad de esas personas también representa una pérdida de control.
Cuando los criterios se formalizan en reglas verificables, parte de ese conocimiento deja de existir únicamente en la mente de los especialistas y pasa a formar parte de la propia ingeniería.
Esto no significa que todas las decisiones puedan convertirse en reglas.
Una inspección automática no comprende por sí sola todas las implicaciones de arquitectura, el contexto de negocio o la intención de un cambio. Tampoco sustituye al code review, las pruebas o el análisis de impacto.
El beneficio está en otra cosa: automatizar aquello que ya sabemos que debe verificarse, preservando el tiempo humano para las decisiones que realmente requieren criterio.
DevOps rápido sin gobernanza solo entrega problemas más rápido
A medida que DevOps madura en el mainframe, esta distinción cobra mayor importancia.
Un pipeline más eficiente reduce el tiempo entre desarrollo y producción. Eso es deseable, pero también reduce el intervalo disponible para detectar problemas.
Si los controles siguen siendo completamente manuales mientras el resto del proceso se acelera, pueden convertirse en el próximo cuello de botella o simplemente ser omitidos en nombre de los plazos.
La respuesta no debería ser elegir entre velocidad y calidad. Debería ser automatizar parte de la calidad para que pueda acompañar la velocidad.
Esto ayuda a situar herramientas como EQC en otra categoría de discusión.
EQC COBOL y EQC DB2 no tienen por qué considerarse únicamente herramientas de optimización de código. Pueden formar parte de una arquitectura de gobernanza del desarrollo, en la que los criterios definidos por la organización se incorporan al flujo y se aplican de forma consistente antes de la promoción.
Una determinada violación puede generar una orientación. Otra puede exigir una corrección. Los criterios y modos de operación pueden variar de acuerdo con las políticas establecidas para cada entorno.
En el caso de EQC DB2, también conocido como EQD, la propia Eccox describe el producto como un filtro de calidad capaz de impedir que código inadecuado sea promovido al entorno productivo.
Esta capacidad hace que el control dependa menos de la eventualidad de que alguien detecte el problema.
La calidad también puede ser infraestructura del desarrollo
Durante mucho tiempo, la calidad del código fue tratada principalmente como una característica del desarrollador: buenos profesionales escriben buen código, revisores experimentados encuentran problemas y equipos maduros siguen buenas prácticas.
Todo esto sigue siendo cierto, pero las organizaciones que operan sistemas críticos necesitan algo más que competencia individual.
Necesitan garantizar que el estándar continúe aplicándose cuando aumenta el número de desarrolladores, cuando cambia el equipo, cuando crece la frecuencia de releases y cuando también aumenta la presión por entregar.
Es ahí donde la calidad deja de ser únicamente un comportamiento y comienza a funcionar como infraestructura.
Las reglas de la organización pasan a formar parte del proceso. La inspección ocurre antes de la promoción. Las violaciones conocidas se identifican sistemáticamente. El conocimiento de los especialistas no desaparece: se utiliza para definir y perfeccionar los criterios que se aplicarán a todos.
Este puede ser uno de los próximos pasos de DevOps en mainframe: después de automatizar build, pruebas y deployment, automatizar la aplicación de las propias políticas de ingeniería.
Porque un pipeline maduro no debería evaluar únicamente si el código está listo para avanzar, sino también si cumple con los criterios de calidad y las políticas de ingeniería definidos por la organización.
About Post Author
