Magento分期和生产

Dav*_*vid 19 svn deployment version-control magento

我已经用magento开发了一段时间了,事情开始变得有意义,变得更加刻意和有组织.一方面虽然看起来仍然非常混乱 - 将网站从开发转移到生产.

任何人都可以为此提供一些好的流程 ​​- 到目前为止我只是导出/导入开发数据库,​​复制源文件,清除测试订单,客户等,然后更改基本URL,htaccess文件等.

这一切似乎有点混乱,容易出错.任何经验丰富的Magento开发人员都可以为他们可以分享的这项任务制定一个良好的流程.

Jos*_*tey 27

我的流程通常围绕源控制存储库(在我的情况下为SVN)进行管理,这使事情变得更容易(或者可能,真的......).我们的想法是在repo中保持一切可能,并使用SVN更新和标记来发布更改.

local.xml:我在SVN中移动此文件local.xml.dist并忽略local.xmlrepo中的实际文件.这使您可以在安装中使用不同的数据库凭据和主机,而不会污染代码库.

其他忽略:查看此问题以获取更多应在数据库中忽略的文件.基本上,环境中唯一的任何东西都应该远离版本控制并在实际主机上处理.您的.htaccess文件与此相关.

主机设置:我的暂存环境和开发环境设置为从存储库运行/ trunk.开发发生在这里,并且可以定期(或按需)推送到阶段,svn up以向客户端显示新功能并执行UAT.但是,生产环境需要一些来自树干Wild West的保护,以便环境不受标签的影响.每当功能集准备出去时,我都会从主干创建一个新标签并执行svn switch移动到新代码集.以这种方式做事也让我轻松撤消生产(切换回最后一个标签).因此,我已经删除了我生活中的所有手动文件推送,这很好.

一个更好的系统(我还没有必要)将用于svn export在生产系统上创建代码树的完整副本,并用于ln在它们之间切换.像这样的东西:

> cd /home/apacheuser
> ls -l
www -> /home/apacheuser/tag_1.0.1
tag_1.0.1

> svn export /url/for/repo/tags/1.0.2 tag_1.0.2
... svn exports here ...

> rm www; ln -s /home/apacheuser/tag_1.0.2 www
Run Code Online (Sandbox Code Playgroud)

这样,版本更改是即时的.

db从生产中同步:为了让我能够处理生产数据,我设置了一个cron-job来转储生产数据库并将其导入到staging中.在发生这种情况时,该脚本将删除敏感的客户数据(并更改客户电子邮件地址,以便所有电子邮件发送给我).它还会将信用卡网关设置更改为测试网关并更改base_url参数,以便临时站点URL正常工作.

新开发:您可能会注意到,不同的环境使用大致相同的代码库(减去任何新的更改),从您注意到的数据库更改等方面来看,这对您来说可能很麻烦.

管理这种复杂性(以及正确的方式,同时!)的唯一方法是确保代码本身跟踪对环境的必要更改.Magento支持自动模块版本升级,包括数据库脚本,您应该使用它来进行架构更改等.这意味着,当您将新代码部署到登台/生产时(或者从您的开发环境中的其他开发人员那里获得),所有数据库补丁都会自动应用.

这也意味着您需要编写新功能以尽可能无破坏性.Magento主题,禁用模块等可用于实现这一目标.例如,在为站点创建新主题时,请确保不要修改任何核心行为,并将所有新资产保留在主题中,这些主题在生成之前对生产是惰性的.

更多开发人员:此设置基于项目中相对较少的开发人员.有一个隐含的假设,当你想标记一个新版本时,你可以让trunk进入工作状态.随着越来越多的开发人员,情况会越来越少,因此需要更复杂的回购设置.如果我遇到这个问题,我的计划是转而使用git而不是SVN,并使用功能分支进行新的开发.


如果有任何不清楚的地方,请告诉我.希望有所帮助!

谢谢,乔

  • @Knowledge Carving这实际上是最简单的部分,涉及从命令行(或从准备好的php文件)调用mysql查询,因为大多数配置值都在core_config_data中,并且只能通过路径更新或删除.我正在将所有客户的电子邮件替换为我自己的电子邮件,并且不会发送任何意外的电子邮件.将mysql数据库复制到dev实例只是导出转储并排除日志文件并使用导出的转储重新创建dev db. (6认同)