2012-08-01 82 views
9

制作Magento更新(维护不当的Magento安装)的最佳做法是什么?进行Magento更新的最佳做法?

我想的东西像下面这样:

  • 看一看在应用程序/代码/本地全重写模块 - 其中的文件与旧版本比较和转发端口到新的Magento版本
  • 比较模板
  • 比较布局XML文件(如果它们被直接复制到自定义主题文件夹,并使用了仅含真正的更新没有单一layout.xml)
  • 比较重写类的方法的方法原始类

主要问题是:当在旧的,维护不良的Magento安装中区分文件时,您永远不知道,原始文件被复制到哪个版本。有时我试图通过查看Magento在文件评论中的版权来识别旧版本。

为了避免更新过程中的麻烦,我们平时做到以下几点:

  • 避免重写,使用事件,而不是
  • 如果重写是必要的,尽量不要复制的代码,但调用parent ::()方法,以保持只有在覆盖类
  • 如果复制的代码需要必要的功能,使用标记注释,例如[Mycompany BEGIN] ... [Mycompany END]
  • 不要复制整个布局文件,但使用单个layout.xml,做只更新。

但是如何进行更新,如果这些防范措施没有采取?

+0

这种类型的问题并不真正属于Stack Overflow,因为它不是编程问题。你应该看看http://area51.stackexchange.com/proposals/25439/magento,看到有关获取适当的地方把这些样的问题 – Sturm 2012-08-02 18:23:02

+0

@paperids:版本比较四周,代码移植到一个新的版本也realated编程。但是感谢指向stackexchange提议的指针。 – Alex 2012-08-03 20:43:09

回答

0

我会做的第一件事是将网站复制到开发环境。现在做一个备份,以便您可以随时恢复到您需要的状态。同样在这一点上,我会把代码锁定的现场。除非绝对必要(并且如果有变化,您将不得不在新的开发环境中复制它们),否则不会再对代码进行任何更改

既然您已经有可供您使用的网站的安全副本,现在乐趣开始。

我会做的第一件事是拉下你正在运行的Magento股票版本的副本。在股票版本和你目前拥有的版本之间做一个差异/ app/code/core。这会告诉你你有什么不同。我会尽量保持你现有的所有功能,同时让核心恢复正常。

希望在这一点上你有一个非常干净的Magento安装。你可以考虑把它推回给现场服务器,但我有一种感觉,你可能不得不做很多瞎猜才能把它变成现实,所以它可能不是一个可行的选择。

现在我将对开发站点进行单独备份,以便您可以根据需要回到这一点。

现在,我会尝试在开发网站上进行升级。希望这一切都可以实现,而且升级没有问题。如果你不这样做,那么你需要修正并从那里继续。

在这一点上,你应该有一个稳定的升级代码库。重新备份(为了安全起见),推新代码,并希望一切正常。

+0

谢谢。但是,如果许多类被重写,布局文件被复制等,那么在app/code/core中没有任何补丁的“干净的”Magento仍然会导致问题。所以稍后在大型Magento安装中会有很多调试。 – Alex 2012-08-01 12:24:57

1

我首先注意到你的问题的内容表明对(我至少认为是)最佳实践有清楚的理解。

关于潜在的多个版本的起源:软件升级的目标是让新的类和方法到位。这意味着(正如您所提到的)移植任何自定义,无论它们是如何实现的。

在努力的差异之外,不幸的是您的状况的最佳技术将是回归测试 - 检查生成的输出为多个视图。

这很可能是,你可能需要踢的情况下,即开始用干净的安装,并积极引进自定义功能&主题化这仍然是必要。这似乎不是最有效的方法,但这里有我相信超过明显的开销好处:

  1. 你会在所有的自定义行为的控制,没有惊喜
  2. 您将得到保证的单一起源
  3. 健康的代码库在某些时候给客户成为代码的所有者和白名单/积极性的做法重返定制似乎是确保您的所有权是你所期望的最佳途径。
12

正如其他人已经注意到,这里的关键是要使它与干净的安装相媲美,所以这里是我在版本控制的帮助下做的事情。

  1. 让自己现在你正在使用的Magento的干净版本,不要忘记使它可比较。或者使用的Magento的现有的git镜(详见http://blog.speedupmate.com/post/4063307705/magento-git-mirror

  2. 设立依据1.这里的主回购,并有它在手问在评论

    :你的最终目标是有一个干净的核心所有git中的文件都存在于magento安装文件中。这是必要的,所以你可以比较一切与干净的安装。管理核心变更,核心文件树(现有的,不存在的,添加的文件)。您可以使用.gitignore处理异常(不包括介质,缓存,所有与服务器相关的作用域local.xml .htaccess)。我发现将Magento核心文件移出到不同的(非公开的)目录是很容易的(这里解释为http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento),这会给我一个代码状态,其中.htaccess在升级时永远不会发生冲突。我也从不将媒体包含在版本控制,缓存和magento生成的所有临时文件中。这将保证您清除升级路径,因为您可以禁用所有升级时间。稍后比较代码将为您提供需要概览的范围,并且您可以估计需要多长时间来比较更改的部分并升级。

  3. 与您现有的网站和混帐配置现在

    到位(使其可比性)做你的代码库git init并添加一切与git那里,这会在你的混帐配置,使每个文件可比性(同换行符空格等),然后修复文件权限是相同的。之后,您可以从您的网站中删除.git文件夹,因为您只使用git使文件在那里可比。

    在评论中提问:这里的要点是要让git为你工作,就像将所有行结束符转换为unix样式并忽略空白区域一样,理论上你可以忽略权限,但这样做没有用(格式化在这里“代表命令

    git config core.autocrlf input \ git config core.eol lf \ git config apply.whitespace nowarn

    现在,如果你这样做git init 和添加这些CONFIGS并添加一切承诺阶段git会取代你的所有窗口行结束和所有的垃圾,以统一和可比期间的git然后之间的换行符请注意,zend编码标准提供了unix样式的行结尾,不过你会a也可以查看Zend库不遵循它自己的标准的文件。这里的关键是你需要你的文件是可比较的,以最大限度地减少你必须做的差异负载。 git格式化所有坏的安装文件后,您将删除.git文件夹。 Git仅用于在此步骤中自动执行“制作可比较的流程”,而不会执行其他任何操作。

  4. 从您的主回购库中检出您的测试存储库,并检出包含当前版本的分支并命名“testsomething”或任何你需要的东西

  5. 从该结帐文件夹中删除一切,只留下.git到位,所以它是空的,但版本控制仍然存在那里。它会处于状态,像所有内容都被删除,这在这里很重要,因为你会知道你可能在你的坏站点上删除了哪些文件。

    在评论中提问:我通常添加空白忽略git配置(本地或全局范围可用),让git为我处理。当我们在团队中工作时,我们总是同意基于Zend的标准:在3处提及4个标签,unix样式行结尾和git配置变量空间,如果涉及到构建脚本,我们使用提交钩子进行代码格式化和验证。

  6. 中的所有文件到您的空目录移动(请注意,您从现有的网站中删除。git的目录使其可比性之后)从˚Fcked了Magento的安装(他们现在可比)和运行git status > changes.txt 。现在,该文件列出了您在“f联机安装”中所拥有的每个不同之处,您拥有的任何新文件,任何已删除,已重命名等文件,以及您当前使用的干净Magento代码。

    说明基于评论:我通常做git status --porcelain

  7. 已经制定了的.gitignore文件来帮助你放弃local.xml中VAR/*或每一个文件/目录,你不需要版本控制和也.DS_Store,.Thumbs.db和你的ide从git创建项目文件。您不需要版本控制中每台服务器上不同的所有介质和缓存文件和文件。

从那里,你应该仔细概述该名单并根据该列表中你应该:

  • 每移动核心改变应用程序/代码/ local /,并且签了改变的文件到它的原始状态(保持复制一个,并丢弃在核心与git checkout filename变化)
  • 每移动改变核心模板和布局文件发送给自己的主题文件夹和检查用更改后的文件到它的原始状态
  • 恢复或迁移的.htaccess变化或慈德,如果你需要保存或放弃

现在,你仍然是在恶劣的形状,但你现在是:

  • 基于清洁核心
  • 基于版本的主树在一个单独的分支

现在,您可以受版本控制,可比较和基于您的主分支的独立分支,该主分支中具有Mergeable版本的Magento。因此,让我们尝试升级,这是做到这一点100%成功的关键点。

  1. 第一步将禁用所有现在已分离到app/code/local/Mage /并分离主题的“垃圾”。如果你的核心是明确的,主题可以被禁用,你就没有自定义代码干扰升级过程。所以,尽管禁用:

    • 所有通过移动出来的应用程序的本地扩展和定制社区扩展的/ etc /模块/到临时文件夹让它成为应用程序的/ etc /无效/
    • 禁止自定义主题,并开启基地/默认/
    • 这是你在处于可比较状态的好处。你知道什么是不同的,你可以禁用和诊断依据是
  2. 事已至此,如果你有在你的回购标记主树中的所有主要版本或单独支然后让版本更高的仅仅是一个命令离开:再次混帐合并“的Magento,vhateverthenextversionis”

    • 这样做后,“混帐地位> changes.txt”会给你的版本上运行浏览器的网站将进行升级之间
    • 所有修改过的文件的列表并且由于您处于默认主题并且没有激活自定义,它将执行像一个魅力
    • 按版本重复升级版本,并通过标记在您的测试分支保存您的代码状态或基于现有的测试分支为每个版本创建一个新的分支,这样你已保存每个magento版本的干净状态升级在
    • 之间在这里再次额外的好处是,如果你使用版本控制做到这一点,你也将摆脱新版本丢弃的文件,你可以删除它们很容易
  3. 如果你已经重述, 2。到所需的Magento版本最新那么现在是时候吃了“S *它”你继承和做以下:

    • 分析你所有扩展,看看他们是否可以升级,如果你能升级并打开看看他们是否有默认主题
    • 在app /代码/本地/法师工作DIFF每个内核重写针对它的新形式的原始版本来自应用程序/代码/核心/法师。您可以使用像winmerge.org或变化差异工具(你喜欢的任何操作系统和工具)一个由一个或版本比较整个文件夹
    • 同去与你的模板和覆盖模板或布局。比较原始和合并更改新的基础模板,并从旧DOM摆脱
    • 接通主题的变化和扩展逐一调试
  4. 如果你到这一点,那么你已经做了shitload的工作,取决于如何搞砸安装是可能需要几天。但是,嘿,现在你有一个干净的magento核心,它受版本控制,被合并和概括的分开覆盖,以及可以被禁用的单独主题中的所有东西。

  5. 有趣的部分是,如果下一次升级magento可用,您可以吹口哨并将它添加为与主树相比,并合并更改,知道发生了什么变化,并且清楚了什么要进行概述和测试。

+0

一个好的和详细的答案。我们做类似的事情。 请您详细说明3.在第一个列表中?说实话,我不明白做'git init'有什么用处,然后再次删除.git文件夹而不更改存储库中的任何内容。 与6)在这种情况下,你可能还需要像做'git的差异-p --diff过滤= M -b -w> modifications.txt'部分或全部文件。您可以查看哪些文件在修改后的文件中发生了更改,忽略了您在此时可以忽略的空格。 – 2012-08-02 04:11:33

+0

关于第二个列表中的2.):你如何处理合并重新引入的不必要的文件? (不需要的模板主题,皮肤等)。对于媒体/我们用符号链接替换的目录也是如此,以便在使用相同媒体文件夹时轻松地在我们的商店代码版​​本之间切换。我们必须注意媒体/保持符号链接,并且不会被目录取代。 – 2012-08-02 04:19:25

+0

编辑我的答案2,3,6。因为我需要的“状态”我不管理附带安装包我从来不删除或忽略它们不需要模板主题相媲美,他们不跟我的所作所为无论如何干扰。我的目标是永远不要更改安装包随附的任何文件,并将所有编辑作为扩展名,单独的区域设置文件,单独的主题/皮肤文件。我忽略了媒体,tmp和Magento从版本控制中即时生成的所有文件。 Git的他这里管理一般的变化对我来说,保持它分开仅仅是关键,“可比状态” – 2012-08-02 07:12:24