OpenAI/Codex：將關鍵基礎架構從 perl 移轉至 python

數位化轉型通常被稱為數位革命，很難確定過去幾年發生的重大技術變革有沒有造成任何損害。但是，當潛在損害範圍可能包括任務關鍵型服務時，您該如何發展您的技術堆疊？

這是 NetApp 內部 DevOps / 測試基礎架構團隊 BAERO 所面臨的困境，該團隊提供工具和服務，讓開發人員在提交程式碼之前先建置和測試程式碼。BAERO 的職責是協助開發人員更快地行動、儘早解決品質問題，並保護 NetApp^® 產品免於多次遞迴修正。多年來，我們建置了大量軟體來支援這項任務。但隨著 NetApp 增加新產品和功能，此軟體也必須不斷發展以支援這些新環境。 

例如，NetApp ONTAP^® 現在是 Amazon FSX 的一部分，但為了提供這項功能，ONTAP 開發人員必須能夠在功能發布之前，先在 AWS 中執行、測試和除錯新功能。為了支援這些需求，BAERO 擴充了服務和基礎架構，以與 Amazon FSX 搭配運作。一般而言，BAERO 新增支援的速度越快，NetApp 開發人員就能越早自動擷取他們 程式碼的 遞迴修正。

BAERO 面臨一個棘手的平衡問題：我們必須快速行動，但同時，我們不能破壞 NetApp 開發團隊全年無休使用的基礎架構。如今，BAERO 基礎架構程式碼結合了相對較新的 python 和久經考驗的 Perl 程式碼，以及多年前撰寫但可視需要擴充的程式庫。可惜的是，由於 perl 的程式庫生態系統不像 python 那麼豐富，而且渴望使用 perl 的開發人員較少，因此 perl 程式碼可能會讓支援 NetApp 的新功能和產品變得更加困難。

Python 讓團隊能夠更快行動，並更有效地支援新一代的 NetApp 產品。但是，我們能否將 perl 程式碼庫轉換為 Python 而不破壞任務關鍵型服務呢？

OpenAI/Codex 於 2021 年 8 月向大眾發布，引進了使用人工智慧和機器學習來協助在語言之間轉譯程式碼的可能性。對於 BAERO 而言，這有助於將我們的 perl 程式碼庫轉換為 python。但並非所有產品都符合預期，我們需要測試才能相信。Codex 在實際環境中是否有效？它是否能比一群開發人員更快、更輕鬆地轉譯我們的程式碼庫？找出答案的唯一方法就是透過嘗試和（希望沒有）錯誤。

對於測試，我們選擇了「run_utest.pl 」，這是一個負責執行單元測試，以及解譯和傳回結果的公用程式。它也是一個超越原本設計的指令碼。我們視需要擴充了原始程式碼，加入了核心傾印分析、模糊支援、程式碼涵蓋範圍支援，或在發生特定罕見故障時進行當場診斷。它成為一個巨大而複雜的 perl 指令碼，背後是已經運作多年的實際環境執行階段，因此使用起來令人膽顫心驚。任何轉譯至新語言的作業都必須以不會影響指令碼正確性的方式進行，因為指令碼會執行單元測試來提高品質，並且每位開發人員每天都會在內部使用數百次。 

在我們第一次使用 Codex 轉譯時，很明顯 Codex 有其優缺點：有些轉譯的很好，但其他轉譯卻很糟糕。使用它需要有開發人員在中間驗證轉譯的正確性並修改任何錯誤。也就是說，驗證新的 python 指令碼比從頭開始撰寫更容易，所以這樣做是有希望的結果。

Codex 本質上是一個非常快速但不完美的轉譯程式。我們需要瞭解如何安全地使用它來加速我們的轉譯專案。當我們完成時，轉譯後的程式碼必須從一開始就能完美（或接近完美）運作。由於「run_utest.pl 」在標準建置中被大量使用，因此要驗證「晴天（平安無事）」情況很簡單。然而，perl 版本處理的許多極端情況和錯誤路徑（撰寫時已經過驗證）則較為困難。在我們部署時，這些必須在 python 轉譯中運作。並且沒有錯誤的餘地。 

我們專注於降低或消除新 python 轉譯的風險。理想情況下，我們會進行一系列測試來測試錯誤路徑和晴天情況。遺憾的是，原始程式碼並未進行後援測試，而是透過手動測試新的程式碼，然後在部署新版本後觀察有哪些問題來強制提升穩定性。

我們以下列方式迅速處理轉譯風險。

• 直接轉譯程式碼，整個過程無需重構。如此一來，檢閱者就能更輕鬆地驗證程式碼在這兩種語言中的功能是否相同。它還支援並行功能和效能測試（針對每個功能）。
• 一次轉譯並測試少許程式碼、檢閱然後提交。較小的檢閱規模讓檢閱者更容易發現問題，也讓開發人員更容易看到緩慢但穩定的進展。 
• 使用相同的輸入測試舊程式碼和新程式碼。由於新程式碼的行為方式應與舊程式碼相同，因此可調查其輸出中的任何差異。
• 我們不斷進行單元測試。我們專注於執行每一行程式碼。自然地觸及每個錯誤路徑可能很困難，但透過 pytest 豐富的模擬，通常可以實操到每一行程式碼。

最後，新版本的測試結果比原始版本好得多，而執行所有程式碼的行為發現了許多錯路徑轉譯問題，這些問題在晴天情況下並未顯現出來。

截至今天，連接埠功能已完成，可執行整個單元測試工作流程。在部署之前，我們將繼續努力提高單元測試涵蓋範圍（大於 80%，之前為 0%）。其中一個驚喜是找到原始 perl 實作中的錯誤；最初 perl 程式碼誤食了特定類型的結束程式碼，在目前的單元測試基礎架構中該問題隱藏不見，這是一個相當罕見但確實存在的問題。原本看起來像是轉譯問題，但經過調查後，python 版本比 perl 版本更嚴格，光是能夠找出這個問題可能就足以證明轉譯專案的合理性。

由於涵蓋範圍極廣、整合測試極高（與 perl 輸出進行並行驗證）、執行次數也很多，因此我們已針對大約 5% 的單元測試目標部署了 python 版本的 run_utest。

我們會修正隱藏在原始 perl 版本的 run_utest 中的錯誤，並慢慢增加這個數字直到 100%。

在 OpenAI/Codex 獲得非常正面的體驗之後，我們準備全力以赴。OpenAI/Codex 確實改變了我們認為 BAERO 開發團隊可以做到的事情。在過去，我們會使用 python 撰寫新專案，同時維護 perl 基礎架構，直到某個特定片段再也無法運作為止...然後使用 python 重新撰寫它。透過我們開發工具箱中的 OpenAI/Codex，我們現在擁有許多基礎架構軟體，我們將主動轉譯這些軟體，制定藍圖來取得專案成功。

最後：

OpenAI/Codex 將協助 BAERO 更快地移動。
OpenAI/Codex 將協助 NetApp 開發人員更快測試新功能。
OpenAI/Codex 將協助 NetApp 以更快的速度為客戶提供更高品質的軟體。 

Perl->Python 只是開始而已。OpenAI/Codex 有潛力充分發揮和加速 NetApp 產品本身的新 NetApp 功能、擴充性和效能。

雖然 OpenAI/Codex 才剛起步，但您應該盡快試用，詳情請參閱此處。OpenAI/Codex 透過正確的測試 / 程序來管理風險，已經可以加速將舊版程式碼轉譯為新語言了。