Magento 分期和制作 [英] Magento staging and production
问题描述
我已经用 magento 开发了一段时间，事情开始变得有意义并且变得更加深思熟虑和有条理.一方面虽然看起来仍然很混乱 - 将站点从开发转移到生产.
任何人都可以为此提供一些好的流程 - 到目前为止，我一直只是导出/导入开发数据库，复制源文件，清除测试订单，客户等，然后更改基本网址，htaccess文件等.
这一切似乎有点混乱且容易出错.是否有经验丰富的 Magento 开发人员为他们可以共享的这项任务制定了良好的流程.
我的流程通常围绕源代码控制存储库(在我的情况下为 SVN)进行管理，这使事情变得更容易(或可能，真的......).这个想法是在 repo 中保留所有可能的东西，并使用 SVN 更新和标签来发布更改.
local.xml:我将 SVN 中的这个文件移动到 local.xml.dist 并忽略实际的 local.xml 文件中的回购.这让您可以在安装时使用不同的数据库凭据和主机，而不会污染代码库.
其他忽略:查看 这个问题 应该在数据库中被忽略的更多文件.基本上，环境特有的任何东西都应该不受版本控制并在实际主机上处理.您的 .htaccess 文件将与此处相关.
主机设置:我的临时环境和开发环境设置为从存储库中运行/trunk.开发在这里进行，并且可以通过 svn up 定期(或按需)推送到阶段，以向客户端显示新功能并执行 UAT.然而，生产环境需要一些保护，免受主干的狂野西部的影响，因此该环境会耗尽标签.每当功能集准备好推出时，我从主干创建一个新标签并执行 svn switch 以移动到新代码集.以这种方式做事也让我可以轻松撤消生产(切换回最后一个标签).因此，我从我的生活中删除了所有手动文件推送，这很好.
一个更好的系统(我还不需要)是使用 svn export 在生产系统上创建代码树的完整副本，并使用 ln 在它们之间切换.像这样:
>cd/home/apacheuser>ls -lwww ->/home/apacheuser/tag_1.0.1标签_1.0.1>svn 导出/url/for/repo/tags/1.0.2 tag_1.0.2... svn 在这里导出 ...>rm www;ln -s/home/apacheuser/tag_1.0.2 www这样，版本更改是即时的.
db 从生产同步返回:为了让我能够处理生产数据，我设置了一个 cron 作业来转储生产数据库并将其导入暂存.发生这种情况时，脚本将删除敏感的客户数据(并更改客户电子邮件地址，以便所有电子邮件都发送给我).它还会将信用卡网关设置更改为测试网关并更改 base_url 参数，以便临时站点 URL 正常工作.
新开发:您可能会在此处注意到不同的环境运行大致相同的代码库(减去任何新更改)，根据您注意到的有关数据库更改等的内容，这对您来说可能看起来很麻烦.
管理这种复杂性的唯一方法(同时也是正确的方法！)是确保代码本身跟踪对环境的必要更改.Magento 支持自动模块版本升级，包括数据库脚本，您应该使用它来进行架构更改等.这意味着，当您将新代码部署到暂存/生产(或从开发环境中的其他开发人员那里获得)时，所有数据库补丁都会自动应用.
这也意味着您需要编写尽可能无损的新功能.Magento 主题、禁用模块等可用于实现这一目标.例如，在为网站创建新主题时，请确保不要修改任何核心行为，并将所有新资产保存在一个主题中，该主题在部署之前在生产中是惰性的.
更多开发人员:此设置基于项目中相对较少的开发人员.有一个隐含的假设，当你想标记一个新版本时，你可以让主干进入工作状态来这样做.随着开发人员的增多，这种情况会越来越少，因此需要更复杂的 repo 设置.如果遇到这种情况，我的计划是改用 git 而不是 SVN，并使用功能分支进行新的开发.
<小时>如果有任何不清楚的地方，请告诉我.希望有帮助！
谢谢，乔
I have been developing with magento for a while now and things are starting to make sense and become much more deliberate and organised. One aspect though still seems quite messy - moving a site from development to production.
Can anyone offer some good processes for this - up to now I have simply been exporting/importing the the development database, copying source files over, clearing out test orders, customers etc then changing base urls, htaccess files etc.
It all seems a bit messy and error prone. Do any of the more experienced Magento developers have a good process in place for this task that they could share.
My process is usually managed around a source control repository (SVN in my case), which makes things much easier (or possible, really...). The idea is to keep everything possible in the repo and use SVN updates and tags to publish changes.
local.xml: I move this file in SVN to local.xml.dist and ignore the actual local.xml file in the repo. This lets you use different database credentials and hosts on your installations without polluting the codebase.
other ignores: Check out this question for more files that should be ignored in the database. Basically, anything unique to the environment should be kept out of version control and handled on the actual host. Your .htaccess files will be relevant here.
host setup: My staging environment and dev environments are set to run off of /trunk from the repository. Development occurs here, and can be pushed to stage periodically (or on demand) via svn up to show new features to the client and do UAT. The production environment needs some protection from the Wild West of trunk, though, so that environment runs off of tags. Whenever a feature set is ready to go out, I create a new tag from trunk and do an svn switch to move to the new code set. Doing things this way also gives me an easy undo for production (switch back to the last tag). Thus I have removed all manual file pushes from my life, which is good.
An even better system (which I've had no need for yet) would be to use svn export to create a complete copy of the code tree on the production system, and use ln to switch between them. Something like this:
> 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
That way, version changes are instantaneous.
db sync back from production: To allow me to work on production-ish data, I have a cron-job set up to dump the production database and import it into staging. While this is happening, the script will remove sensitive customer data (and change customer email addresses so that all emails go to me). It will also change credit card gateway settings to a test gateway and change the base_url parameters so that the staging site URLs work properly.
new development: You may notice here that different environments run off of roughly the same codebase (minus any new changes), which may seem troublesome to you from what you've noted about database changes etc.
The only way to manage this complexity (and the right way, at the same time!) is to make sure that the code itself keeps track of necessary changes to the environment. Magento supports automatic module version upgrades, including database scripts, which you should use to make schema changes, etc. This means that, as you deploy new code to staging/production (or as you get it from another developer in your dev environment), all database patches are applied automatically.
This also means that you need to write new functionality to be as non-destructive as possible. Magento themes, disabled modules and such can be used to make this a reality. For example, when creating a new theme for the site, make sure not to modify any of the core behavior, and keep all new assets in a theme that will be inert on production until deployed.
more developers: This setup is based around a relatively small number of developers on a project. There is an implicit assumption that, when you want to tag a new release, you can get trunk into a working state to do so. With more developers, this will be the case less and less, so a more complex repo setup is necessary. If I run into that, my plan is to move over to using git instead of SVN and to use feature branches for new development.
Let me know if any of that was unclear. Hope that helps!
Thanks, Joe
这篇关于Magento 分期和制作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
