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