在生产服务器上管理演示/登台/现场之间的站点部署

Posted 2023-02-25

【中文标题】在生产服务器上管理演示/登台/现场之间的站点部署

【英文标题】：Managing site deployments between demo/staging/live on production servers

【发布时间】：2010-12-04 23:26:49

【问题描述】：

我们目前管理站点推出到服务器然后在演示/acc/live“模式”之间切换站点的方式有点随意，我希望改进整个过程。

我一直在审查自动部署工具，以及服务器的结构方式。我将把自动化部署问题留到另一篇文章中，在这里我对人们如何在生产服务器上组织代码感兴趣。

我们目前在数据驱动器上有 3 个***文件夹，“demo”、“acceptance”和“live”。将某些东西归类为“演示”或“acc”之间存在细微差别，我不会进入，足以说明我想摆脱所有争论/歧义。

我们的推出程序如下，一旦网站开发完成，在“acceptance”文件夹下的“acceptance”主机标题下推出它，例如acceptance.project-domain.com。客户审查网站，我们对其进行测试以确保所有连接字符串/权限等都是正确的。客户同意上线。此时，我们完全重新推出“live”文件夹下的站点，并为其提供 live 主机头。当然，此时站点在其部署状态下完全未经测试（这里不讨论单元测试，我的意思是文件权限、iis 设置错误等）。然后必须重新测试该网站:(

我认为像这样的结构会更好：

/<customer>/<project>/<fullversion>/wwwroot

这样，一个新站点可以部署到“acc”主机标题下的version1 文件夹。如果客户同意，您只需切换标题即可。如果有更改请求，他们会进入v1.1 下，它可以有接受标头，一旦确定，交换标头就可以了。冲洗并重复。

对于自动部署脚本，此过程也更容易管理。将站点的所有代码放在单个父文件夹下意味着上传权限可以限制在单个站点，因此您不会意外覆盖另一个站点的代码，更容易跟踪服务器上的版本，项目管理 wiki 可以轻松维护...不胜枚举！

您的代码组织和部署管理方法是什么？

【参考方案1】：

大多数人不会按照您建议的方式操作，因为他们使用单独的服务器进行测试和直播。

我们已经从我们的项目中剥离了所有配置，因此我们可以将完全相同的代码部署到测试和实时机器上，它们会自动选择正确的配置。这可以防止出现意外的“哎呀，我指的是测试而不是实时”的时刻。

您的想法可能会奏效 - 但如果您决定将来拆分服务器怎么办（例如，如果它可能会影响您的实时网站，您就不能完全对其进行性能测试）。