Hace varios años, Cullen y su equipo comenzaron a automatizar las pruebas de software con el objetivo de mejorar la velocidad con la que podían lanzar nuevas versiones de su plataforma central de gestión de patrimonio digital, Figaro. Funcionó: pudieron reducir días de sus ciclos de prueba.

Pero el equipo de pruebas estaba compartiendo una partición lógica (LPAR) con el equipo de desarrollo y, con el tiempo, su estrategia de pruebas exitosa comenzó a ralentizar el desarrollo de software importante. Cullen y su equipo intentaron solucionar este problema realizando las pruebas fuera del horario laboral, pero no resultó ser lo ideal.

“Haríamos un cambio, esperaríamos a que la prueba se ejecutara de la noche a la mañana, averiguaríamos que habíamos introducido un error, lo arreglaríamos, esperaríamos a que la prueba se ejecutara de la noche a la mañana... una y otra vez, hasta el punto en que estábamos empezando a ralentizar nuestros propios procesos, la dirección opuesta a donde queríamos ir”, explica Cullen.

Figaro es un sistema muy grande, con millones de líneas de código, miles de tablas y alrededor de 25,000 objetos de programa. Históricamente, se ha ejecutado en IBM i en servidores de energía, por lo que el traslado a IBM Power Systems Virtual Server fue natural. Pero la elección de Cullen va más allá de encontrar la combinación adecuada de servidor y sistema operativo.

Con IBM Power Systems Virtual Server y la oferta de prueba como servicio de CSI, Cullen y su equipo tienen toda la potencia informática que necesitan, cuando la necesitan. "Con esta configuración, podemos solicitar un servidor virtual con la versión requerida de Figaro y el conjunto de datos apropiado, ejecutar nuestras pruebas contra él y luego eliminar el servidor virtual", dice Cullen.

La capacidad de acceder a la versión correcta de Figaro es clave. El programa de lanzamiento actual de FNZ requiere nuevas versiones del software cada trimestre, con parches cada dos semanas. Para que las pruebas sean eficientes y rentables, el equipo de Cullen debe ser capaz de acelerar una versión precisa y actualizada del software según sea necesario. "No queremos tener que instalar montones y montones de parches para conseguir un entorno de trabajo que funcione para poder realizar una prueba, que puede durar solo 15 minutos", afirma.

Para lograr esto, el equipo se basa en un enfoque de estilo Docker, que utiliza capas para crear imágenes. “Tiene un punto de partida conocido y va añadiendo capas encima. Tomamos las imágenes estándar de IBM Power y fuimos añadiendo gradualmente más y más software de configuración hasta que tuvimos un entorno totalmente operativo", explica Cullen.

Ahora, el equipo de Cullen ha automatizado todo el proceso de creación de imágenes para mantener todo actualizado, utilizando un programa de vigilancia para identificar artefactos recién publicados. "Digamos que queremos actualizar de la versión 1.2 a la 1.3 de nuestro sistema. Cuando empujamos el parche de la versión 1.3 al repositorio de artefactos, el observador lo ve y luego gira la versión anterior en una máquina virtual, instala el parche de la versión 1.3, guarda los resultados y elimina la máquina virtual".

Como resultado de este proceso, FNZ siempre tiene un entorno listo para la prueba. "Todo lo que tenemos que hacer es encontrar la imagen correcta, girarla, ejecutar las pruebas y listo", dice Cullen.

Además, con el enfoque basado en Docker, si algo en las capas intermedias cambia, no tienen que reconstruir ninguna de las capas circundantes. "Es bastante eficiente", señala Cullen.

La solución CSI también aprovecha la tecnología de administración multinube IBM® Cloud Pak, que funciona en Red Hat OpenShift (enlace externo a ibm.com). Específicamente, las capacidades de gestión de automatización en la nube de la oferta ayudan a FNZ a organizar, crear plantillas y parametrizar las definiciones del sistema Terraform, mientras que los scripts de automatización de Red Hat Ansible (enlace externo a ibm.com) implementan completamente la aplicación.