从Drupal 6升级到Drupal 7:最好的程序员的做法？

Question

虽然自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. ...

这些问题并不是一个详尽的列表,但我希望他们能够了解我正在寻找什么样的信息.我宁愿说:无论你认为什么是相关的,我没有在上面列出获得"加"!:)

如果我没有表现得足够清楚,请发表您认为我应该在问题中添加的信息的评论.提前谢谢您的时间!

PS:是的我知道...... D7还没有出来,重要的贡献模块升级需要几个月......但是开始思考永远不会太早!:)

Answer 1

好问题,让我们看看:

1. (何时开始移植)
   这当然取决于模块到端口的复杂性.如果确实存在复杂/大的问题,那么尽早开始以便在不受压力的情况下找到棘手的点可能是有用的.对于较小/标准的,我会尝试在以后找到一个更大的时间段,我可以连续移植它们中的许多,以便快速记住常规内容(并从可能改进的文档中获益).

2. (测试覆盖率)
   通常我会说在开始重构/移植之前有一个好的测试覆盖率肯定是可取的.但是考虑到Drupal-7通过将测试框架移动到核心引入了一个关于测试框架的重大变化,我认为无论如何都需要重写大量的测试.因此,如果在迁移后不需要维护Drupal-6版本,我将节省时间/麻烦,并在移植后增加覆盖范围.

3. (早期采用者与观望者相比)
   自4.7版以来使用Drupal,我们总是在考虑移植之前至少等待新主要版本的第一次正式发布.使用Drupal 6,我们在移植我们的第一个站点之前等待了视图模块,我们仍然在Drupal-5上有一些较小的项目,因为它们工作正常并且很难证明为我们的客户支付额外费用是合理的.它仍然有维护/安全修复程序.一天中有这么多时间,并且总是有积压的错误需要修复,要添加的功能等,所以没有使用未完成的技术,而有更多迫在眉睫的事情可以立即使我们的客户受益.现在,如果我们必须维护一个或多个"官方"贡献的模块,这肯定会有所不同,因为提供早期端口将是一件好事.
   我在这里有点束缚 - 作为一个早期采用者肯定会对社区有所帮助,因为有人必须在修复之前发现这些错误,但另一方面,使用bug一小时一小时地进行战斗几乎没有什么商业意义如果你等待的时间更长,其他人可能已找到/修复了.只要我必须以此为生,我需要观察我的资源,努力在服务社区和从中受益之间取得可接受的平衡: - /

4. (质量标准)
   "如果它有效,我很高兴"只是没有削减它,因为我不想只是暂时的幸福,但明天也是如此.因此,我的一个质量标准是,我需要(有点)确定我已经"充分理解"新概念,以便不仅让事情有效,而且让它们按照应有的方式工作.现在很难更准确地定义,因为显然不可能知道在"得到它"之前是否"得到它",所以它归结为一种直觉或区分'是的,它有点作用'对'是' ,这看起来是正确的',并且必须接受他将会经常出错.
   也就是说,我正在寻找的一个特定点是"尽早干预".作为一个初学者,我经常在主题阶段之后调整"事后"的东西,而通过一个钩子或另一个钩子在处理链中更早地应用"修复"会更容易.所以现在,每当我要在主题图层中"调整"某些东西时,我都会故意花一点时间检查一下之前是否在钩子内更加干净/兼容.因为我希望Drupal-7能够添加更多的挂钩选项,这是我需要特别注意的事情,因为它通常会在添加新模块时减少冲突和突然"破坏东西".

5. (常见的陷阱)
   嗯 - 主要是移植到早期,之后发现一个或多个所需的模块根本不可用于新版本,或者仅在dev/alpha /早期beta状态.因此,我要确保首先编译已用/需要模块的完整列表,列出其移植状态,以及快速检查其问题队列.
   除此之外,到目前为止,我一直对新版本及其改进感到非常满意,并且我再次期待Drupal-7.

6. (移植时重构)
   可以说移植本身就是一个相当大的重构,所以没有必要通过重组非移植相关的东西来增加复杂性.另一方面,如果你已经不得不将模块碎成碎片,为什么不利用这个机会进行重大改造呢？我试图根据复杂性绘制一条线 - 对于大/复杂的模块,我会尽可能地直接进行端口,如果需要的话,稍后重构一下.对于较小的模块,它应该不重要,因为引入细微错误的可能性应该相当小.

7. (其他的东西)
   ......需要考虑一下......

好的,其他的东西:

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

• 最新版本首先 - 这一点在升级指南中相当明显并且总是受到重视,但值得一提的是:在进行重大升级之前,首先将核心和所有模块升级到最新版本,因为升级代码很可能取决于最新的表/数据结构才能正常工作.鉴于Drupals'零碎',一次一步更新策略,实现升级代码将很难检测到不同的升级前状态并采取相应措施.