Magento 部署的最佳实践 [英] Best practices for Magento Deployment
问题描述
我正在为高度定制的 Magento 站点设置部署流程，并想知道其他人是如何做到这一点的.
I am looking setting up a deployment process for a highly customized Magento site, and was wondering how other people do this.
我将设置开发、UAT 和生产环境.所有 Magento 文件都在源代码管理 (SVN) 中.现阶段看不到有任何更改数据库的需求，因此将手动维护3个数据库.
I will be setting up dev, UAT and prod environments. All the Magento files will be in source control (SVN). At this stage, I can't see any requirements for changing the DB, so the 3 databases will be manually maintained.
具体来说，
- 您如何应用 Magento 升级?(单独在每个 env 中，或者在 dev 上然后推出，或者只是放弃升级?)
- 在每个环境中哪些文件/文件夹是单独留下的(例如 magento/app/etc/local.xml)
- 您是否限制开发人员编辑特定文件/文件夹?
- 您是否限制主题设计者编辑特定文件/文件夹?
- 您如何管理数据库更改?
主题设计器文件/文件夹
设计师可以限制编辑以下文件夹-
Designers can restricted to editing the following folders-
app/design/frontend/your_interface/your_theme/layout/
app/design/frontend/your_interface/your_theme/template/
app/design/frontend/your_interface/your_theme/locale/
skin/frontend/your_interface/your_theme/
<小时>
扩展开发者文件/文件夹
扩展开发者可以编辑以下文件夹/文件-
Extension developers can edit the following folders/files-
/app/code/local
/app/etc/modules/<Namespace>_<Module>.xml
<小时>
数据库环境管理
由于商店的基本 URL 存储在数据库中，因此您不能只是在环境之间复制数据库.选项包括-
As the store's base URL is stored in the database, you cannot just copy databases between environments. Options include-
- 覆盖 php 中的基本 url.博客关于设置开发和暂存的文章数据库
- 复制后更改数据库中的基本 url.(这个存储在哪里?)
- 执行 MySQLDump 或备份，然后替换 SQL 文件中的 URL.
推荐答案
我建议在 SVN 上使用 git.更轻松的分支和合并意味着所有这些点对您来说都会更顺利.
I recommend using git over SVN. Easier branching and merging means that all of these points will go more smoothly for you.
应用升级:在开发中执行此操作.创建一个分支(这是 git 真正发挥作用的地方)，应用补丁文件甚至更好，解压一个新的 Magento 版本并将其指向您的旧数据库.还没有扩展.在新的 Magento 安装中打开管理员，希望最好.在次要版本之间升级可能不会有问题.在安装所有新东西后，您可能需要重新编制索引.稳定后进行提交，然后逐渐将您的扩展和主题引入分支，进行任何代码调整，然后在每一步证明稳定后进行提交.
Applying upgrades: Do this in dev. Make a branch (this is where git really shines), apply the patch files or even better, unpack a new Magento version and point it to your old database. No extensions yet. Open the admin in the new Magento installation an hope for the best. Upgrading between minor versions probably won't be a problem. You will probably have to reindex after all the new stuff installs. Do a commit once this is stable, then gradually bring into the branch your extensions and themes, make any code adjustments, then doing a commit after each step proves stable.
环境相关文件: .htaccess 和 app/etc/local.xml.我为每个做了一个单独的版本:local.dev.xml, htaccess-devlocal.staging.xml, htaccess-staginglocal.production.xml, htaccess-production
Environment-dependent files: .htaccess and app/etc/local.xml. I do a separate version for each: local.dev.xml, htaccess-dev local.staging.xml, htaccess-staging local.production.xml, htaccess-production
...然后为每个环境制作指向它们的软链接:
...and then make softlinks to them for each environment:
ln -s htaccess-dev .htaccess
cd app/etc/
ln -s local.dev.xml local.xml
等等.
限制某些开发人员的访问:我不这样做.但是，您可以在 git 中制定部署策略，让发布经理决定哪些内容可以进入，哪些不能.
Restricting access to certain developers: I don't do this. However, you can develop a deploy strategy in git that lets a release manager decide what goes in and what doesn't.
管理数据库更改:这是最棘手的部分.我们只使用生产中的 mysqldump，并为每个环境准备了一些env-setup.sql"文件.类似这样的事情(您的 ID 可能会有所不同):
Managing database changes: That's the trickiest part. We just use mysqldump from production, and have some ready-made "env-setup.sql" files for each environment. Something like this (your ids may vary):
UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4);
我通常会添加更多指令，将支付网关更改为测试环境、更改外发电子邮件等.您可以在 core_config_data 中找到其中大部分.
I usually add some more instructions that will change payment gateways over to test environments, change outgoing emails, etc. Most of these you will find in core_config_data.
请记住，模块通常会对数据库进行自己的更改，因此应用制作精良的模块通常会自行处理.在任何情况下，都不要对 prod 应用未经测试的更改，始终在本地和暂存环境中进行排练".
Remember that modules will usually make their own changes to the db, so applying a well-made module usually takes care of itself. In any case, never apply untested changes to prod, always do "rehearsals" on local and staging environments.
您可以通过转储和加载来自任何环境开发的 cms_* 表，从数据库中获取 CMS(页面和静态块)数据.
You can get the CMS (pages and static blocks) data out of the database by dumping and loading just the cms_* tables from whatever environment development was done on.
祝你好运！
这篇关于Magento 部署的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
