我使用git进行版本控制。我有一个开发，升级和生产环境。当我完成开发时，我会推送到客户端进行审查。批准后，我将更改从分段推送到生产。只要没有数据库更改，这样就可以正常工作。如果我通过Magento连接在本地开发上安装模块并且它进行数据库修改会发生什么。
由于生产服务器总是在变化，我如何将这些更改推送到生产服务器？
修改
我写了两个shell脚本。将生产数据库下载到我的开发服务器，将基本URL替换为develpment url并相应地更新我的开发db。它还将生产sql转储保留在我的git仓库中。我不确定将原始转储保留在源代码控制中是否有益，但我会尝试一下。第二个脚本将开发数据库移动到分段，并基本上执行与第一个相同的操作。
现在到了生产的时候，我将更新后的生产仓库拉到生产服务器上，让magento做到这一点。我最近也开始使用SQLYog并且它有一个数据库比较向导，它将为我提供开发和生产数据库的差异，并允许我有选择地合并更改。它总是创建一个我添加到源代码控制的迁移脚本。如果出现任何问题，我可以进行比较以查看是否遗漏了任何内容。
这对你们来说听起来像是一个不错的工作流程吗？
答案 0 :(得分：7)
这是开发人员的常见情况。修改代码和模式要容易得多，并确保当有一个完全理解的小代码库并且没有太多的UI灵活性时，一切都很好。当然，Magento的情况并非如此，因此很难将其用于自动化测试和持续集成方案。也就是说，您可以依赖一些可知的，可测试的行为。
概述
在处理合并到生产的本地开发时，必须确保在更新文件系统时也应用与新功能或更改功能相关的模式和数据更改。这实际上是Magento本身的工作方式。模块配置文件可以提供版本号，并可以配置设置资源。该信息用于进入模式和模型。数据修改工作流程，导致版本信息被添加到数据库中。文件指定的版本号和数据库注册的版本号之间的一致性是，系统可以推断数据库在给定文件存在的情况下处于适当的状态。
这意味着当新的/更新的模块文件合并到生产并且满足必要的条件（例如，配置缓存无效等）时，应该进行数据库升级。您（正确）担心的是，此过程可能会因远程服务器级差异，远程数据差异等而中断。如果没有严格监管的集成测试流程，则会产生一些开销。
攻击计划：选择正确的策略
该领域的基本活动是评估模块对数据库影响的领域。对于任何值得安装的模块，这应该是直截了当的;检查以下任何一项：
global/resources xpath下配置）global/resources xpath下的设置资源）对于1，只需查看结构并知道它对数据库的影响将仅限于core_config_data表，并且通常只有管理员通过GUI保存值后才会知道（注意以下1.适用于孔）。
2＆amp; 3，查看设置为运行的脚本。这些可分为三个一般领域：
1.配置设置 - 查找setConfigData()和deleteConfigData()来电
2.表添加和编辑（新表，添加列等）
3.与EAV相关的变化和增加;寻找EAV设置资源
4.非EAV数据变化：安装新数据或修改现有数据
这是一个感觉和问题的问题直觉，但衡量对数据库的影响程度将允许您确定是否应将生产数据克隆到本地开发人员并在本地测试设置工作流程，验证它是否正常工作，然后推送到生产和重新检查（始终备份） ！）。如果更改范围很广，最好让网站脱机，这样您就可以确保在升级后需要恢复时不会丢失订单或客户数据。
答案 1 :(得分：2)
您通常不希望从dev＆gt;中推送数据库中包含的数据。刺。您的架构defs应该包含在Magento sql安装脚本中。如果您确实需要实际的新数据，那么您必须根据具体情况这样做。你很可能从prod＆gt;下拉开发人员在生产实际案例之前测试数据和配置。
答案 2 :(得分：-3)
案例 - 1：
如果您的生产服务器具有与本地相同的数据（DB），则只需将数据库和文件复制到生产服务器并执行以下操作：
1）删除文件夹/ var
的内容2）更改文件/app/etc/local.xml的值 在那里，您可以找到您的连接字符串数据（数据库用户，主机和名称）。
3）上传数据库后，您需要进行一些更改。
运行此查询：
SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';
UPDATE core_config_data SET value = 'YOUR_NEW_LIVE_URL' WHERE path LIKE 'web/%/base_url';
这就是全部。
案例 - 2：
如果您不想更改生产中的数据库数据，则需要通过megento connect将模块直接安装到生产服务器。您可以在Local中更新已更改的文件。