本地主机 +分期+生产环境？

发布于 2024-10-09 05:24:13 字数 524 浏览 3 评论 0原文

我有一个网站 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 执行此操作的正确方法是什么？太感谢了！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

千紇 2024-10-16 05:24:13

其他提到 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-XYZ）。这样，如果您需要对生产代码进行一些压力很大的调整，您可以将其提交回分支，并在火熄灭后将其合并回主干）

我经常这样做，而且效果很好。但是，它有一些主要缺点：

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

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

Other answers mentioning Hudson or Weploy are good. They cover more issues than what follows. That said, the following may be sufficient.

If you feel that's overkill, here's the poor-man's way of doing it with SVN and a little creative sysadminning.

Make your proudction document root a symlink, not an actual directory. Meaning you have something like this:

/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

This means you can check out code onto production (say, myproject-1-1-2) without overwriting stuff being served. Then you can switch codebases near-instantly by doing something like:

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

I'd further recommend not doing an svn checkout/svn export of your trunk on the production box. Instead, create a branch ahead of time (name it something like myproject-X-Y-Z). That way if you need to do some very stressful tweaking of production code, you can commit it back to the branch, and merge it back to trunk once the fire is extinguished)

I do this a lot, and it works quite well. However, it has some major drawbacks:

Mainly, you have to handle database migrations, or other upgrade scripts, all by yourself. If you have scripts (plain-old-SQL, or something more involved), you need to think about how best to execute them. Downtime of hopefully-just-a-minute might not be a bad idea. You could keep a "maintenance site" around (/var/www/mainenance), and point the symlink there for a few moments if you needed to.

This method is not nearly as cool as Weploy, for example, but for relatively small projects (running on a single server, with not-huge databases), it's often good enough, and dead simple.

回复收藏 0 原文

寂寞笑我太脆弱 2024-10-16 05:24:13

我的回答会让事情变得有点复杂，但这里是：

对于这种类型的场景，我会使用 Hudson。

Hudson 将允许您进行自动部署 / 清理当前目录 / 从 svn 添加新的进程。然后，您可以担心开发，而不必担心从一个地方到另一个地方的杂耍和部署。

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

如何开始使用 PHP for Hudson

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

回复收藏 0 原文

提笔落墨 2024-10-16 05:24:13

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

在所有情况下，无论您是否使用任何持续集成工具，我相信通过停机来应用这些更改是最安全的。人们在网站上贴上“测试版”标签的原因之一是，他们可以注销所有人并将他们全部拒之门外以应用更改，恕不另行通知。只要他们不经常这样做，他们也可以逃脱惩罚。一旦退出测试版，应用更改就变成了一种仪式，您提前几周开始宣布停机，然后获得 30 分钟到几个小时的时间来应用所有更改。

对于底层的事情，例如修补操作系统或系统软件的安全漏洞、添加硬件等，如果有负载平衡，就可以避免停机，并且补丁会一一打上。

回复收藏 0 原文

~没有更多了~