localhost + staging +生产环境?

时间:2010-12-29 03:36:38

标签: php svn development-environment production-environment

我有一个网站说www.livesite.com,目前正在运行。我一直在我的本地机器上使用http://localhost开发一个新版本的网站,然后将我的更改与svn一起提交到www.testsite.com,我将在livesite.com服务器上测试该网站,但在另一个域下(它与现场网站的环境相同,但在不同的域下)。

现在我准备将新版本发布到livesite.com。第一次这样做很容易,我可以复制&将所有内容从testsite.com粘贴到livesite.com(不确定它是最好的方法)。

我想将testsite.com作为测试网站,我会推送更新,测试它们,并且一旦满意转移到livesite.com但我不确定在新网站推出后如何做到这一点..我不知道认为复制粘贴整个目录是正确的方法,它将打破livesite.com上当前用户的操作。

我还想在testsite.com上保留我的svn历史记录。使用SVN执行此操作的正确方法是什么?非常感谢你!

3 个答案:

答案 0 :(得分:5)

提到Hudson或Weploy的其他答案都很好。它们涵盖的问题多于以下问题。也就是说,以下可能就足够了。

如果你觉得这有点过分,那么这就是穷人用SVN和一点点创意系统管理的方式。

使您的自豪文档根目录为符号链接,而不是实际目录。意思是你有这样的东西:

/var/www/myproject-1-0-0
/var/www/myproject-1-1-0
/var/www/myproject-1-1-1
/var/www/html -> myproject-1-1-1

这意味着您可以将代码签出到生产中(例如,myproject-1-1-2),而不会覆盖正在提供的内容。然后,您可以通过执行以下操作立即切换代码库:

$ rm html && ln -s myproject-1-1-2 html

我还建议你不要在生产箱上对你的主干进行svn checkout / svn导出。相反,提前创建一个分支(将其命名为myproject-X-Y-Z)。这样,如果您需要对生产代码进行一些非常紧张的调整,您可以将其提交回分支,并在火灾消失后将其合并回主干)

我做了很多,而且效果很好。但是,它有一些主要的缺点:

主要是,您必须自己处理数据库迁移或其他升级脚本。如果您有脚本(普通旧SQL或更复杂的东西),您需要考虑如何最好地执行它们。希望停机只需一分钟也许不是一个坏主意。您可以在(/ var / www / mainenance)周围保留一个“维护站点”,如果需要,可以将符号链接指向那里一段时间。

例如,这种方法并不像Weploy那样酷,但是对于相对较小的项目(在单个服务器上运行,数据库不是很大),它通常足够好,而且很简单。

答案 1 :(得分:2)

我的回答会让事情变得复杂一点,但这里有:

我希望这种情况使用 Hudson

Hudson将允许您进行自动部署 / 清除当前目录 / 从svn 进程添加新内容。然后,您可以担心开发,而不是担心从一个地方到另一个地方的混乱和部署。

需要注意的是,您需要了解如何设置Hudson以及如何让为您工作。

如何开始使用PHP for Hudson

我认为这应该让你走上正轨,像我说的那样做一些工作,但稍后会有回报。

答案 2 :(得分:1)

如果只有服务器端代码发生变化,您可以简单地复制代码,一切都会好的。但即使在那里,你也必须考虑到人们在中间互动中的可能性。如果客户端代码发生更改,特别是如果您大量使用ajax,则必须让当前用户重新加载其页面。如果数据库也发生了更改,那么您可以确保在应用数据库更改脚本期间不会发生任何数据库事务。

在所有情况下,无论您是否使用任何持续集成工具,我认为最安全的做法是停机以应用这些更改。人们在其网站上贴上“测试版”标签的原因之一是,他们可以将所有人都关闭并将其全部关闭以应用更改,恕不另行通知。只要他们不经常这样做,他们也可以侥幸逃脱。一旦您退出测试阶段,应用更改将成为一个仪式,您可以提前几周宣布停机时间,然后获得30分钟到几个小时的窗口以应用所有更改。

对于修补操作系统或系统软件中的安全漏洞,添加硬件等基础问题,如果存在负载平衡,可以避免停机,并逐个应用补丁。