我们目前管理网站部署到服务器然后在demo / acc / live“模式”之间切换网站的方式有点危险，我希望改进整个过程。
我一直在审查自动部署工具，还有服务器结构的方式。我将为另一篇文章保存自动部署问题，这里我对人们如何在他们的生产服务器上组织代码感兴趣。
我们目前在数据驱动器上有3个顶级文件夹，“demo”，“accepted”和“live”。将某些内容归类为“demo”或“acc”的内容之间存在着微妙的差异，我不想进入，只需说我想摆脱所有争论/歧义。
我们的推出程序如下，一旦开发了网站，就在“接受”文件夹下的“接受”主机标题（如acceptance.project-domain.com）下滚动出来。客户端审查该网站，我们给它一个测试，以确保所有连接字符串/权限等是正确的。客户端可以上线。此时，我们完全重新推出“live”文件夹下的网站，并为其提供实时主机标头。当然，在这一点上，该网站在其部署状态下完全未经测试（不是在这里讨论单元测试，我的意思是文件权限，我设置错误等）。然后必须重新测试该网站:(
我认为像这样的结构会好得多：
/<customer>/<project>/<fullversion>/wwwroot
这样，可以将新网站推广到“acc”主机标题下的version1文件夹。如果客户端给出了OK，那么您只需切换标题即可。如果有更改请求，它们会在v1.1下进行接受标题，一旦得到确定，交换标题就可以了。冲洗并重复。
对于自动部署脚本，此过程也更容易管理。在单个父文件夹下拥有站点的所有代码意味着上传权限可以限制在单个站点，因此您无法意外覆盖其他站点的代码，更容易跟踪服务器上的版本，项目管理维基可以轻松维护......列表继续！
您的代码组织和部署管理方法是什么？
答案 0 :(得分：1)
大多数人不按照您提议的方式运营，因为他们使用单独的服务器进行测试和直播。
我们已经从项目中删除了所有配置，因此我们可以将完全相同的代码部署到测试和实时计算机，他们将自动获取正确的配置。这可以防止意外的“oops我指向测试而不是现场”。
您的想法可能会奏效 - 但如果您决定将来拆分服务器会怎么样（例如，如果它可能会影响您的实时网站，则无法完全针对它进行性能测试）。