Magento部署的最佳做法 [英] Best practices for Magento Deployment

问题描述

我正在为高度定制的Magento网站设置一个部署过程，并且想知道其他人如何做到这一点。

我将设置dev，UAT和prod环境。所有Magento文件都将进行源代码控制（SVN）。在这个阶段，我看不到任何更改数据库的要求，所以3个数据库将被手动维护。

具体来说，

• 如何应用Magento升级？ （在每个环境中，还是在开发环境中单独启动，还是放弃升级？）


• 在每个环境中单独留下什么文件/文件夹（例如magento / app / etc /您是否限制开发人员编辑特定文件/文件夹？


• 您是否限制主题设计师编辑特定的文件/文件夹？ / li>
  
• 如何管理数据库更改？

---

主题设计器文件/文件夹

设计师可以限制编辑以下文件夹 -

  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 / 
  

---

扩展开发者文件/文件夹

扩展开发人员可以编辑以下文件夹/文件 -

  / app / code / local 
 /app/etc/modules/<Namespace>_<Module>.xml 
  / pre> 
 
 
 
 
 
 数据库环境管理 
 
 
 
由于商店的基本URL存储在数据库中，因此您不能只在环境之间复制数据库。选项包括 -  
 
 
 
 
 
覆盖php中的基本URL。 博客
关于设置开发者的文章并分期
数据库 
 
 
复制后更改数据库中的基本URL。 （ 
 
 
执行MySQL转储或备份，然后对SQL文件中的URL进行替换。
 
 
 
 
解决方案
我建议在SVN上使用git。更容易的分支和合并意味着所有这些要点将更加顺利。
 
 
 
 应用升级：在开发人员中执行此操作。做一个分支（这是git真正闪耀的地方），应用补丁文件甚至更好，打开一个新的Magento版本并将其指向您的旧数据库。还没有扩展在新的Magento安装中打开管理员希望最好的。次要版本之间的升级可能不会是一个问题。在安装所有新东西后，您可能需要重新编索引。做一个提交一旦这是稳定的，然后逐渐带入分支你的扩展和主题，进行任何代码调整，然后在每一步证明稳定后进行提交。
 
 
 
 环境相关的文件： .htaccess和app / etc / local.xml。我为每个单独的版本：
 local.dev.xml，htaccess-dev 
 local.staging.xml，htaccess-staging 
 local.production.xml，htaccess-production 
 
 
 
 ...然后为每个环境制作软链接：
  ln -s htaccess-dev .htaccess 
 cd app / etc / 
 ln -s local.dev.xml local.xml 
  
等等。
 
 
 
 限制对特定开发人员的访问：我不这样做。但是，您可以在git中开发一个部署策略，让发布管理员决定发生什么，什么不在。
 
 
 
 管理数据库更改：
  UPDATE core_config_data SET value ='http：//magento.dev/'WHERE config_id IN（3,4）; 
  
我通常会添加更多的说明，将会更改支付网关到测试环境，更改发送的电子邮件等大多数这些都可以在core_config_data中找到。
 
 
 
请记住，模块通常会对数据库进行自己的更改，因此应用一个精心设计的模块通常会自行管理。在任何情况下，永远不要对未经测试的更改应用于prod，总是在本地和分段环境中执行排练。
 
 
 
您可以获取CMS（页面和静态块）数据的数据库通过倾倒和加载只是cms_ *表从任何环境开发完成。
 
 
 
祝你好运！
 
I am looking setting up a deployment process for a highly customized Magento site, and was wondering how other people do this. 

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.

Specifically,


How do you apply Magento upgrades? (Individually in each env, or on dev then roll out, or just give up on upgrades?)
What files/folders do leave alone in each environment (e.g. magento/app/etc/local.xml)
Do you restrict developers to editing specific files/folders?
Do you restrict theme designers to editing specific files/folders?
How do you manage database changes?




Theme Designer Files/Folders

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 Developer Files/Folders

Extension developers can edit the following folders/files-
/app/code/local
/app/etc/modules/<Namespace>_<Module>.xml




Database environment management

As the store's base URL is stored in the database, you cannot just copy databases between environments. Options include-


Overriding the base url in php. Blog
article on setting up dev and staging
databases
Changing the base url in the database after copying. (Where is this stored?)
Doing a MySQLDump or backup, then doing a replace on the URL in the SQL file.

解决方案
I recommend using git over SVN. Easier branching and merging means that all of these points will go more smoothly for you.

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.

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
and so on.

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.

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);
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.

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.

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.

Good luck!

                        
这篇关于Magento部署的最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！