从 Drupal 6 升级到 Drupal 7：最佳程序员实践？

StackOverflow https://stackoverflow.com/questions/1750972

题

虽然我从 D4 系列开始就使用 drupal，但我只是从 D6 开始对其进行专业开发，因此 - 尽管我进行了各种站点升级 - 我从未面临过以下任务： 必须移植我自己的代码 到新版本。

我知道 Drupal 社区将提供大量关于 API 变更和架构变更的技术支持（请参阅 枯木模块 对于 D5-D6 甚至 D6-D7 操作方法的这些存根 用于模块 和主题).

然而，我的问题所寻找的更多的是 战略思维, ，或者换句话说， 我正在寻找有关如何计划/实施/审查移植我自己的代码的过程的意见和建议, ，根据开发人员同事从以前的经验中学到的知识。一些例子：

  1. 您是否建议我一有时间就开始移植我的模块，并维持并发 D7 一段时间（这样我就为 D 日“做好准备”），或者您是否建议宁愿等待港口实际到达的日期 迫在眉睫的 然后将模块升级到 D7 并放弃 D6 版本？
  2. 只有我的一些模块具有完整的测试覆盖率。您是否会建议完成 D6 版本的测试覆盖范围，以便让所有测试都能检查 D7 端口，或者您会建议在移植时编写我的测试指导，以测试 D7 版本吗？
  3. 您是否发现成为早期采用者可以让您在新功能和更好的 API 方面获得优势，或者您是否发现延迟转换以便利用大量现成的 contrib 模块更方便？
  4. 您是否为自己设定了质量标准/评估标准，或者您只是将标准设置为“如果有效，我很高兴”？为什么？如果您设定了某些标准或目标，它们在哪里/将是什么？他们如何帮助你？
  5. 您过去遇到过并且您认为适用于 D6-D7 移植过程的常见陷阱吗？
  6. 移植是进行一些重构的好时机还是只会让一切变得更加复杂而无法重新组合在一起？
  7. ...

这些问题并不是详尽的列表，但我希望它们能让我了解我正在寻找什么样的信息。我宁愿说：无论您认为相关且我上面未列出的内容都会获得“加号”！:)

如果我没有能够足够清楚地表达自己的意思，请发表评论，其中包含您认为我应该在问题中添加的信息。预先感谢您的宝贵时间！

附：是的，我知道...D7 尚未发布，重要的贡献模块需要几个月的时间才能升级......但开始思考永远不会太早！:)

有帮助吗？

解决方案

好问题，让我们看看：

  1. （什么时候开始移植）
    这当然取决于要移植的模块的复杂性。如果确实有复杂/大的问题，那么尽早开始可能会很有用，以便在没有压力的情况下找到棘手的地方。对于较小/标准的，我会尝试稍后找到一个更大的时间段，在那里我可以连续移植其中的许多内容，以便快速记住常规内容（并从可能改进的文档中受益）。

  2. （测试覆盖率）
    通常我会说，在开始重构/移植之前拥有良好的测试覆盖率肯定是可取的。但鉴于 Drupal-7 通过将测试框架移至核心而引入了有关测试框架的重大更改，我预计无论如何都需要重写大量测试。因此，如果迁移后不需要维护 Drupal-6 版本，我会节省时间/麻烦，并致力于在移植后增加覆盖范围。

  3. （早期采用者与早期采用者等着瞧）
    从 4.7 版本开始使用 Drupal，我们总是至少等待新主要版本的第一个正式发布，然后才考虑移植。对于 Drupal 6，我们在移植我们的第一个站点之前等待了视图模块，并且我们在 Drupal-5 上仍然有一些较小的项目，因为它们运行得很好，只要仍有维护/安全修复。一天的时间太多了，总是有积压的错误需要修复、需要添加的功能等等，因此，在有更多迫在眉睫的事情要做、可以立即使我们的客户受益的情况下，玩未完成的技术是没有用的。现在，如果我们必须维护一个或多个“官方”贡献的模块，情况肯定会有所不同，因为提供早期移植将是一件好事。
    我在这里有点进退两难——成为早期采用者肯定对社区有利，因为有人必须先发现错误才能修复，但另一方面，与错误作斗争一小时又一小时没有什么商业意义如果您再等一会儿，其他人可能已经找到/修复了。只要我必须以此为生，我就需要注意我的资源，努力在服务社区和从中受益之间取得可接受的平衡:-/

  4. （质量标准）
    “如果有效，我就高兴”并不能解决这个问题，因为我不想只高兴一时，但明天也一样。因此，我的质量标准之一是，我需要（在某种程度上）确定我足够好地“理解”新概念，以便不仅使事情发挥作用，而且使它们按照应有的方式发挥作用。现在很难更准确地定义这一点，因为在“得到它”之前显然不可能知道一个人是否“得到它”，所以它归结为“是的，它有点管用”与“是的，它有点管用”的直觉/区别。“是的，看起来是对的”，人们必须承认他在这一点上经常会犯错。
    也就是说，我特别关注的一点是“尽早干预”。作为一名初学者，我经常在主题阶段“事后”调整内容，而通过一个或另一个钩子在处理链的早期应用“修复”会容易得多。所以现在，每当我要“调整”主题层中的某些内容时，我都会故意花一点时间来检查是否可以在之前的挂钩中更干净/兼容地完成此操作。正如我期望 Drupal-7 添加更多挂钩选项，这是我会特别注意的事情，因为它通常会减少添加新模块时的冲突和突然的“破坏”。

  5. （常见陷阱）
    嗯 - 主要是移植到早期，之后/中间发现一个或多个所需的模块根本不适用于新版本，或者仅处于开发/阿尔法/早期测试状态。所以我要确保编译一个 完全的 首先列出已使用/需要的模块，列出它们的移植状态，以及对其问题队列的快速检查。
    除此之外，到目前为止我一直都是 非常 对新版本及其改进感到满意，我再次期待 Drupal-7。

  6. （移植时重构）
    可以说，移植本身就是一种相当大的重构，因此无需通过重构与移植无关的内容来增加复杂性。另一方面，如果您已经必须将模块撕成碎片，为什么不利用这个机会对其进行重大检修呢？我会尝试根据复杂性画一条线 - 对于大型/复杂模块，我会尽可能直接地进行端口，并在需要时进行更多重构。对于较小的模块，这并不重要，因为引入细微错误的可能性应该相当小。

  7. （其他的东西）
    ...需要考虑一下...

好吧，其他的东西：

  • 资源需求 - 考虑到一些 Drupal-7 线程，看起来它们可能会上升，因此在移植位于共享/受限托管帐户上的较小站点之前应该对此进行评估。

  • 首先是最新版本 - 这是相当明显的，并且在升级指南中总是强调，但仍然值得一提：在进行重大升级之前，请先将核心和所有模块升级到最新的当前版本，因为升级代码很可能依赖于最新的表/数据结构才能正常工作。考虑到 Drupals 的“零碎”、一次一步的更新策略，很难实现能够检测不同升级前状态并采取相应行动的升级代码。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top