2

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

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

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

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

我认为像这样的结构会好得多:

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

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

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

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

4

1 回答 1

1

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

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

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

于 2009-10-13T07:40:47.500 回答