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

Question

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

drupaldrupal-6upgradeportingdrupal-7

18

虽然我自D4系列以来一直在使用Drupal，但是我只从D6开始专业开发它，因此-尽管我进行了各种网站升级-我从未面对过将自己的代码移植到新版本的任务。

我知道Drupal社区会提供有关API更改和架构更改的大量技术支持（请参见deadwood模块，适用于D5-D6，甚至这些D6-D7 how-to的存根 用于模块 和主题）。

然而，我的问题更多地涉及策略思考，换句话说，我正在寻求关于如何计划/实施/审查移植自己的代码的过程的输入和建议，考虑到同事开发人员通过以前的经验学到了什么。以下是一些示例：

你建议我在有时间的时候开始移植我的模块，并保留一个并发的D7版本一段时间（这样我就为“D-day”做好了准备），还是建议等到移植实际上已经迫在眉睫时再升级模块到D7并放弃D6版本？
只有我的一些模块具有完整的测试覆盖率。你建议我完成D6版本的测试覆盖率，以便所有测试都能正常工作来检查D7移植，还是建议我在移植时编写测试来测试D7版本？
你是否认为成为早期采用者可以在新功能和更好的API方面给你带来优势，还是你是否认为推迟转换更加方便，以利用更多现成的贡献模块？
你是否为自己设定了质量标准/评估标准，还是只是将标准设定为“如果它能工作，我就满意”？为什么？如果你设定了某些标准或目标，它们是什么？它们如何帮助你？
你过去经历过哪些常见的陷阱，你认为这些陷阱适用于D6-D7移植过程？
移植是进行一些重构的好时机，还是会使一切变得更加复杂难以重新组合？
...

这些问题并不是一个详尽的列表，但我希望它们能给您提供我正在寻找的信息类型的想法。我宁愿说：无论您认为什么是相关的，并且我没有列在上面的都会得到“加分”！ :)

如果我没有表达清楚，请在评论中提供您认为应该添加到问题中的信息。感谢您提前花费时间！

PS：是的，我知道... D7还没有发布，重要的贡献模块将需要几个月才能升级...但现在开始思考永远不为时过早！:)

- mac

1

我喜欢这个问题，因为这是我自己将要面对的。但是，我不会太急于更新。Drupal 7仍在开发中，并且可能需要很长时间才能将你或我使用的许多模块移植到Drupal 7上。此外，可能会有新的（对我们目前未知的）功能或模块，我们可以利用它们并实际减少我们的自定义代码。我的个人计划是在发布D7的测试版本后安装一个测试版本，但在Drupal的整体情况稳定之前等待再将现有网站移植过来。 - Greg

嗯 - 我到目前为止还没有做过这个，但考虑到这些是多个开放性问题，没有可能的“正确”答案，我需要这样做：应该是社区维基！（我说了，现在快投票支持我，否则那一部分就会被翻转;) - Henrik Opel

1

我在社区维基上多读了一些内容，因此我理解了它背后的逻辑和推理，并将这个问题转化为维基。 - mac

请参见https://dev59.com/5HE95IYBdhLWcg3wV8a_。 - apaderno

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Henrik Opel · Accepted Answer

好问题，那么让我们来看看：

（何时开始移植）
这肯定取决于要移植的模块的复杂性。如果有非常复杂/大型的模块，最好早点开始，以便在没有压力的情况下找到棘手的地方。对于较小/标准的模块，我会尝试在以后找到一个更大的时间段，在那里我可以连续移植许多模块，以便快速记忆常规内容（并从可能改进的文档中受益）。
（测试覆盖率）
通常我会说，在重新构建/移植之前拥有良好的测试覆盖率肯定是明智的。但由于Drupal-7将测试框架移至核心，这是一项重大变革，我预计需要重写大量测试。因此，如果在迁移后不需要维护Drupal-6版本，则应节省时间/麻烦，并在移植后提高覆盖范围。
（早期采用者与等待观望）
自4.7版本以来使用Drupal，我们总是等待新主要版本的第一个官方发布，然后才考虑移植。对于Drupal 6，我们在移植我们的第一个网站之前等待了views模块，我们仍然有一些较小的项目在Drupal-5上运行良好，由于仍然有维护/安全修复，很难为客户证明额外的账单。一天只有那么多时间，总是有一堆需要修复的错误，添加的功能等等，因此，在有更紧迫的事情要做可以立即让我们的客户受益之前，没有必要玩未完成的技术。现在，如果我们必须维护一个或多个“官方”的贡献模块，则提供早期移植将是一件好事。

我有点为难 - 作为早期采用者确实对社区有益，因为必须在修复之前找到错误，但另一方面，如果您稍微等待一下，就可以避免与他人可能已经找到/修复的错误进行长时间的战斗。只要我需要靠这个谋生，我就需要控制好自己的资源，试图在服务社区和从中获益之间取得可接受的平衡 :-/

（质量标准）
仅仅"能正常工作"并不够，因为我不想仅仅暂时感到满意，而是希望明天也能如此。因此我的一个质量标准是，我需要相当确定自己已经很好地理解了新概念，以便不仅使事情正常工作，而是让它们像应该的那样工作。现在更加具体地定义这一点很难，因为显然在真正掌握之前就不知道是否真正掌握了，因此它归结为一种直觉感觉/区别：'是的，它有点工作' vs. '是的，看起来没问题'，人们必须接受自己通常会在这方面犯错。

话虽如此，我特别关注的一个点是'尽早干预'。作为初学者，在主题阶段之后我经常调整东西，而这些更改在处理链的早期通过某个挂钩进行修复会更容易。因此，现在每当我要在主题层次上“调整”某些内容时，我会有意地停下来一小段时间，检查是否可以在较早的挂钩中更清晰/兼容地完成此操作。由于我希望Drupal-7增加更多的挂钩选项，所以这是我将特别注意的事情，因为它通常减少了添加新模块时的冲突和突然的“破坏性问题”。

（常见陷阱）
主要是将早期版本移植过来，在此过程中发现一个或多个所需模块在新版本中完全不可用，或者只处于dev/alpha/early beta状态。因此，我会确保首先编译一个使用/所需模块的完整列表，列出它们的移植状态，并快速检查它们的问题队列。
除此之外，我一直对新版本及其改进非常满意，并且我期待Drupal-7再次出现。

(移植重构)
可以说移植本身就是一种相当大的重构，因此没有必要为非移植相关的内容增加复杂性。另一方面，如果您已经不得不将模块分解成碎片，为什么不利用这个机会进行一次重大革新呢？我会根据复杂性制定一条线路 - 对于大/复杂的模块，我会尽可能地进行移植，如果需要的话稍后进行重构。对于较小的模块，实际上并不重要，因为引入微妙错误的可能性应该相当小。

(其他事项)
...需要考虑一下...

好的，其他事项：

资源需求 - 鉴于一些Drupal-7线程，看起来它们可能会增加，因此应在移植到共享/受限制的托管帐户上的较小站点之前进行评估。
首先是最新版本 - 这个显而易见并且在升级指南中始终强调，但仍值得一提：在进行重大升级之前，将核心和所有模块升级到它们的最新当前版本，因为升级代码极有可能依赖于最新的表/数据结构才能正常工作。鉴于Drupal的“逐步”，一次性更新策略，很难实现升级代码检测不同的预升级状态并相应地采取行动。