Web开发不再像过去那样。它曾经包含了几个PHP脚本的黑客攻击（我没有反对PHP，实际上它是我目前的主要编程语言），通过FTP将它们上传到一些webhost就是这样。今天，事情变得更加复杂。正如我所看到的那样，通过查看一些专业和现代网站（SO是主要的网站，我认为这是Web开发中良好实践的一个很好的例子，即使它是用ASP.NET制作并托管在Windows上），开发一个网站远不止于此：
好的，这些是我的观察。现在我的问题：
我正在寻找一个新的网络项目：
我想要的是关于使用上述工具和上述问题的答案的最佳实践建议。
答案 0 :(得分：6)
你是对的，在尝试部署可扩展的网站时，事情会变得复杂。以下是我发现的一些好的指导方针（免责声明：我是铁路工程师）：
关于代码存储库的文件结构的大多数决策主要基于您选择实现的语言，框架和平台的约定。你提出的许多问题（JS，CSS，资产，生产与开发）都是用Rails处理的。但是，对于您想要使用的其他语言，这可能因PHP而异。我发现你应该对你选择使用哪种语言进行一些研究，并尝试找到适合该社区惯例的方法。当您稍后尝试寻找障碍物的帮助时，这将对您有所帮助。您的代码将像他们的代码一样进行组织，您将能够更轻松地获得答案。
我会控制版本不大的所有内容。我发现VC的唯一问题是你的repo变大了。除此之外，我从未后悔保留以前代码的版本。
对于部署到多个服务器，有许多脚本可以帮助您完成您需要执行的操作。对于Ruby / Rails，最广泛使用的工具是Capistrano。其他语言也有类似的资源。基本上你只需要配置你的服务器设置是什么样的，然后编写或查看一组脚本的开源，这些脚本可以将代码库部署/回滚/操作到你在配置文件中列出的服务器。
发展与生产是一个重要的区别。虽然您可以在没有这种区别的情况下运行，但是当您需要修补整个存储库中的代码时，它会变得很麻烦。如果我是你，我会编写一些代码，这些代码在每个请求开始时运行，确定您正在运行的环境。然后，在处理该请求时，您可以获得该知识。当您指定在连接到数据库时要使用的配置时，可以使用此信息，一直到只在开发时在浏览器中显示调试信息。它派上用场。
RESTful通常会决定您的网站设计的大部分内容。尝试将代码保留在restful框架中可以帮助您记住代码所在的位置，保持路由可预测性，防止代码过于耦合，并遵循越来越被接受的约定。显然有其他惯例可以实现这些相同的目标，但我使用REST有很好的经验，并且它大大改善了我的代码。
所有这一切。我发现虽然你可以有良好的意图来创建一个可以无限扩展并且很好且干净的原始代码库，但很少有这种方式。如果我是你，我会做一些关于你感觉最舒服的东西以及有助于让你的生活更轻松的研究，并坚持下去。
希望这有帮助！
答案 1 :(得分：3)
虽然我没有使用你提到过的工具，除了MySQL，我可以为你发布的问题提供一些相当标准的答案。
1）取决于细节，但大多数情况下，你将它们保存在同一个存储库中，但是在一个单独的文件夹中。
2）仅仅因为某些东西被提交到存储库并不意味着它已经准备好上线 - 它通常是一个可能充满错误的中间构建。手动完成发布，从存储库导出。在与svn checkout相同的文件夹中设置web服务器是一个巨大的nono，因为.svn文件夹包含相当多的敏感信息，例如如何将更改推送到svn服务器。
3）您使用某种NAS或SAN解决方案，或者仅使用其中一台服务器上的网络共享，并从那里读取所有数据。这样，当您将信息推送到一个地方时，所有服务器都可以访问它。如果网络速度很慢，则可以设置脚本，从单个位置自动将文件推送到所有服务器。如果在ASP.NET中使用多服务器环境，请不要忘记更新配置文件中的计算机密钥，否则共享加密缓存（如viewstate）将无法跨服务器运行。在数据库中使用会话存储也是一个好主意。
4）我有一个post build步骤，只在发布时触发，用生成的数据库替换我的数据库连接字符串，并在发布的web.config / app.config文件中将我的Production app配置值从false更改为true 。我无法看到任何情况下您需要为服务相同内容的不同服务器提供不同的配置文件。
如果某些事情不清楚，请发表评论，我会尽力澄清。
祝你好运！ // Eric Johansson答案 2 :(得分：1)
我认为您正在混合两个不同方面，即源代码控制和部署。仅仅因为您在单个存储库中拥有所有文件并不意味着必须以这种方式部署它们。您是否应该直接使用源代码控制进行部署，或者使用可以处理任意数量配置的构建/部署脚本，这也是有争议的。
在高流量网站上，仅在单独的域上托管静态文件才真正值得。你确定你没有过早地进行优化吗？