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 代码正在吞噬特定类型的退出代码。问题隐藏在 CURRENT 单元测试基础架构中；这是一个相当罕见但确实存在的问题。最初，它看起来像一个转换问题，但调查后发生，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 已经可以加快将旧代码转换为新语言的速度。