识别合适的时机
对于正处于扩张阶段的电子商务企业而言，确保应用程序更新至最新版本至关重要。
本文将分享在不感到沮丧的情况下升级框架的最佳实践。本案例研究基于 Spree Commerce 平台，但无论使用何种平台，大多数问题和挑战都是相似的。应用程序通常被构建为概念验证（PoC）和/或最小可行产品（MVP），并往往经过多年的演变，成为为其所属组织提供重大经济价值的一个或多个大型系统的重要组成部分。
不幸的是，支持应用程序增长所需的功能开发工作量往往很大，几乎没有或根本没有空间进行认真的维护工作。由于开发资源匮乏，对应用程序使用的主要框架进行的升级可能会被推迟。
在达到相对稳定的阶段后，升级问题往往会再次出现。但随着特定框架版本的长期支持（LTS）期接近尾声，进一步的安全补丁变得难以实施。同时，开发团队失去了使用该框架的新功能或添加现代库的能力，这严重且负面地影响了开发团队的整体生产力。
虽然升级成为一个紧迫的关注点，但通常仍有一些持续的开发工作无法暂停。为了应对这些挑战，我们的升级团队确定了一套使这些流程顺畅运行的实践方法。这些实践允许以尽量减少对功能团队影响的方式执行必要的升级。随着您通读整篇文章，您将深入了解我们使用的具体策略以及我们所解决的问题。
确定升级的里程碑
虽然将相关框架升级到最新、最先进版本的诱人目标可能很吸引人，但采取循序渐进的方法更为务实。如果当前框架库的版本已过时，这一点尤其正确。
我们发现，最好的方法是为一组升级定义一系列里程碑，其中每个里程碑尽可能依赖较少的依赖项升级。这大大降低了生产部署的风险以及开发人员陷入“依赖地狱”的可能性。
例如，在升级 Spree 框架时，您可能同时正在升级其底层 Ruby on Rails 版本和 Bootstrap（某些版本的 Spree 自带 Bootstrap）。一次性处理所有这些升级可能会是一场噩梦。因此，如果可能，理想的升级场景应首先将 Spree 升级到带有更新版 Rails 的版本并部署它，然后执行另一个需要升级 Bootstrap 的升级。
示例表：
从 Spree 3.0 迁移到 4.4
回归测试计划
虽然框架升级通常不会带来新功能，但期望的结果是应用程序的外部行为保持不变。这正是质量保证（QA）在这些项目中如此重要的原因——QA 人员对于支持团队其他成员并确保在升级过程中不引入重大问题是至关重要的。
他们的工作通常从创建详细的回归检查清单开始，以便在升级的每个阶段之后执行。同样重要的是，QA 专业人员应记录系统中现有的缺陷，以便明确当前问题的表现。一旦应用程序在升级后的框架下看起来稳定，QA 人员将对整个应用程序（包括其所有集成）执行详细的回归测试。通过这种方式，QA 可以有效验证自动化测试未覆盖或无法覆盖的细节。
即使是对软件引入的最微小变化，也需要在整个应用程序的上下文中进行验证，因此，在执行升级和迁移时，至关重要的是确保应用程序保持其完整性，并且每个功能都能按预期工作。 – Wojtek Wiśniewski – Upside的质量保证负责人
重要的是，QA 需要了解每次升级的内部细节——这使他们能够将注意力集中在可能因底层变更而出问题的区域，从而设计更全面的测试用例。
管理持续工作：Shopify 的双启动方法
将升级与持续的功能开发协调起来可能是一个重大挑战。公司中常见的做法是在代码库的一个独立且长期存在的分支上进行升级，定期将主分支合并到该分支，并在过程中解决任何潜在问题。
随后，通常会有一段较长的代码冻结期，在此期间功能开发暂停，团队所有人准备发布升级后的版本。这一暂停和准备阶段需要提前规划，并与业务团队保持清晰沟通，以便他们对其他功能的发布时间表设定合理的预期。
以行业案例为例，GitHub 花了几年时间进行单一的 Rails 升级，原因是 Rails 3 中的新语法与基于 Rails 2 的 GitHub 持续功能开发之间存在多次冲突。
但有一种方法可以实现更好的时间表和更顺畅的开发工作流程。这种方法基于“双启动”（dual booting）概念，该概念由 Shopify 和 GitHub 掌握，并基于他们在大型 Rails 应用程序升级过程中吸取的深刻教训。
长期存在的分支
双启动
双启动详解
双启动方法基于拥有一个包含两种配置（旧依赖项和新依赖项）的单一代码库，可以通过例如设置环境变量来切换这两种配置。
代码库中因底层框架版本不同而需要有所差异的部分（例如 Active Record 的不同语法）可以通过功能标志进行隐藏。这有助于避免难以维护的长期分支。此外，CI 环境可以同时运行两个版本的代码测试——这不仅使我们能够观察升级状态，还能防止正在开发新功能的开发人员引入与新框架版本不兼容的代码（因为他们从一开始就必须同时保持与两个版本的兼容性）。
现在，计划已基本完成并进行了基础设置，让我们更深入地探讨为了成功执行升级所需采取的具体步骤。
首先确保应用能启动，然后让测试通过
配置双启动后，下一步是让应用程序在新配置下能够启动——无论其是否按预期正常工作。能够启动 Rails 环境有助于设置进一步的自动化流程（例如负责运行测试的 CI）。它还构建了一个测试环境骨架，使团队能够在新代码库上验证他们的修复方案。
在此阶段，根据你们的测试覆盖率，审查在升级后的版本上运行的自动化测试结果可能是一个好主意。这些结果将为升级核心框架后在整个应用中出现的明显问题提供良好的指导。大多数这些问题都易于修复；如果你们能让所有测试都通过，这对最终进行功能开发的团队来说同样重要。
在 CI 中配置双启动，以强制确保新功能与升级后的代码库兼容
当升级后代码库上的测试套件开始通过后，我们就达到了一个可以开始强制要求新功能与升级后代码库兼容的阶段。
强制开发人员在每次部署前使用新版本启动应用程序并执行两组回归测试成本高昂。但我们可以利用一些容易实现的措施，在流水线中添加一个额外步骤。目标是基于旧配置和新配置运行自动化测试套件。假设新功能至少会有单元测试覆盖，这些测试将作为断言，证明新功能也能在新配置下正确执行。即使无需经历双启动的麻烦，开发人员也有机会进行确认，并在必要时调整其功能以适应框架的新版本。
当然，这一切都需要付出一定的代价——你的构建时间可能会翻倍。然而，这通常仍然比让开发人员花费数周时间解决代码库分叉后出现的棘手冲突要高效得多。
处理数据库迁移
数据库迁移可能是系统升级中最困难的部分，尤其是在处理大规模系统时。虽然你在升级基本框架（如 Ruby on Rails）时不会遇到迁移问题，但在升级包含业务逻辑的框架（如 Spree）时，你会遇到大量问题。
审查和评估迁移是开发团队的关键步骤。必须认识到迁移可能会运行很长时间——事实上，它们可能需要在“切换开关”到升级版本之前很久就运行。这意味着与其他行动的规划和协调至关重要。迁移问题通常特定于某个应用程序，因为运行时间往往取决于某些表的使用情况或已创建的索引。
在审查数据库迁移时，不要忘记那些可能直接访问数据库的外部依赖项——尤其是商业智能（BI）工具。很多时候，BI 团队拥有自己的报告集，这些报告不在应用程序代码中，但在执行迁移后仍需更新。
管理部署
尽管让新版本的依赖项正常运行非常重要，但在对新配置执行回归测试时，QA 人员经常会遇到 bug 或不一致之处。拥有一个参考环境非常有用。
参考环境允许快速验证某个特定 bug 是新引入的，还是已经存在于旧版本中，只是在准备回归测试时未显现出来。
这正是双启动发挥作用的地方——它使得设置具有不同依赖项版本的多阶段环境变得容易。在升级过程中，最佳实践是拥有两个阶段环境：
拥有一个将最新代码库版本部署到这些环境的简单流程，可以大大改善工作流程并提高开发速度。如果你使用 CI 和基于 Docker 的部署，它还可以显著减少持续工作中的麻烦。
拥有一个轻松复制阶段数据的过程也非常好。在最理想的情况下，这些数据应该是匿名化的生产数据，这使得能够在尽可能接近真实生产环境的状态下测试升级。
识别底层框架中的破坏性更改并使新代码适应这些更改
在代码方面，即使你修复了明显的问题，仍可能会遇到底层框架逻辑的一些变化。这些变化可能包括从 Rails 2 到 3 的 ActiveRecord 查询接口的变化，或者更复杂的业务逻辑变化，特别是如果你的应用程序基于更复杂的框架（如 Spree Commerce）。
有时，核心框架的升级也可能需要对项目中使用的其他库进行更改。Spree 升级通常要求升级 Paperclip 等工具。这也需要纳入计划。
而在其他情况下，用于项目的库可能与所需框架的新版本不兼容。在这种情况下，您可能需要寻找替代库，或者对库进行分叉并升级其内部结构。
框架的发布说明是帮助定位可能需要更多关注的潜在问题点的绝佳资源。提前规划如何处理这些问题非常重要。在执行升级之前，为每个此类领域制定具体计划。有时痛点可能需要技术上的变通方案，而另一些则可能影响某种业务逻辑的变更。
在执行升级时，双启动（dual booting）和功能标志（feature flagging）将使管理应用程序代码中的依赖关系和分歧变得容易。
部署计划
框架升级的部署通常比部署大多数功能的风险更大。
让我们面对现实：框架升级的部署通常比部署大多数功能的风险更大。它涉及底层技术的变更，这些变更可能会对整个应用程序产生影响，并且难以隔离。框架部署还会导致业务逻辑的变化，在某些情况下甚至会影响底层数据库。
虽然回归测试可以极大地增强您对升级的信心，但仔细规划以避免对业务运营造成重大中断仍然很重要。您可以采取几项措施来避免此类重大中断：
- 审查日历：避免在业务繁忙时期进行部署，例如在处理电子商务应用程序时，避开黑色星期五前后的高峰期。
- 规划开发团队的可用性：选择一个开发团队能够快速响应任何问题的时间点。假日季节并不是部署的最佳时机，周五也不是（除非团队计划在周末监控部署状态）。
- 审查迁移所需的时间投入：如果升级包含数据库迁移，请确保对其进行分类——运行时间较长的迁移需要在升级之前先行执行。
通过双启动，部署本身就像更改环境变量并重启应用程序一样简单，或者更新 Kubernetes 配置以使用另一个 Docker 镜像。部署完成后，再次让质量保证团队在生产环境中执行基本的回归测试以验证一切是否按预期工作是件好事。
当升级在生产环境中完成并验证后，清理功能标志非常重要。否则，它们会给未来的升级带来不必要的混乱和复杂性。
在完成整体升级的最后一步里程碑后，您可能也想移除双启动设置。只需记住要使其易于再次启用，因为它在未来可能仍然有用。
总结
升级框架是一个困难且复杂的过程。然而，制定一个包含多个里程碑、涵盖每次升级细节并确保数据得到妥善处理的扎实计划，将使升级过程更加顺畅。使用利用双启动的现代技术还可以减少升级团队与功能团队之间协调工作所需的工作量，同时降低代码合并错误的风险。质量保证在这一过程中也将发挥重要作用——他们将梳理当前系统的状态，并让你对升级后版本的质量充满信心。
Rafal Cymerys
Upside的首席技术官
拥有超过10年管理技术项目经验的技术领导者——从大型企业到有前景且正在扩展的初创公司，Rafal于2017年创立了Upside，负责监督主要项目。