管理生产服务器上演示/暂存/实时之间的站点部署
我们目前管理站点部署到服务器，然后在演示/acc/实时“模式”之间切换站点的方式有点偶然，我希望改进整个过程。
我一直在审查自动化部署工具，以及服务器的结构方式。我将把自动化部署问题保存到另一篇文章中，在这里我对人们如何在生产服务器上组织代码感兴趣。
目前，我们的数据驱动器上有 3 个顶级文件夹：“demo”、“acceptance”和“live”。将某些东西分类为“演示”或“acc”之间存在细微的差异，我不会深入讨论，足以说明我想消除所有争论/歧义。
我们的推出过程如下，一旦开发了站点，就将其推出到“acceptance”主机标头下，例如“acceptance”文件夹下的acceptance.project-domain.com。客户审查该网站，我们对其进行测试以确保所有连接字符串/权限等均正确。客户同意上线。此时，我们完全重新推出“live”文件夹下的站点，并为其提供 live 主机标头。当然，此时该站点在部署状态下完全未经测试（这里不是谈论单元测试，我的意思是文件权限、iis 设置错误等）。然后必须重新测试该站点:(
我认为类似这样的结构会更好：
/<customer>/<project>/<fullversion>/wwwroot
这样，可以将新站点推出到“acc”下的 version1 文件夹中如果客户端给出“确定”，您只需切换标头即可离开。如果有更改请求，它们将进入可以包含接受标头的 v1.1 下。好的，交换标头就可以了，
对于自动部署脚本来说，此过程也更容易管理，这意味着可以将上传权限限制在单个站点。 ，这样您就不会意外地覆盖另一个站点的代码，跟踪服务器上的版本要容易得多，项目管理维基可以轻松维护......
您的代码组织方法是什么 ？推出管理？
The way we currently manage site roll outs to the server and then switching sites between demo/acc/live "mode" is a bit hap-hazard and i'm looking to improve the whole process.
I've been reviewing automated deployment tools, but also the way the server is structured. I'll save the automated deployment questions for another post, here i'm interested in how people organise code on their production servers.
We currently have 3 top level folders on the data drive, "demo", "acceptance" and "live". There's tenuous differences between what classifies something as "demo" or "acc" which i won't go into, suffice to say i want to be rid of all argument/ambiguity.
Our rollout procedure is as follows, once a site is developed, roll it out under an "acceptance" host header such as acceptance.project-domain.com under the "acceptance" folder. The client reviews the site, we give it a test to make sure all connection strings/permissions etc are correct. The client gives the OK to go live. At this point, we completely re-roll out the site under the "live" folder and give it the live host header. of course at this point the site is totally untested in its deployed state (not talking about unit tests here, i mean file permissions, iis setup mistakes etc). The site then has to be re-tested :(
I think a structure something like this, would be much better:
/<customer>/<project>/<fullversion>/wwwroot
This way, a new site can be rolled out to a version1 folder under an "acc" host header. If the client gives the OK, you simply switch the headers and youre away. If there are change requsts, they go under a v1.1 which can have the acceptance header, once it gets the ok, swap the headers and youre good. Rinse and repeat.
This process would also be much easier to manage for an automated deployment script. Having all the code for a site under a single parent folder means upload permissions can be restricted to a single site, so you cant accidentally overwrite another site's code, its much easier to keep a track of what versions there are on the server, the project management wiki can easily be maintained... the list goes on!
What are your methods of code organisation and rollout management?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
大多数人不会按照您建议的方式进行操作，因为他们使用单独的服务器进行测试和实时运行。
我们已经从项目中剥离了所有配置，因此我们可以将完全相同的代码部署到测试机器和实时机器上，它们将自动选择正确的配置。这可以防止意外的“哎呀我指的是测试而不是实时”时刻。
您的想法可能很有效 - 但如果您决定将来拆分服务器怎么办（例如，如果它可能会影响您的实时网站，您就无法对其进行性能测试）。
Most people don't operate in the way you've proposed because they use separate servers for test and live.
We have stripped all configuration out of our projects, so we can deploy exactly the same code to the test and live machines and they will automatically pick up the correct config. This prevents unexpected "oops I'm pointing at test instead of live" moments.
Your idea may well work - but what if you do decide to split your servers up in the future (you can't exactly run performance testing against it if it could potentially impact your live websites for example).