OpenAI/Codex: Cómo llevar la infraestructura crítica de Perl a Python

La transformación digital se conoce a menudo como disrupción digital. Es difícil identificar cambios tecnológicos importantes que se hayan producido a lo largo de los años y que no hayan dejado algún daño a su paso. Pero, ¿cómo puede evolucionar tu pila tecnológica cuando ese daño potencial podría incluir servicios de misión crítica?

Este fue el dilema al que se enfrentó BAERO, el equipo interno de infraestructura de DevOps/Test de NetApp, que proporciona herramientas y servicios para que los desarrolladores creen y prueben su código antes de enviarlo. La función de BAERO es ayudar a los desarrolladores a avanzar más rápido, detectar problemas de calidad lo antes posible y proteger los productos de NetApp^® de las regresiones. A lo largo de los años, hemos creado una gran cantidad de software para respaldar esta misión. Pero, a medida que NetApp añade nuevos productos y funciones, este software debe evolucionar para dar cabida a estos nuevos entornos. 

Por ejemplo, NetApp ONTAP^® ahora forma parte de Amazon FSx, pero para ofrecer esta funcionalidad, los desarrolladores de ONTAP deben poder ejecutar, probar y depurar nuevas funciones en AWS antes de su lanzamiento. Para respaldar estos requisitos, BAERO amplió los servicios y la infraestructura para trabajar con Amazon FSx. En general, cuanto más rápido pueda BAERO añadir soporte, antes podrán los desarrolladores de NetApp detectar regresiones en su código.

BAERO se enfrenta a un equilibrio complicado: tenemos que actuar con rapidez, pero al mismo tiempo, no podemos romper la infraestructura que los equipos de desarrollo de NetApp utilizan ininterrumpidamente. Hoy en día, el código de infraestructura de BAERO es una mezcla de código Python relativamente nuevo y bibliotecas y Perl curtido en mil batallas, escrito hace años pero ampliado en función de la necesidad. Por desgracia, el código Perl puede dificultar la compatibilidad con las nuevas funciones y productos de NetApp, porque el ecosistema de bibliotecas de Perl no es tan rico como el de Python y no es que haya muchos desarrolladores deseando trabajar en Perl.

Python permite a los equipos avanzar más rápido y ofrece una mejor compatibilidad para la siguiente generación de productos de NetApp. Pero, ¿podemos traducir nuestro código base de Perl a Python sin interrumpir los servicios de misión crítica por el camino?

El lanzamiento de OpenAI/Codex al público en agosto de 2021 introdujo la posibilidad de utilizar la inteligencia artificial y el aprendizaje automático para ayudar a traducir código entre lenguajes. Para BAERO, esto significaba que podría ayudar a traducir nuestra base de código Perl a Python. Pero no todos los productos están a la altura de las expectativas; necesitábamos probarlo para creer. ¿El Codex resistiría situaciones del mundo real? ¿Podría traducir nuestro código base de forma más rápida y sencilla que un grupo de desarrolladores? La única forma de averiguarlo era mediante prueba y (con suerte, no) error.

Para la prueba, elegimos 'run_utest.pl', una utilidad responsable de ejecutar pruebas unitarias e interpretar y devolver resultados. También es un script que ha evolucionado más allá de su diseño original. El código original se amplió según fue necesario para agregar el análisis del volcado de núcleo, el fuzzing, la cobertura de código o el diagnóstico en el momento cuando ocurrían fallos particularmente raros. Como resultado, se convirtió en un script Perl grande y complicado, con años de tiempo de ejecución detrás en el mundo real y, por lo tanto, era algo aterrador experimentar con él. Cualquier traducción a un nuevo lenguaje debía realizarse de una manera que no pusiera en riesgo la exactitud del script, porque el script refuerza la calidad mediante la ejecución de pruebas unitarias y cada desarrollador lo utiliza internamente cientos de veces al día. 

Cuando usamos por primera vez la traducción del Codex, quedó claro que el Codex tiene sus pros y sus contras: fue excelente en algunas traducciones pero muy malo en otras. Usarlo requería tener un desarrollador en el medio verificando las traducciones y corrigiendo cualquier error. Dicho esto, es más fácil validar un nuevo script de Python que escribirlo desde cero, lo que dio lugar a un resultado prometedor.

Básicamente, el Codex es un traductor muy rápido pero imperfecto. Teníamos que descubrir cómo usarlo de forma segura para acelerar nuestro proyecto de traducción. Cuando termináramos, el código traducido debería funcionar perfectamente (o casi) desde el principio. Como 'run_utest.pl' se usa tanto en una compilación normal, fue sencillo validar las situaciones de «día soleado». Sin embargo, los numerosos casos extremos y rutas de error que maneja la versión de Perl (y que fueron validados cuando se escribió) son mucho más difíciles. Estos deben funcionar en la traducción de Python cuando los implementemos. No hay margen de error. 

Nos centramos en reducir o eliminar el riesgo en la nueva traducción de Python. Lo ideal sería haber tenido un conjunto de pruebas que ejercitaran tanto las rutas de error como los escenarios perfectos o de «día soleado». Por desgracia, no hubo pruebas de respaldo sobre el código original y la estabilidad se aplicó probando manualmente el nuevo código y observando los problemas después de que se implementaran las nuevas versiones. 

Abordamos el riesgo de traducción de las siguientes maneras.

• Tradujimos el código directamente sin refactorizar por el camino. Esto facilita que los revisores validen que el código hace lo mismo en ambos lenguages. También permite pruebas funcionales y de rendimiento en paralelo (por función).
• Tradujimos, probamos, revisamos y enviamos. Poco a poco. Los tamaños de revisión más pequeños facilitan que los revisores detecten problemas y que los desarrolladores vean el progreso lento pero constante. 
• Probamos el código antiguo y el nuevo con las mismas entradas. Dado que el nuevo código debería comportarse de la misma manera que el código anterior, investigamos cualquier diferencia en el resultado.
• Hicimos pruebas unitarias como locos. Nos concentramos en ejercitar cada línea de código. Encontrar todas las rutas de error de forma natural puede resultar difícil pero, con las pruebas mock de pytest, por lo general es posible ejercitar todas las líneas de código.

Al final, las pruebas de la nueva versión son mucho mejores que la original, y el hecho de ejercitar todo el código reveló muchos problemas de traducción de rutas de error que no se manifestaron en el escenario «soleado».

Desde hoy, el puerto tiene todas las funciones y puede ejecutar todo el flujo de trabajo de prueba unitaria. Seguimos trabajando para aumentar la cobertura de las pruebas unitarias (>80 % frente al 0 % anterior) antes de su implementación. Una sorpresa fue encontrar un error en la implementación original de Perl; el código Perl estaba tragándose tipos específicos de código de salida. El problema estaba en la infraestructura CURRENT de pruebas unitarias; es un problema bastante raro pero real. Originalmente parecía un problema de traducción, pero tras investigarlo, la versión Python era más estricta que la versión Perl. El solo hecho de encontrar este problema probablemente ya fuera justificación suficiente para el proyecto de traducción.

Con una alta cobertura de pruebas unitarias, pruebas de integración exhaustivas (validadas en paralelo con resultados de Perl) y muchas iteraciones de ejecución, hemos implementado la versión Python de run_utest para aproximadamente el 5 % de los objetivos de las pruebas unitarias.

Aumentaremos poco a poco este número hasta llegar al 100 %, después de corregir los errores ocultos de la versión Perl original de run_utest en las pruebas unitarias.

Después de una experiencia muy positiva con OpenAI/Codex, estamos listos para ir a por todas. OpenAI/Codex ha cambiado literalmente lo que creemos que es posible hacer en el equipo de desarrollo de BAERO. En el pasado, habríamos escrito los nuevos proyectos en Python, mientras manteníamos la infraestructura de Perl hasta que una pieza en particular se volviera insostenible... y luego lo reescribiríamos en Python. Con OpenAI/Codex en nuestra caja de herramientas de desarrollo, ahora tenemos una larga lista de software de infraestructura que vamos a traducir de forma proactiva, con un plan para hacer que el proyecto sea todo un éxito.

Al final:

OpenAI/Codex ayudará a BAERO a avanzar más rápido.
OpenAI/Codex ayudará a los desarrolladores de NetApp a probar las nuevas funciones antes.
OpenAI/Codex ayudará a NetApp a enviar software de mayor calidad a nuestros clientes a un ritmo más rápido. 

Perl->Python es solo el principio. OpenAI/Codex tiene el potencial de desbloquear y acelerar nuevas funciones, escalabilidad y rendimiento de NetApp en los propios productos de NetApp.

Si bien OpenAI/Codex apenas está empezando, deberías comenzar a experimentarlo cuanto antes, aquí. Al gestionar el riesgo con las pruebas y procesos adecuados, OpenAI/Codex ya puede acelerar la traducción del código heredado a nuevos lenguages.