最佳部署策略是什么？

82

设置Magento商店不仅是开发可自行安装的扩展程序，还需要大量“手动输入”操作，例如创建最终编辑属性，类别，产品，价格规则CMS页等，更不用说全部了系统配置的更改。

在部署Magento商店从开发到暂存和生产环境的过程中，我希望您能概述最佳策略。

我的一种策略是编写一个以编程方式创建上述实体的“部署模块”，但这是一个非常耗时的任务，有时对我而言似乎有点过大。

最近，我开始使用Selenium IDE重现Admin任务，但是设置所有测试套件所需的时间与上面提到的时间相距不远。

也许最佳的解决方案是使用能够对Magento系统进行快照的模块，让您选择要部署的模块。

所以：

您的部署策略是什么？
是否有一个模块可以对Magento系统做快照，让您选择要部署的内容？
如果不存在这样的模块，并且提供了这样的模块是合理的解决方案，那么是否有人有兴趣为他/她的开发做出贡献？

谢谢！

deploy admin entities

— 亚历山德罗·隆奇（Alessandro Ronchi）
source

这可能表明需要另一个标签或标签类别。您是一次性商店还是作为服务提供商的一般建议？如果是后者，则任何答案都必须加上“取决于客户希望对实体数据进行多少控制”。

— benmarks

我的观点是属于开发团队的一名开发人员。假设我正在开发一个需要一些数据才能起作用的部分，例如类别结构。我通过Admin创建结构，执行代码并推送代码。我想知道最好的策略是否是还要编写和推送创建所需类别结构的代码。如果我的类别结构或设置与其他自行开发的开发人员的类别结构或设置冲突，该怎么办？如何处理冲突？这就是我的意思。

— 亚历山德罗·隆奇

@AlessandroRonchi这是一个有争议的话题，永远不应该发生冲突。您的类别结构并不是应该轻而易举地更改的，因此，一个开发人员不应在其他人不知道的情况下对您的结构进行重大更改。如果发生这种情况，则需要解决开发人员之间的通信。通常，从第一天起就需要确定网站的类别结构，而无需再更改，只需添加即可。如果您确实需要更改它，那么您第一次就没有正确地将其范围限定。

— ProxiBlue

不幸的是，在我认识和工作的世界里，@ dedmeet每天都在变化。客户改变主意，开发商改变主意，黑天鹅出现。我必须做好改变的准备；无论如何，即使从第一天起就不需要更改类别结构，它也只是整个部分的一小部分，整个部分都是一个“进行中的项目”项目，应该进行更改以完成任务。

— 亚历山德罗·隆奇

当然，我们确实在不断变化的环境中工作，但是我仍然认为类别结构冲突不应该发生。每个分支都更改结构的地方不应存在多个分支，这只会导致问题和开发时间的浪费。为什么开发人员花时间在结构b进行更改的同时将结构更改为不同的结构，并且他们俩都在推动工作呢？如果必须更改结构，则项目中涉及的所有开发人员必须参与确定新结构的过程。您能否提供一个示例来帮助我了解何时会发生这种情况？

— ProxiBlue 2013年

39

我的观点是编写所有脚本。通常，对于没有与功能上特定模块直接相关的任何内容，我通常都有一个基本配置模块。（例如，将以前的网站url创建为自定义url重写为新的网站url），并将与模块相关的任何内容添加到其自己的安装脚本中。

这背后的想法是，如果需要使用新的数据库重新安装该站点，则一切都会恢复原样。这也有助于我定期使用实时数据库副本更新uat站点。然后，uat中的模块会继续工作，因为它们再次插入了配置。

更改邮费，购物车规则等（基本上是客户在admin中自行管理的事情）被视为“易失性数据”，并且没有编写脚本。这包括产品数据。客户可以选择，并鼓励客户首先在uat站点上测试新的导入。

告知客户不要创建属性，而是通过票证请求来创建属性。然后，这使我还可以收集有关客户对属性的意图的信息，有时我有更好的建议，或者可以创建更好的代码，因为我可以处理存在的属性以及可选属性，从而确保数据正确无误。清洁。

是的，脚本编写需要更长的时间，但是稍后手动重新创建整个网站配置设置会花费更长的时间。如果您忘记了某些内容并导致站点无法正常运行，或者在缺少某些关键配置设置的本地站点上进行了新的开发工作，这也可能会令人尴尬。

— ProxiBlue
source

1

我同意dedmeet。当您第一次学习如何编写所有更新的脚本时，这可能是更多的初始工作，但是如果您必须手动为3-4个开发人员（暂存，调试和实时运行）应用配置更新，则协调和实际工作将花费更长的时间。我们的工作流程非常相似：如果（可重复使用的）扩展需要配置，则将其放置在那里。如果配置是特定于客户端的，请将其放在特定于项目的扩展名中。购物车规则是少数例外之一，根本无法进行更新/创建。

— Matthias Zeis 2013年

1

我只是发布了一个模块，该模块可帮助创建所需的配置脚本，从而消除了必须手动创建安装脚本的繁琐工作。该模块使用core_config_data表的网格显示来允许导出配置值的选择。让我的生活更简单一点，我希望它对其他人有用。proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue 2013年

27

几个月前我曾做过一些研究。这是您可以参考的网站。

~~Magento基本URL和开发/登台安装~~
Magento开发和部署
 Magento Git指南和工作流程
 更快转储Magento MySQL数据库以进行分支

— OğuzÇelikdemir
source

1

谢谢，我将阅读所有这些内容，然后再考虑一些问题。

— 亚历山德罗·隆奇

我已经阅读了所有捐赠资源；我已经知道其中一些，其他我不知道的非常有趣。无论如何，它们都不是解决我的问题的方法，因此我决定草拟一个可以满足我的需求的扩展。谢谢大家给我的宝贵建议。我希望回到这里获得一些结果。

— 亚历山德罗·隆奇

亲爱的亚历山德罗，我想看看你的方式，我也希望自己的技术更舒适！

— 奥古兹Çelikdemir

18

我要感谢大家，因为您的考虑启发并促使我开发了一个扩展，称为“ Mageploy”，目的是解决保持不同环境同步的问题。

http://www.mageploy.com

即使我已经将Mageploy用于具有一些好处的几个项目中，但仍必须对其进行扩展，充分记录并进行全面测试。

它是开源的，任何帮助或建议将不胜感激。

问候

— 亚历山德罗·隆奇（Alessandro Ronchi）
source

7

关于安装脚本和创建实体，我的一般感觉是，如果模块需要或期望它，则应将其作为安装脚本的一部分进行创建。

最近，在开发/阶段/生产方面，我们将登台站点用作内容数据库的主副本，因为这意味着客户可以进行协作。过去，我们遇到的最大问题可能是与客户协调内容输入，尤其是在产品上传方面。

您如何看待快照？我认为在理想的世界中，您将拥有一个工具，可以显示两个数据库在特定类型（产品，类别，CMS等）上的差异，并允许您将更改合并到另一个数据库中，但是我不知道有什么可用的工具，例如那。

— 保罗
source

1

“关于安装脚本和创建实体，我的一般感觉是，如果模块需要或期望它，则应将其作为安装脚本的一部分来创建。” 这是要考虑的最突出的点，并且适用于配置设置。我的快速测试：当我需要一个新的开发人员来克隆存储库并安装环境时，系统需要具备什么功能？

— benmarks

从理论上讲，与客户共享登台站点以协作进行配置是很棒的。实际上，客户不会在99％的时间内告诉您他们更改的所有内容，这很容易搞砸。我们可能允许客户处理购物车规则，类别，产品或类似内容，但我们不允许他们干扰配置。

— Matthias Zeis

6

在我看来，创建和编辑属性，类别，产品，价格规则与“部署策略”无关。所有这些商品对于商店来说都是非常独特的，并且在大多数情况下，需要对您的产品进行适当的分析和研究将要出售。

如果您要创建“一刀切”的商店，并且提到的所有元素都具有相似的配置，则可以在完成每个商店所需的所有设置后对数据库进行“快照”导出。

— 罗格
source

不，“一种尺寸适合所有人”不是重点；在开发人员将我们的源代码与开发团队的另一成员合并时，我们也遇到了同样的情况：在这种情况下，我们拥有执行魔术的源代码控制系统。我的问题与合并“非开发人员”内容（例如配置设置和典型的管理员设置和条目）的机会有关。

— 亚历山德罗·朗奇

嗯，这更清楚了

— 罗格（Rutger）2013年

假设我们正在创建一个完整的新网站，因此旧数据等都不会出现问题。几乎所有的开发人员一直都在使用相同的数据库进行开发。那解决了很多问题。对于其他情况，我还没有写出某种路线图/脚本中所需的所有步骤并在合并后重新使用它们的更好的解决方案。如果只有一个人负责“ magento核心”管理设置，则这些步骤不应太多。我曾经发现这一点，但从未尝试过tinybrick.com/magento-modules/admin-tools/…–罗格

— Rutger）

2

我想添加两个出色的省时工具：

开发：带Magicento插件的PhpStorm IDE
部署：Magentify，Magento的Capistrano配方

— ondo
source

感谢您告知我们有关Magentify的信息，我不知道，请尝试一下。但是，我的重点更多是在同步不同的开发环境上，而不是在发布代码库的意义上进行部署。Mageploy可以与Magentify集成在一起，但它是一个不同的工具，用于自动保持数据库更改的某些部分对齐，而与不同环境之间不同的特定ID无关。真诚的，亚历山德罗

— 亚历山德罗·隆奇