Las complejidades ocultas del lanzamiento de nuevas versiones en IBM^® i

Presentando un nuevo lanzamiento de Rocket^® DevOps siempre es un hito. Representa meses (o años) de esfuerzo de los equipos de desarrollo, pruebas, documentación y soporte. Pero para aquellos de nosotros en IBM^® En un ecosistema como este, el proceso de lanzamiento rara vez es sencillo.

Destaquemos los aspectos menos visibles de los lanzamientos de productos: los desafíos que conllevan la compatibilidad, las actualizaciones y el soporte a largo plazo. Si bien cada proveedor y equipo de producto se enfrenta a sus propios obstáculos, estos tres temas recurrentes son los que he visto surgir con frecuencia durante los ciclos de lanzamiento. Pero ¿cómo pueden las organizaciones sortearlos?

1. Mantenerse al día con las actualizaciones del sistema operativo IBM i

IBM^® i continúa evolucionando, con frecuentes actualizaciones tecnológicas (TR) y lanzamientos importantes periódicos. Cada cambio trae consigo mejoras, pero también riesgos potenciales para los proveedores de software.

• Riesgos de compatibilidad: Incluso pequeños cambios en IBM i pueden alterar el comportamiento de forma que afecte a nuestro producto. Es posible que se descontinúen las API, se mejoren los modelos de seguridad o se reemplacen las herramientas del sistema.
• Requisitos de las pruebas: Antes de cada lanzamiento, invertimos considerablemente en pruebas en múltiples versiones de IBM i para garantizar la estabilidad. Esto requiere no solo esfuerzo técnico, sino también acceso a entornos de prueba que ejecuten cada versión compatible.

Qué puedes hacer:

• Mantener un laboratorio dedicado con entornos que abarquen las versiones de IBM i compatibles.
• Colabore con IBM al inicio del ciclo de actualización tecnológica para anticipar cambios importantes.
• Proporcione a los clientes matrices claras de compatibilidad con las versiones de IBM i.

2. Interdependencias con herramientas de terceros

Las aplicaciones modernas de IBM i rara vez existen de forma aislada. Nuestro producto se integra con Git.^® Control de versiones, plataformas CI/CD, sistemas de gestión de incidencias e incluso soluciones de seguridad. El problema radica en que estas herramientas de terceros evolucionan de forma independiente.

• Desviación de la versión: Una nueva versión de una herramienta de terceros podría interrumpir repentinamente nuestra integración.
• Coordinación de proveedores: Con frecuencia dependemos de las hojas de ruta y las prioridades de otros proveedores, que pueden no coincidir con las nuestras.

Lo que puedes hacer

• Siempre que sea posible, desarrolle integraciones sólidas y basadas en estándares.
• Mantener flujos de pruebas automatizadas que comprueben las integraciones con las versiones más recientes de herramientas de terceros.
• Ofrecemos orientación a los clientes sobre las versiones de terceros “certificadas” que hemos probado.

3. Actualización de clientes desde versiones anteriores de nuestro software.

No todos los clientes actualizan sus productos con frecuencia. Algunos pueden estar utilizando versiones de nuestro producto con cinco, diez o incluso quince años de antigüedad, una estrategia que conlleva un riesgo significativo. Actualizar a los clientes a la última versión rara vez es un proceso que se realiza con un solo clic.

• Se requieren varios pasos intermedios: En ocasiones, la arquitectura del producto ha cambiado tanto que las actualizaciones directas no son posibles. Es posible que los clientes deban pasar por varias versiones intermedias.
• Conversión de datos: Los cambios de esquema y las transformaciones de configuración deben gestionarse cuidadosamente para evitar interrupciones.
• Aversión al riesgo: Es comprensible que los clientes se preocupen por el impacto en las aplicaciones de misión crítica.

Lo que puedes hacer

• Proporcione rutas de actualización claras y documentación que describa los pasos necesarios.
• Siempre que sea posible, proporcione utilidades de migración para automatizar las transiciones de datos y configuración.
• Ofrecemos servicios profesionales o asistencia de socios para actualizaciones complejas.

4. Compatibilidad con versiones anteriores cuando cambian las dependencias.

Incluso después de lanzar una nueva versión, las versiones anteriores siguen en uso. Darles soporte puede ser difícil, especialmente cuando existen dependencias de terceros como Java.^® o los compiladores evolucionan.

Terreno inestable: Por ejemplo, cuando Oracle^® Si IBM modifica sus políticas de soporte para Java, es posible que las versiones anteriores de nuestro producto dejen de funcionar correctamente.
Expectativas del cliente: Algunos clientes esperan que las versiones antiguas sigan recibiendo soporte completo, incluso cuando la plataforma subyacente ya no funcione correctamente.

Lo que puedes hacer

• Defina y comunique una política clara sobre el ciclo de vida del soporte (por ejemplo, versiones N-2).
• Avise a los clientes con antelación cuando los cambios de terceros afecten a versiones anteriores.
• Fomente las actualizaciones proactivas en lugar de la resolución reactiva de problemas.

5. Otros retos que merece la pena mencionar

Los problemas mencionados anteriormente son comunes, pero no son ni mucho menos las únicas dificultades para lanzar una nueva versión. Por ejemplo:

• Localización y soporte multilingüe.
• Diferencias de hardware entre las distintas instalaciones de los clientes.
• Requisitos de cumplimiento de seguridad (por ejemplo, estándares de cifrado).
• Personalizaciones específicas para cada cliente que complican las actualizaciones.
   

Reflexiones finales

Lanzar una nueva versión de software para IBM i nunca se trata solo de añadir funcionalidades. Cada lanzamiento implica un delicado equilibrio entre prioridades, concesiones y mitigación de riesgos. Para Rocket Software, se trata de compatibilidad, continuidad y la confianza de los clientes que dependen de nuestro producto para cargas de trabajo críticas.

Rara vez existe un enfoque único e infalible para el lanzamiento de software, especialmente en entornos complejos como IBM i. El éxito radica en una combinación estratégica de pruebas y validación rigurosas, comunicación clara y consistente, y políticas bien definidas que guíen el soporte y la planificación del ciclo de vida. Cuando estos elementos están presentes, las organizaciones reducen riesgos, mejoran la confiabilidad y fortalecen su credibilidad. Al ser transparentes sobre el proceso, su evolución y las expectativas, fomentamos la confianza y creamos una base más sólida para una colaboración y un rendimiento a largo plazo.

IBM es una marca comercial de International Machines Corporation.

Oracle, Java, MySQL y NetSuite son marcas registradas de Oracle y/o sus filiales. Otros nombres pueden ser marcas comerciales de sus respectivos propietarios.

Git y el logotipo de Git son marcas comerciales registradas o marcas comerciales de Software Freedom Conservancy, Inc., en los Estados Unidos y/o en otros países.