AI/Codex aperti: spostare l'infrastruttura critica da perl a python

La trasformazione digitale viene spesso chiamata digital disruption. Qualsiasi cambiamento tecnologico importante che sia accaduto nel corso degli anni ha provocato danni. Ma come si fa a far evolvere il proprio stack tecnologico quando questi potenziali danni potrebbero includere servizi mission-critical?

È stato questo il problema affrontato da BAERO, il team interno dell'infrastruttura di test/DevOps di NetApp, che offre strumenti e servizi agli sviluppatori affinché possano costruire e testare il proprio codice prima di inviarlo. Il ruolo di BAERO è quello di aiutare gli sviluppatori a muoversi più velocemente, individuare i problemi di qualità il prima possibile e proteggere i prodotti NetApp^® dalle regressioni. Nel corso degli anni, abbiamo costruito una grande quantità di software per supportare questa missione. Tuttavia, con l'aggiunta di nuovi prodotti e funzioni da parte di NetApp, è necessario che questo software si evolva in modo da supportare questi nuovi ambienti. 

Ad esempio, NetApp ONTAP^® è ora parte di Amazon FSX ma, per fornire questa funzionalità, gli sviluppatori ONTAP devono essere in grado di eseguire, testare ed effettuare il debug di nuove funzionalità in AWS prima del rilascio. Per supportare questi requisiti, BAERO ha esteso servizi e infrastrutture per operare con Amazon FSX. In generale, più velocemente il team BAERO riesce ad aggiungere supporto, più tempestivamente gli sviluppatori NetApp possono rilevare automaticamente le regressioni nel loro codice.

BAERO deve affrontare un difficile equilibrio: dobbiamo muoverci rapidamente, ma al tempo stesso non possiamo disgregare l'infrastruttura utilizzata dai team di sviluppo NetApp 24 ore su 24, 7 giorni su 7, 7 giorni all'anno. Oggi, il codice dell'infrastruttura BAERO è una miscela di librerie e codice perl relativamente nuovi e consolidati, scritti anni fa ma estesi in base alle necessità. Sfortunatamente, il codice perl può rendere più difficile il supporto delle nuove funzionalità e dei nuovi prodotti NetApp, perché l'ecosistema della libreria di perl non è così ricco come quello di python e perl ha meno sviluppatori desiderosi di lavorare al suo interno.

Python consente ai team di muoversi più velocemente e di supportare meglio la nuova generazione di prodotti NetApp. Ma possiamo tradurre la nostra base di codice basata su perl in python senza interrompere i servizi mission-critical lungo il percorso?

Il rilascio di OpenAI/Codex al pubblico nell'agosto del 2021 ha introdotto la possibilità di utilizzare l'intelligenza artificiale e l'apprendimento automatico per aiutare a tradurre il codice da un linguaggio all'altro. Per quel che concerne BAERO, potrebbe aiutare a tradurre il nostro codice perl in python. Ma non tutti i prodotti sono all'altezza delle aspettative, abbiamo dovuto testarli per verificare. Codex potrebbe reggere in situazioni reali? Potrebbe tradurre la nostra base di codici in modo più semplice e più velocemente di quanto farebbe un gruppo di sviluppatori? L'unico modo per scoprirlo era facendo una prova, auspicabilmente senza errori.

Per il test, abbiamo scelto 'run_utest.pl', un'utilità che esegue l'unit testing e interpreta e restituisce i risultati. È anche uno script che si è evoluto oltre le finalità per cui era stato inizialmente progettato. Il codice originale è stato esteso in base alle necessità per aggiungere l'analisi core-dump, il supporto del fuzzing, il supporto della copertura del codice o la diagnosi in loco quando si sono verificati errori rari particolari. Di conseguenza, è diventato uno script perl complicato e di grandi dimensioni, con anni di runtime effettivo alle spalle, pertanto si è trattato di un'esperienza abbastanza impegnativa. Qualsiasi traduzione in una nuova lingua dovrebbe essere eseguita senza compromettere la correttezza dello script, perché la qualità dello script viene consolidata dall'unit testing e lo script viene utilizzato internamente da ogni sviluppatore, centinaia di volte al giorno. 

Al nostro primo utilizzo della traduzione di Codex, è emerso chiaramente che Codex ha i suoi pro e contro: si è rivelato molto efficace in alcune traduzioni ma molto inefficace in altre. L'utilizzo di tale strumento richiede il coinvolgimento di uno sviluppatore che verifichi la correttezza delle traduzioni e modifichi eventuali passaggi errati. Detto questo, è più facile convalidare un nuovo script python che scriverlo da zero, cosa che ha permesso invece di ottenere risultati soddisfacenti.

In sostanza, Codex è un traduttore molto veloce ma imperfetto. Avevamo bisogno di capire come utilizzarlo in modo sicuro per velocizzare il nostro progetto di traduzione. Al termine, il codice tradotto doveva funzionare perfettamente (o quasi) fin dall'inizio. Poiché 'run_utest.pl' viene utilizzato in modo molto intensivo in una build normale, è stato semplice convalidare i risultati nelle situazioni ideali. Risultano invece molto più complessi i numerosi casi limite e percorsi di errore gestiti dalla versione perl (e convalidati al momento della scrittura). Questi devono funzionare nella traduzione python durante l'implementazione. Non c’è spazio per gli errori. 

Ci siamo concentrati sulla riduzione o sull'eliminazione del rischio nella nuova traduzione python. L'approccio ottimale prevede l'esecuzione di una serie di test a cui sottoporre sia i percorsi di errore che le situazioni ideali. Purtroppo, non sono stati eseguiti test di supporto sul codice originale ed è stato possibile verificare la stabilità mediante test manuali del nuovo codice e l'analisi dei problemi dopo l'implementazione delle nuove versioni. 

Abbiamo gestito il rischio della traduzione nei seguenti modi.

• Il codice è stato tradotto direttamente senza refactoring lungo il percorso. Questo rende più semplice per i revisori verificare che il comportamento del codice sia lo stesso in entrambi i linguaggi. Consente inoltre di eseguire test funzionali e delle prestazioni affiancati (in base alle singole funzioni).
• Il codice è stato tradotto e testato un po' alla volta, rivisto e inviato. Le dimensioni ridotte delle revisioni consentono ai revisori di individuare più facilmente i problemi e agli sviluppatori di registrare progressi lenti ma costanti. 
• È stato eseguito il test del vecchio e del nuovo codice con gli stessi input. Poiché il nuovo codice dovrebbe comportarsi allo stesso modo del vecchio codice, sono state esaminate tutte le differenze nell'output.
• Eseguiamo unit testing in modo intensivo. Il nostro focus è diventato la verifica di ogni singola riga di codice. Può risultare difficile trovare ogni percorso di errore naturalmente, ma con il Mocking di Pytest, spesso è possibile testare tutte le righe di codice, una per una.

In definitiva la nuova versione include una funzionalità di testing migliore dell'originale e la scelta di testare tutto il codice ha consentito di identificare molti problemi di traduzione del percorso di errore che non apparivano nelle situazioni ideali.

Oggi la porta è completa di tutte le funzionalità e può eseguire l'intero flusso di lavoro di unit testing. Il lavoro continua ad aumentare la copertura dell'unit testing (>80% rispetto allo 0% precedente) prima dell'implementazione. Una sorpresa è stata un bug nell'implementazione di perl originale; il codice perl stava inglobando tipi specifici di codice di uscita. Il problema si nasconde nell’ATTUALE infrastruttura di unit testing; è un problema piuttosto raro ma reale. In origine sembrava un problema di traduzione, ma in seguito a un'indagine, si è riscontrato che la versione python era più rigorosa della versione perl. Questo problema da solo è probabilmente una giustificazione sufficiente per il progetto di traduzione.

Con un'elevata copertura dell'uni testing, attraverso test di integrazione completi (validati fianco a fianco con l'output perl) e molte iterazioni di esecuzione, abbiamo implementato la versione python di run_utest per circa il 5% degli obiettivi di unit testing.

Aumenteremo progressivamente questa percentuale, passando al 100% dopo aver corretto gli unit test con gli errori nascosti dalla versione perl originale di run_utest.

Dopo un'esperienza molto positiva con OpenAI/Codex, siamo pronti per cominciare. OpenAI/Codex ha letteralmente cambiato ciò che riteniamo sia possibile per il team di sviluppo di BAERO. In passato, avremmo scritto nuovi progetti in python, mantenendo l'infrastruttura perl fino a quando un particolare pezzo non fosse diventato insostenibile, quindi lo avremmo riscritto in python. Con OpenAI/Codex nei nostri strumenti di sviluppo, ora abbiamo un lungo elenco di software di infrastruttura che tradurremo in modo proattivo, con un modello efficace per il successo del progetto.

Alla fine:

OpenAI/Codex aiuterà BAERO a muoversi più velocemente.
OpenAI/Codex aiuterà gli sviluppatori NetApp a testare più velocemente le nuove funzionalità.
OpenAI/Codex aiuterà NetApp a fornire software di qualità superiore ai nostri clienti più velocemente. 

Perl->Python è solo l'inizio. OpenAI/Codex ha il potenziale per sbloccare e accelerare nuove funzioni, scalabilità e prestazioni NetApp nei prodotti NetApp stessi.

Anche se OpenAI/Codex è solo l'inizio, è possibile iniziare a sperimentarlo subito, qui. Gestendo il rischio con i test/processi appropriati, OpenAI/Codex è già in grado di accelerare la traduzione di codice legacy in nuove lingue.