不完全是这样的问题。Magento EE 内置了 staging,也可以合并您的数据。你必须明白,如果没有一些严肃的同步框架来跟踪每一行和每一列的状态,知道哪些数据是新的,哪些是旧的,并解决同步冲突,那么从开发到实时同步数据是不容易的。
这是您的流程,假设您使用的是 CE 并且没有捆绑数据迁移工具。
- 设置实时数据库并计算数据只会从实时移动到开发,而永远不会从开发移动到实时,因为您没有数据迁移。您需要在数据库级别进行和保存的每个配置都在实时数据库上进行(在开发环境中测试它们,然后在实时环境中创建)
- 制作一个shell脚本,fabric脚本任何你喜欢的部署脚本,它将导出实时数据库转储,删除dev数据库(如果存在)并创建一个新数据库并将实时数据库导入其中,运行将更改/删除的pre或post sql脚本与环境相关的配置值(如 base_url、secure_base_url 等)
- 为避免重复数据输入,请始终创建您需要使用 magento 设置脚本保留的所有属性和配置值。
代码也是如此,这是一个具有实时、舞台和开发环境的常见设置场景
- 一个基于干净的 magento 版本树的主版本控制(最好是裸露的,以避免有人在那里更改文件)存储库
- 为每个环境(live、stage、dev(n))和一个经过验证的代码流从 dev(您开发并且可能有损坏的代码库状态)到 stage(发布候选驻留并准备好测试并且不会更改)的单独分支从舞台到现场(您的现场代码处于稳定状态)
- 每个开发人员都在从 dev 分支结帐并提交到自己的 dev 分支,然后将更改推送到 dev 在那里可以评估并确定更改是否足够成熟以进行暂存
- 阶段是发布候选者存在的地方,客户可以测试(或自动化测试)并诊断它是否准备好发布,没有人在这里更改代码并且代码来自开发分支
- live 是实时运行的版本,没有人直接更改任何代码。如果测试通过,代码只能从阶段来到这里
所以为了更好地可视化它,想象你的代码库驻留在 git 中。
myproject_magento_se (your project git repository on bitbucket.org or in github or wherever you can host)
--> master (branch with all clean magento versions from your current to latest)
--> dev (git checkout -b master (or by specific version from master)
--> stage (while on dev: git checkout -b stage)
--> live (while on stage: git checkout -b live)
并想象您的主机设置如下:
www.mylivesite.com = git clone yourgitrepo; git checkout live;
stage.mylivesite.com = git clone yourgitrepo; git checkout stage;
dev.mylivesite.com = git clone yourgitrepo; git checkout dev;
对于所有这些,您最好拥有部署脚本,只需按一下按钮,即可在环境之间进行切换、代码和数据库提升。
以下是您每天需要对每个软件项目执行的一些常见操作
- 从现场移动/重置数据从现场到开发(如果需要加扰或更改客户端相关数据,请进行混淆调用)
- 将代码从开发移动到阶段
- 将代码从舞台转移到现场
- 重置/创建任何具有实时状态的开发人员(数据和代码)
玩得开心 :) 并通过这个线程以及https://superuser.com/questions/90301/sync-two-mysql-databases和所有其他你可以在类似的问题上搜索 SO。