LinkedIn 是如何逐步淘汰 Python 2 的?

随着 2020 年 1 月 1 日的到来,长达 20 年的一代传奇 Python 2 终于落幕了,永久退出舞台。InfoQ 曾经发表过《Python 2 宣布正式退休,Python 3 时代到来!》、《从 Python 2 到 Python 3,“迁移与否”是个大问题》、《R.I.P Python 2.x:尽管风靡一时,但现在该说再见了》等多篇文章,今天我们翻译了 LinkedIn 的工程师 Barry Warsaw 的文章,讲述了 LinkedIn 是如何从 Python 2 迁移到 Python 3 的,相信对国内大规模使用 Python 的公司有所启迪。

Python 2 的第一个版本发布近 20 年后,在 Python 3 的第一个版本发布 11 年后,Python 开发社区已经淘汰了 Python 2.7,这是 Python 2 系列的最后一个版本。这标志着 Python 2 所有上游支持(包括 Bug 和安全修复)的终结,并让开发人员将他们的时间和精力完全投入到 Python 3 上。Python 3 速度更快,提供了更多的一致性,并为开发人员带来了许多优秀的特性(例如,asynciotype hinting)。

具体的迁移过程

在 2018 年,为了全面迁移到 Python 3 代码库,LinkedIn 投入了长达多个季度的工作。在历经大约两个季度的计划和两个季度的执行后,LinkedIn 在新产品甚至现有产品的新版本中逐步淘汰了 Python 2 的使用。这次迁移是由 LinkedIn 的 Python Foundation 团队领导的,多个团队和部门扮演着一个整体的角色,以确保迁移执行的相对顺畅。这次迁移的工作总共需要迁移大约 550 个代码仓库(库、应用程序和服务)。值得赞扬的是,LinkedIn 的同事理解这次迁移的必要性,并在将 LinkedIn 的基础设施迁移至未来的过程中做出了自己的贡献。

在 LinkedIn,Python 不仅用于为 LinkedIn 的会员提供在线体验,还用于访问内部系统和服务,包括部署工具、CI/CD 框架、脚本、命令行界面、数据科学工具等。除了 Java 和 JavaScript,Python 是 LinkedIn 工程师们完成任务的关键语言。LinkedIn 并没有在其产品中使用 Python,也没有将它作为一个独立的 Web 服务来使用,而是拥有数百个独立的微服务和工具,以及数十个支持库,这些都由独立团队在单独的仓库中所拥有。这些仓库之间的关系可由复杂的依赖关系图表示。

LinkedIn 的迁移故事早在正式迁移开始之前就已经开始了。随着 Python 3 在更大的开源生态系统中变得越来越重要,LinkedIn 的大多数内部库都被移植为“双语”的,这意味着它们可以在 Python 2 或 Python 3 中使用。这一方法,长期以来一直被认为是理想的标准,因为它为这些库的使用者提供了一个平稳的过渡期。如果开发人员小心谨慎,并且库有一个非常清晰的模型,说明哪些数据是字节、哪些数据是文本(人类可读的字符串,即 Unicode),那么这也不是很难做到的事。Python 2 融合了这两个截然不同的概念,但 Python 3 迫使用户理解并明确表示文本数据模型。这是加强数据一致性和避免大多数可怕的 UnicodeError 所必需的,这些 UnicodeError 可能会困扰 Python 2 代码库。

在 LinkedIn 漫长的迁移历史中,这是成功移植所需的最关键的明确性。双语库意味着你不能充分利用 Python 3 的许多最吸引人的新特性。但是,只要 Python 2 仍然受支持,这种折衷就是值得的,因为双语库允许那些库的用户在方便的时候用最少的资源移植到 Python 3。另一方面,应用程序通常不需要使用双语,它们只在一个 Python 版本中运行,因此,它们可以利用 Python 3 的所有新特性、模块和改进。

考虑到这次迁移影响了如此众多的不同团队和数千名工程师的所有 LinkedIn 工程,这项工作是由 LinkedIn 的 Horizontal Initiative(HI)计划监督的。Python Foundation 团队充当了焦点,积极与所有工程领域的开发人员合作,分析 LinkedIn 现有的代码库。他们确定了产品所有者,创建工作单位,回答出现的问题,审查变更,并跟踪即将到来的截止日期。LinkedIn 有大约 550 个仓库需要移植,因此给了自己和合作伙伴两个季度来完成整个计划。

LinkedIn 将工作分为两个阶段进行,连续几个季度进行实施:

  • 第一个阶段: 在 2019 年第一季度,LinkedIn 执行了详细的依赖关系图的绘制,确定了一些更基础的仓库,因此需要首先进行全面的移植,因为它们会阻塞依赖它们的所有端口。其中包括一些与 Python 3 不兼容的内部库,以及没有阻塞依赖关系的应用程序(命令行工具和微服务)。这是在大约 75 个仓库中计算出来的,这在一个季度内就可以很容易完成,并为 LinkedIn 提供了许多重要的经验、反馈和信心来启动整个移植工作。
  • 第二个阶段: 在 2019 年第二季度,LinkedIn 确定了需要移植的仓库的其余部分,以及由于任何原因而错过最后期限的第一阶段仓库的任何迁移。

通过这种分阶段的方法,LinkedIn 实现了目标完工日期。LinkedIn 对构建系统进行了更改,禁用了构建 Python 2 应用程序的能力,并停止构建内部 Python 库的 Python 2 版本。

请注意,从任何双语库中删除 Python 2 支持显然不是一个目标。然而,既然 LinkedIn 已经完成了迁移,LinkedIn 的库所有者就有机会放弃 Python 2,并对他们的代码库进行现代化升级,利用任何适当的 Python 3 特性使他们的代码更具可读性或更高效。

迁移后的反思

LinkedIn 完成多产品迁移的主要指标是成功构建并通过单元和集成测试。对于具有高覆盖率测试套件的仓库,这在实践中效果很好。但是,LinkedIn 的一些代码库的覆盖率很低。虽然通过构建和测试仍然是 LinkedIn 最好的信号,但 LinkedIn 对端口保真度的信心有时会因那些较低的测试覆盖率而削弱。

对于其他规划迁移或处于正在迁移过程中的组织,LinkedIn 提供以下指导原则:

  • 尽早计划,并请组织的 Python 专家参与进来。在受影响的团队中寻找和利用冠军,宣传 Python 3 的优势。
  • 采用双语方法来支持库,这样你的库的用户就可以按照自己的计划移植到 Python 3。
  • 投资于测试和代码覆盖率:这些将是你最好的成功指标。
  • 确保你的数据模型是明确而清晰的,特别是在识别哪些数据是字节,哪些是人类可读的文本时。

现在,LinkedIn 工程已经完全采用了 Python 3,不再需要担心是否支持 Python 2,而且 LinkedIn 的支持负载已经降低了。LinkedIn 现在可以依靠最新的开源库和工具,将自己从不得不编写双语 Python 的束缚中解放出来。LinkedIn 正在适时地、积极地采用类型提示和 mypy 类型检查器,以提高 Python 代码库的整体质量、技术和可读性。LinkedIn 目前支持 Python 3.6 和 3.7,并计划在 2020 年初支持 Python 3.8。

原文链接:

https://engineering.linkedin.com/blog/2020/how-we-retired-python-2-and-improved-developer-happiness

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/5IbzfQkZME6SbuKigHkM
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券