从Drupal 6升级到Drupal 7:最佳程序员的实践?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (1)
  • 关注 (0)
  • 查看 (14)

尽管我从D4系列开始就使用Drupal,但我只用D6开始专业开发,所以 - 尽管我做了各种网站升级 - 但我从来没有面临将自己的代码移植到新版本的任务。

我知道Drupal社区会提出很多关于更改API和架构变更的技术支持

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

  1. 你会建议在我有时间做这件事的时候立即开始移植我的模块,并且在一段时间内保持并发D7(所以我为D-day“准备好”)或者你会建议宁可等待那么港口实际上即将到来的一天,然后将模块升级到D7并删除D6版本?
  2. 只有我的一些模块具有全面的测试覆盖率。您会建议您完成D6版本的测试范围,以便让所有测试能够检查D7端口,或者您会建议编写我的测试指导移植时间来测试D7版本吗?
  3. 您是否发现成为早期采用者可以为您提供新功能和更好的API方面的优势,或者您是否发现延迟转换以便利用大量现成的contrib模块更方便?
  4. 你是否为自己设定了质量标准/评估标准,或者你是否设置了“如果它有效,我很高兴”?为什么?如果你设定了某些标准或目标,他们在哪里/他们会是什么?他们是如何帮助你的?
  5. 您是否曾经遇到过常见的缺陷,并且您认为这些缺陷适用于D6-D7移植过程?
  6. 正在移植一个好时机来做一些重构,或者它将会使一切变得更加复杂以便重新整合在一起?

这些问题并不是一个详尽的列表,但我希望他们能够提供我正在寻找的信息。我宁愿说:无论你认为相关,我没有列出上面得到一个“加号”!

如果我没有足够清楚地表达自己,请发表评论,并附上您认为应该在问题中添加的信息。预先感谢您的时间!

提问于
用户回答回答于

好问题,让我们看看:

  1. (何时开始移植) 这当然取决于要移植的模块的复杂性。如果真的有复杂/大型的,为了在不受压力的情况下找到棘手的点,可能会很有用。对于较小的/标准的,我会尽量在后面找到一个更大的时间段,在那里我可以连续移植其中的很多时间段,以便快速记住常规内容(并从可能改进的文档中受益)。
  2. (测试覆盖率) 通常我会说在开始重构/移植之前拥有良好的测试覆盖率肯定是可取的。但是考虑到Drupal-7将测试框架转变为核心,引入了一个重大改变,我希望无论如何都需要重写大量的测试。因此,如果在迁移后不需要维护Drupal-6版本,我将节省时间/麻烦,并在移植后增加覆盖率。
  3. (早期采用者与观望) 自从4.7版本开始使用Drupal之后,我们甚至在考虑移植之前一直等待至少第一次正式发布新的主要版本。在Drupal 6中,我们在移植我们的第一个站点之前等待了views模块,而且我们在Drupal-5上仍然有一些小型项目,因为它们工作得很好,并且只要我们的客户支付额外账单就很难证明这一点。它仍然有维护/安全修复程序。一天只有这么多时间,总会有这些积压的bug修复,添加的功能等等,所以没有必要使用未完成的技术,而有更多迫在眉睫的事情可以立即使我们的客户受益。如果我们必须维护一个或多个“官方”贡献模块,现在这肯定会有所不同,因为提供早期端口将是一件好事。 我在这里遇到了一些麻烦 - 作为一名早期采用者,肯定会让社区受益,因为有人必须在问题得到解决之前找到问题,但另一方面,一小时一小时地出现bug并没有多大意义如果你只是等了一会儿,其他人可能会找到/修复。只要我必须以此为生,我就需要看我的资源,试图在为社区服务和从中受益之间达成可接受的平衡: - /
  4. (质量标准) “如果它有效,我很高兴”,但并没有削减它,因为我不想只在一瞬间快乐,而是在明天。所以我的一个质量标准是,我需要(有点)确定,为了不只是让事情顺利运作,而且让他们像他们应该做的那样工作,我已经足够好地培养了新的概念。现在很难更准确地定义,因为在“得到它”之前知道是否“得到它”显然是不可能的,所以它归结为“是的,它有点作用”与“是的” ,看起来是正确的“,而且人们必须承认,他经常会在这方面出现错误。 也就是说,我期待的一个特定点是'尽早干预'。作为一名初学者,我经常在主题阶段调整'事实'之后的东西,而通过一个钩子或另一个钩子在处理链中早些时候应用'修复'会更容易。所以,现在,无论何时我要调整主题层中的某些内容,我都会特意抽出一点时间检查一下,在早期的钩子中,这样做是否能够更加干净/兼容。正如我期望Drupal-7添加更多的钩选项,这是我会特别注意的,因为它通常会减少添加新模块时的冲突和突然的“突破”。
  5. (常见陷阱) 好 - 主要是移植到更早的阶段,之后/之间找到一个或多个所需的模块根本不可用于新版本,或仅在dev / alpha / early beta状态下。所以我会确保首先编译一个使用/需要的模块列表,列出它们的移植状态,并快速检查它们的问题队列。 除此之外,我对迄今为止的新版本及其改进感到非常满意,并且我很期待Drupal-7的再次发布。
  6. (移植时重构) 可以说移植本身是一个相当大的重构,因此不需要通过重构非移植相关的东西来增加复杂性。另一方面,如果你已经不得不将模块碎片化,那么为什么不利用这个机会进行大修呢?我会尝试根据复杂性绘制一条线 - 对于大型/复杂模块,我会尽可能直线地完成端口,并且如果需要的话可以稍后重构。对于较小的模块,它应该没有问题,因为引入细微错误的可能性应该很小。
  7. (其他东西) ...需要考虑...

好的,其他的东西:

  • 资源需求 - 考虑到一些Drupal-7线程,它看起来很可能会上升,因此在移植位于共享/受限托管帐户的较小站点之前应对其进行评估。
  • 最新版本 - 这一点在升级指南中相当明显并且一直强调,但值得一提的是:在进行重大升级之前,先将核心和所有模块升级到最新的当前版本,因为升级代码很可能取决于最新的表格/数据结构才能正常工作。鉴于Drupals'零碎',一步一步更新策略,这将是很难实现升级代码,将检测到不同的升级前状态,并采取相应的行动。

扫码关注云+社区