OpenAI Codex : Transférer les infrastructures stratégiques de Perl à Python

La transformation digitale est souvent appelée disruption digitale. Rares sont les virages technologiques majeurs qui se sont produits au fil des années sans laisser de dégâts dans leur sillage. Mais comment faire évoluer votre pile technologique alors que les dommages potentiels risquent d'affecter des services stratégiques ?

C'est le dilemme auquel a été confrontée BAERO, l'équipe interne infrastructure DevOps/Test de NetApp, qui fournit des outils et des services aux développeurs pour créer et tester leur code avant de le soumettre. Le rôle de BAERO est d'aider les développeurs à avancer plus rapidement, à détecter les problèmes de qualité au plus tôt et à protéger les produits NetApp^® contre les régressions. Au fil des ans, nous avons développé un grand nombre de logiciels pour mener à bien cette mission. Mais à mesure que NetApp ajoute de nouveaux produits et de nouvelles fonctionnalités, ces logiciels doivent évoluer pour prendre en charge ces nouveaux environnements. 

Par exemple, NetApp ONTAP^® fait désormais partie d'Amazon FSx, mais pour proposer cette fonctionnalité, les développeurs ONTAP doivent être en mesure d'exécuter, tester et déboguer les nouvelles fonctionnalités dans AWS avant leur sortie. Pour répondre à ces exigences, BAERO a étendu ses services et son infrastructure afin de travailler avec Amazon FSx. D'une manière générale, plus BAERO arrive à accélérer la prise en charge, plus les développeurs NetApp arrivent à détecter automatiquement les régressions dans leur code.

BAERO doit trouver un équilibre délicat : il faut aller plus vite, mais sans briser l'infrastructure utilisée par les équipes de développement NetApp 24 h/24, 7 j/7. Aujourd'hui, le code d'infrastructure de BAERO est un mélange de Python relativement nouveau et de code et bibliothèques Perl éprouvés écrits il y a plusieurs années, puis étendus au fur et à mesure des besoins. Malheureusement, le code Perl peut compliquer la prise en charge des nouvelles fonctionnalités et des nouveaux produits NetApp, car l'écosystème de bibliothèques Perl n'est pas aussi riche que celui de Python, et moins de développeurs désirent travailler avec Perl.

Python permet aux équipes d'évoluer plus rapidement et de mieux prendre en charge la nouvelle génération de produits NetApp. Mais pouvons-nous traduire notre base de code Perl en Python sans interrompre les services stratégiques en cours de route ?

Avec la sortie d'OpenAI Codex en août 2021, il est désormais possible d'utiliser l'intelligence artificielle et le machine learning pour aider à traduire le code d'un langage à l'autre. Pour BAERO, cela pourrait l'aider à traduire notre base de code Perl en Python. Mais tous les produits ne sont pas à la hauteur des attentes ; il nous fallait d'abord le tester pour en être sûrs. Codex tiendrait-il la route dans des situations réelles ? Pourrait-il traduire notre base de code plus rapidement et plus facilement qu'un groupe de développeurs ? La seule façon de le savoir était de procéder par essais et (espérons-le) sans erreurs.

Pour le test, nous avons choisi « run_utest.pl », un utilitaire qui se charge de l'exécution des tests unitaires, et de l'interprétation et de la restitution des résultats. Ce script a également évolué au-delà de sa conception initiale. Le code d'origine a été étendu au fur et à mesure des besoins pour ajouter l'analyse du core dump, la prise en charge du fuzzing et de la couverture de code, et le diagnostic immédiat en cas de défaillances rares particulières. Il est devenu un gros script Perl compliqué après des années d'exécution dans le monde réel. Il était donc plutôt terrifiant de l'utiliser pour expérimenter. Toute traduction vers un nouveau langage doit être effectuée sans mettre en péril l'exactitude du script, car celui-ci assure la qualité en exécutant des tests unitaires et est utilisé en interne par tous les développeurs, des centaines de fois par jour. 

Lors de notre première utilisation de la traduction Codex, il est apparu clairement que l'outil présentait des avantages, mais aussi des inconvénients : il était excellent pour certaines traductions, mais très mauvais pour d'autres. Il fallait qu'un développeur soit présent pour vérifier les traductions et corriger les erreurs éventuelles. Cela dit, il est plus facile de valider un nouveau script Python que de l'écrire à partir de zéro, ce qui a donné un résultat prometteur.

En substance, Codex est un traducteur très rapide, mais imparfait. Nous devions trouver comment l'utiliser en toute sécurité pour accélérer notre projet de traduction. Lorsque nous avons terminé, le code traduit devait fonctionner parfaitement (ou presque) dès le départ. Étant donné que « run_utest.pl » est largement utilisé dans une build normale, il était facile de valider les situations les plus favorables. Cependant, les nombreux problèmes et chemins d'erreur gérés par la version Perl (et qui ont été validés lors de l'écriture) sont beaucoup plus difficiles. Ceux-ci doivent fonctionner dans la traduction en Python lorsque nous déployons. Il n'y a pas de place pour l'erreur. 

Nous nous sommes concentrés sur la réduction ou l'élimination du risque dans la nouvelle traduction en Python. Idéalement, nous aurions disposé d'une série de tests permettant de vérifier à la fois les chemins d'erreur et les situations les plus favorables. Malheureusement, il n'y a pas eu de tests de sauvegarde sur le code d'origine, et la stabilité était assurée par des tests manuels sur le nouveau code, puis par l'observation des problèmes après le déploiement des nouvelles versions. 

Nous avons abordé le risque de traduction de la manière suivante.

• Nous avons traduit le code directement, sans le remanier en cours de route. Il est ainsi plus facile pour les réviseurs de valider que le code fait la même chose dans les deux langages. Cela permet également d'effectuer des tests fonctionnels et de performance côte à côte (par fonction).
• Nous avons traduit et testé petit à petit, révisé et soumis. La taille réduite des révisions permet aux réviseurs de détecter plus facilement les problèmes et aux développeurs de constater les progrès lents, mais constants. 
• Nous avons testé l'ancien code et le nouveau avec les mêmes entrées. Étant donné que le nouveau code doit se comporter de la même manière que l'ancien, tout écart de résultat a été étudié.
• Nous avons effectué des tests unitaires à tout-va. Nous nous sommes attachés à tester chaque ligne de code. Il est parfois difficile de détecter tous les chemins d'erreur naturellement, mais avec la richesse du mocking de pytest, il est souvent possible d'exercer chaque ligne de code.

En fin de compte, la nouvelle version est bien mieux testée que l'originale, et l'exercice de tout le code a permis de trouver de nombreux problèmes de traduction des chemins d'erreur qui ne s'étaient pas manifestés dans la situation la plus favorable.

À ce jour, le module est complet et peut exécuter l'ensemble du workflow des tests unitaires. Le travail se poursuit pour augmenter la couverture des tests unitaires (> 80 % contre 0 % auparavant). L'équipe a eu la surprise de trouver un bogue dans l'implémentation originale de Perl : le code Perl avalait des types spécifiques de code de sortie. Le problème se cache dans l’infrastructure de test unitaire ACTUELLE ; il est assez rare, mais réel. À l'origine, il semblait s'agir d'un problème de traduction, mais après enquête, la version Python était plus stricte que la version Perl. La découverte de ce problème suffit probablement, à elle seule, à justifier le projet de traduction.

Avec une couverture élevée des tests unitaires, des tests d'intégration approfondis (validés côte à côte avec une sortie Perl) et de nombreuses itérations d'exécution, nous avons déployé la version Python de run_utest pour environ 5 % des cibles des tests unitaires.

Nous allons lentement augmenter ce nombre et passer à 100 % après avoir corrigé les tests unitaires avec les erreurs cachées par la version Perl originale de run_utest.

Après une expérience très positive avec OpenAI Codex, nous sommes prêts à nous lancer. OpenAI Codex a littéralement repoussé les limites de l'équipe de développement BAERO. Auparavant, nous aurions écrit de nouveaux projets en Python, tout en maintenant l'infrastructure Perl jusqu'à ce qu'un élément particulier devienne bloquant... puis nous l'aurions réécrit en Python. Avec OpenAI Codex dans notre boîte à outils de développement, nous disposons à présent d'une longue liste de logiciels d'infrastructure que nous allons traduire de manière proactive, avec un plan pour assurer la réussite du projet.

En fin de compte :

OpenAI Codex aidera BAERO à avancer plus vite.
OpenAI Codex aidera les développeurs de NetApp à tester plus tôt les nouvelles fonctionnalités.
OpenAI Codex aidera NetApp à livrer plus rapidement des logiciels de meilleure qualité à ses clients. 

La traduction Perl/Python n'est qu'un début. OpenAI Codex a le potentiel de débloquer et d'accélérer les nouvelles fonctionnalités, l'évolutivité et les performances des produits NetApp eux-mêmes.

Alors que OpenAI Codex n'en est qu'à ses débuts, vous devriez commencer à l'expérimenter bientôt, ici. En gérant les risques avec les bons tests/processus, OpenAI Codex peut déjà accélérer la traduction du code hérité dans de nouveaux langages.