我使用 git 进行版本控制。我有一个开发、暂存和生产环境。当我完成开发时,我将推进到分期以供客户审查。获得批准后,我会将更改从暂存阶段推向生产阶段。只要没有数据库更改,它就可以正常工作。如果我在本地开发中通过 Magento 连接安装模块并修改数据库,会发生什么情况。
既然生产服务器总是在变化,我该如何将这些更改推送到生产服务器?
编辑:
我写了两个 shell 脚本。一个将生产数据库 pull 到我的开发服务器,用开发 url 替换基本 url 并相应地更新我的开发数据库。它还将生产 sql 转储留在后面以添加到我的 git 存储库中。我不太确定将原始转储保留在源代码管理中是否有益,但我会尝试一下。第二个脚本将开发数据库移至暂存区,并基本上执行与第一个脚本相同的操作。
现在,当需要转移到生产环境时,我将更新后的生产存储库 pull 入生产服务器并允许 magento 执行它。我最近也开始使用 SQLYog,它有一个数据库比较向导,可以给我开发和生产数据库的差异,并允许我有选择地 merge 更改。它总是创建一个迁移脚本,我也将其添加到源代码管理中。如果出现任何问题,我可以运行比较以查看是否遗漏了任何内容。
你们觉得这听起来像是一个不错的工作流程吗?
最佳答案
这是开发人员的常见情况。修改代码和模式要容易得多,并且当有一个被彻底理解并且没有太多 UI 灵 active 的小代码库时,可以确保一切都很好。当然,Magento 的情况并非如此,它很难融入自动化测试和持续集成方案。也就是说,您可以依赖一些已知的、可测试的行为。
概述
在处理 merge 到生产的本地开发时,必须确保在更新文件系统时也应用与新功能或更改功能相关的架构和数据更改。这实际上是 Magento 本身的工作方式。模块配置文件可以提供版本号并可以配置设置资源。此信息用于进入架构和数据修改工作流程,从而将版本信息添加到数据库中。文件指定的版本号和数据库注册的版本号之间的一致性,可以/系统可以推断数据库在给定文件的情况下处于适当的状态。
这意味着当新的/更新的模块文件 merge 到生产环境并且满足必要条件(例如配置缓存无效等)时,应该进行数据库升级。您(正确的)担心的是,此过程可能会因远程服务器级别差异、远程数据差异等而中断。如果没有严格监管的集成测试过程,则会产生一些开销。
进攻计划:选择正确的策略
该领域的基本事件是评估模块对数据库的影响领域。对于任何值得安装的模块来说,这应该是直截了当的;检查以下任何一项:
- system.xml 文件
- sql 或 data 文件夹中存在安装/升级脚本
- 存在自定义设置资源类(在
global/resources
xpath 下配置) - 适当的配置 XML(模块配置节点中的版本号和
global/resources
xpath 下的设置资源)
对于 1,只需查看结构即可知道它对数据库的影响将仅限于 core_config_data
表,并且通常仅在管理员通过 GUI 保存值后(注意 1.以下内容也适用)。
对于 2 和 3,查看设置为运行的脚本。这些可以分为三个一般领域:
1. 配置设置 - 查找 setConfigData()
和 deleteConfigData()
调用
2、表的增改(新建表、增加列等)
3.EAV相关的修改和补充;寻找 EAV 设置资源
4. 非EAV数据变化:安装新数据或修改现有数据
这是一个感觉和直觉的问题,但是衡量对数据库的影响程度将允许您确定是否应该将生产数据克隆到本地开发人员并在本地测试设置工作流,验证它是否正常工作,然后推送到生产和重新检查(始终备份!)。如果更改范围很广,最好让网站脱机,这样您就可以确保在升级失败后需要恢复时不会丢失订单或客户数据。
关于database - 将 magento 数据库从开发同步到生产,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12324641/