Magento分期生产 [英] Magento staging and production
问题描述
任何人都可以提供一些很好的流程 - 到目前为止，我只是导出/导入开发数据库，复制源文件，清除测试订单，客户然后更改基本URL，htaccess文件等。
这似乎有点凌乱，容易出错。任何更有经验的Magento开发人员都可以为他们可以共享的这个任务有一个良好的过程。
我的进程通常围绕源代码管理库（在我的例子中是SVN）进行管理，这使得事情变得更容易，真的...）这个想法是在repo中保持一切可能，并使用SVN更新和标签来发布更改。
local.xml ：我将SVN中的文件移动到 local.xml.dist 并忽略repo中的实际 local.xml 文件。这使您可以在安装时使用不同的数据库凭据和主机，而不会污染代码库。
其他忽略：查看此问题更多的数据库中应忽略的文件。基本上，环境特有的任何东西都应该保留在版本控制之外，并在实际的主机上处理。您的 .htaccess 文件将在此处相关。
主机设置：我的登台环境并且dev环境设置为从存储库运行/ trunk。开发发生在这里，并可以通过 svn up 定期（或按需）推送到阶段，向客户端显示新功能并执行UAT。虽然生产环境需要一些来自主干野生西部的保护，从而使环境无法使用标签。每当一个功能集都准备好出去时，我会从中继线创建一个新的标签，并执行一个 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 export here ...
> rm www; ln -s /home/apacheuser/tag_1.0.2 www
这样，版本更改是即时的。 / p>
db从生产中恢复：为了让我能够处理production-ish数据，我有一个cron-job设置来转储生产数据库并将其导入分段。当这种情况发生时，该脚本将删除敏感的客户数据（并更改客户的电子邮件地址，以便所有的电子邮件发送给我）。它还会将信用卡网关设置更改为测试网关，然后更改 base_url 参数，以便分段站点URL正常工作。
新开发：您可能会注意到，不同的环境运行的大致相同的代码库（减去任何新的更改），这可能对您从数据库更改中所注意到的问题很麻烦等等。
管理这种复杂性（和正确的方式，同时！）的唯一方法是确保代码本身跟踪必要的更改环境。 Magento支持自动模块版本升级，包括应用于进行架构更改的数据库脚本等。这意味着，当您将新代码部署到临时/生产（或从您的开发环境中的其他开发人员处获取）时，所有数据库修补程序将自动应用。
这也意味着您需要将新功能写入尽可能无损的功能。 Magento主题，残障模块等可以用来实现这一点。例如，当为网站创建新主题时，请确保不修改任何核心行为，并将所有新资产保留在生成期间将不生效的主题，直到部署。
更多开发人员：此设置是基于项目中相对较少数量的开发人员。有一个隐含的假设，当你想标记一个新的版本时，你可以使中继线进入工作状态。随着更多的开发人员，这将越来越少，所以更复杂的备份设置是必要的。如果我遇到这种情况，我的计划是转移到使用git而不是SVN，并使用特征分支进行新的开发。
如果有的话不清楚，请告诉我。希望有帮助！
谢谢，
Joe
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屋！
