drupal - 从Drupal 6升级到Drupal 7:最佳程序员实践？

Question

尽管自D4系列以来我就一直在使用drupal，但我只是开始用D6进行专业开发，因此-尽管我进行了许多站点升级-从来没有面临将自己的代码移植到新版本的任务。

我知道Drupal社区将提供有关已更改的API和体系结构更改的大量技术支持（请参阅D5-D6的deadwood module甚至是D6-D7方法的for modules and themes的这些存根）。

但是，我所寻求的问题更多是出于战略思考的角度，换句话说，我正在寻求有关如何计划/实施/审查移植我自己的代码的过程的意见和建议。同事开发人员从以前的经验中学到了什么。一些例子：


您是否建议我在有时间的时候就开始移植我的模块，并在一段时间内保持并发D7（这样我就为D日做好了准备），还是建议您等待实际即将到来的端口的那一天，然后将模块升级到D7并删除D6版本？
我只有一些模块具有完整的测试范围。您是否建议完成D6版本的测试范围，以便所有测试都能正常工作以检查D7端口，还是建议在移植时编写我的测试指南以测试D7版本？
您是否发现早采用者在新功能和更好的API方面给您带来优势，还是您发现延迟转换以便利用大量现成的contrib模块更方便？
您是否为自己设置了质量标准/评估标准，还是只是将标准设置为“如果可行，我很高兴”？为什么？如果您设定了某些标准或目标，那么它们在哪里/将是什么？他们如何帮助您？
您过去是否遇到过常见的陷阱，并且认为适用于D6-D7移植过程？
是移植一个好时机进行一些重构，还是只是使所有事情变得更加复杂以重新组合在一起？
...


这些问题并不是详尽无遗的清单，但我希望它们能使我对我正在寻找的信息类型有所了解。我宁愿说：任何您认为相关且我上面未列出的内容都将获得“加分”！ :)

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

PS：是的，我知道... D7还没有发布，重要的contrib模块要升级还需要几个月的时间...但是开始思考永远不会太早！ :)

Answer 1

好问题，让我们看看：


（开始移植时）
这当然取决于要移植的模块的复杂性。如果确实存在复杂/大型的漏洞，那么尽早开始以找到棘手的漏洞而不受到压力可能会很有用。对于较小的/标准的，我会在以后尝试找到更大的时隙，以便在其中连续移植很多时隙，以便快速记住常规内容（并从可能改进的文档中受益）。
（测试覆盖率）
通常，我会说在开始重构/移植之前进行良好的测试覆盖肯定是明智的。但是鉴于Drupal-7通过将其移至核心而对测试框架进行了重大更改，所以我希望无论如何都需要重写大量的测试。因此，如果在迁移后无需维护Drupal-6版本，我将节省时间/麻烦，并希望在移植后增加覆盖范围。
（早期采用者与观望者）
从4.7版本开始使用Drupal，我们一直在等待至少一个新的主要版本的正式发布，甚至没有考虑移植。使用Drupal 6，我们在移植第一个站点之前等待了views模块，而我们在Drupal-5上仍然有一些较小的项目，因为它们工作得很好，并且只要有足够的成本为我们的客户辩解就很难了。仍然有维护/安全修复程序。一天中有那么多时间，并且总是存在待解决的错误，要添加的功能等积压的问题，因此，在未完成的技术中玩耍毫无用处，而还有更多迫在眉睫的事情可以立即使我们的客户受益。现在，如果我们必须维护一个或多个“官方”贡献模块，肯定会有所不同，因为提供早期移植将是一件好事。
我在这里有点束手无策-早期采用者肯定会给社区带来好处，因为有人必须先发现错误才能将其修复，但另一方面，与时俱进地应对错误几乎没有商业意义。如果您再等一会，其他人可能已经找到/解决了。只要我必须以此为生，我就需要观察我的资源，努力在为社区服务和从中受益之间取得可接受的平衡：-/
（质量标准）
“如果成功，我会很高兴”只是没有切入，因为我不想只是暂时而幸福，但明天也不会幸福。因此，我的质量标准之一是，我需要（某种程度上）确定自己对新概念的理解程度足够好，以便不仅使事情正常进行，而且使它们按应有的方式工作。现在很难对此进行更精确的定义，因为显然不可能在“得到它”之前知道是否“了解了它”，因此归结为直觉到“是的，有点儿起作用”与“是”的区别。 ，这看起来不错”，并且必须接受这一点，他经常会犯错。
也就是说，我要注意的一个特定问题是“尽早干预”。作为一个初学者，我经常在主题化阶段“事后”进行调整，而通过一个钩子或另一个钩子在处理链中更早地应用“修复”会容易得多。因此，现在，每当我要“调整”主题层中的某些内容时，我都会花一点时间检查一下是否可以在钩子中更干净/更兼容地进行。正如我期望Drupal-7会添加更多的挂钩选项一样，我会特别注意这一点，因为它通常会减少添加新模块时的冲突和突然的“东西破坏”。
（常见的陷阱）
好吧-主要是移植到早期，然后在之后/之间发现一个或多个所需模块根本无法用于新版本，或者仅在dev / alpha /早期beta状态下可用。因此，我将确保首先编译已使用/需要的模块的完整列表，列出它们的移植状态，并快速检查它们的发布队列。
除此之外，到目前为止，我一直对新版本及其改进感到非常满意，并且我非常期待Drupal-7。
（移植时重构）
可以说移植本身就是一个相当大的重构，因此不需要通过重组与移植无关的东西来增加复杂性。另一方面，如果您已经必须将模块切成碎片，为什么不利用这次机会对其进行大修呢？我会尝试根据复杂度划分一条线-对于大型/复杂模块，我会尽可能直接进行移植，并在以后根据需要进行更多重构。对于较小的模块，它实际上并不重要，因为引入细微错误的可能性应该很小。
（其他的东西）
...需要考虑一下...




好的，其他的东西：


资源需求-考虑到某些Drupal-7线程，看来它们可能会增加，因此应在移植位于共享/受限托管帐户上的较小站点之前进行评估。
首先是最新版本-此版本相当明显，并且始终在升级指南中强调，但仍然值得一提：在进行重大升级之前，首先将核心和所有模块升级到最新的最新版本，因为升级代码很可能取决于升级版本。最新的表格/数据结构才能正常工作。鉴于Drupals是“零敲碎打”的，每次更新策略仅一步之遥，因此很难实施能够检测到不同的升级前状态并采取相应措施的升级代码。