Home›Perspectivas›Artículos›DevOps en IBM i: cómo llevar el core del negocio a integración y despliegue continuo
Blog · Modernización de aplicaciones · Servicios financieros
DevOps en IBM i: cómo llevar el core del negocio a integración y despliegue continuo
Pipelines modernos para la web y el móvil, despliegues manuales para el core. Lo que aprendimos al llevar las aplicaciones de pensiones y cesantías en IBM i de la segunda mayor AFP de Colombia a DevOps con ARCAD.
Un core que administra el ahorro de millones
El sistema privado de pensiones colombiano es enorme: según Asofondos, los fondos administraban más de $525 billones de pesos a septiembre de 2025, en manos de cuatro administradoras. Y es un mercado concentrado: las dos mayores reúnen cerca del 90 % de los afiliados, según datos publicados por La República. Nuestro cliente es la segunda, con alrededor de tres de cada diez afiliados del sistema.
Con esa escala, las aplicaciones de cesantías y pensiones obligatorias no pueden detenerse ni fallar tras un cambio. Pero tampoco pueden quedarse quietas: regulación, nuevos productos y canales digitales exigen que el core evolucione al mismo ritmo que el resto de la organización.
Por qué DevOps "no llega solo" a IBM i
La compañía ya había adoptado DevOps como estrategia de modernización en sus otras plataformas. El core quedó por fuera por una razón concreta: las herramientas open source que funcionan bien para aplicaciones web, móviles y nativas en la nube no son efectivas por sí solas en IBM i. Hace falta una capa de tecnología que entienda la plataforma:
- El código fuente de RPG o COBOL vive tradicionalmente en miembros de archivos fuente, no en archivos planos listos para Git.
- La compilación depende de relaciones entre programas, archivos y objetos que hay que analizar para saber qué recompilar y en qué orden.
- El despliegue implica mover objetos y cambios de base de datos entre bibliotecas y ambientes, con capacidad de reversión.
ARCAD for DevOps: la capa que faltaba
ARCAD for DevOps es una suite modular pensada para resolver precisamente eso. Entre sus capacidades:
- Gestión del código nativo de IBM i con Git y plataformas como GitHub, GitLab o Bitbucket.
- Compilación automatizada basada en el análisis de dependencias entre componentes.
- Pruebas y calidad de código integradas al ciclo.
- Integración con Jenkins, Azure DevOps, Jira y SonarQube , para que IBM i entre en el mismo pipeline que las demás tecnologías.
- DROPS , el módulo de orquestación de liberaciones, para desplegar de forma sincronizada aplicaciones IBM i y cambios de base de datos, con reversión.
Para nuestro cliente, Redsis construyó un pipeline inicial con los componentes básicos —desde la auditoría de las aplicaciones hasta el despliegue en producción— con licenciamiento de ARCAD for DevOps y DROPS, servicios de implantación con soporte de segundo nivel del fabricante, acompañamiento en la parametrización y la operación inicial, y un año de administración delegada de la plataforma.
DevOps en IBM i no se trata de reemplazar la plataforma, sino de darle las mismas prácticas que ya tiene el resto de la organización.
Cinco lecciones para llevar el core a CI/CD
1. Empezar con una prueba de concepto
En este caso, una PoC en un ambiente sandbox le permitió al cliente ver cómo ARCAD integraba las herramientas open source con su entorno antes de adoptarlo. Es la forma más rápida de convertir escepticismo en evidencia.
2. Auditar antes de automatizar
El pipeline arrancó con la auditoría de las aplicaciones. Conocer el inventario de código, sus dependencias y su estado es lo que permite automatizar compilaciones y despliegues sin sorpresas.
3. Un solo estándar para todas las plataformas
El objetivo no era un DevOps "especial" para IBM i, sino el mismo estándar para Windows, Linux, Unix e IBM i. Eso simplifica la gobernanza, la auditoría y la formación de los equipos.
4. Avanzar por etapas
Descubrimiento, implementación, lanzamiento, entrenamiento y transición a producción. Un pipeline inicial con componentes básicos que funciona es mejor punto de partida que un diseño ambicioso que nunca termina.
5. No dejar solo al equipo después del go-live
El cambio es tanto cultural como técnico. El entrenamiento de desarrollo y operaciones, el soporte de segundo nivel del fabricante y un año de administración delegada dan tiempo para que las nuevas prácticas se consoliden.
El resultado: el core entra al mismo ritmo que el resto
Hoy las aplicaciones de cesantías y pensiones obligatorias de la compañía cuentan con un pipeline DevOps de extremo a extremo sobre IBM i: despliegue ágil, continuo y controlado, sin tareas manuales, bajo el mismo estándar multiplataforma que el resto de su software y validado previamente en una prueba de concepto.
¿Por dónde empezar?
Si su organización ya practica DevOps en la web y el móvil pero su core en IBM i sigue con despliegues manuales, el primer paso es una prueba de concepto acotada sobre una aplicación real. En Redsis combinamos más de 25 años de experiencia en plataformas de misión crítica en América Latina con soluciones como ARCAD for DevOps para modernizar el ciclo de vida de sus aplicaciones IBM i.
Lea el caso completo
Conozca cómo la segunda mayor AFP de Colombia llevó su core en IBM i a DevOps con ARCAD.