在Web应用程序的开发/测试设置中，使用dvcs（bzr，git）为什么从存储库目录中实际运行应用程序是错误的？
我遇到的所有团队都有一个单独的部署脚本，可以将存储库签出导出到另一个目录或服务器，但我真的不明白为什么，并且害怕要求“长大”不要看起来“愚蠢”......我的意思是，无论如何它都是一个开发服务器，而不是生产，所以......？
答案 0 :(得分：4)
您是希望查看路径和权限接近的运行时，因为它们将是真实的，因此任何错误都可能反映现实，或者您是否愿意花时间运行将解决为非的奇怪问题标准部署的特质？你知道，比如
或任何其他一些减慢速度但无法提供高质量代码的东西。
tl;博士：@Schwern在下面说的是什么。
答案 1 :(得分：2)
要澄清一下，问题不在于如何部署，这是另一个问题。更深层的原则是，由于@DaveE提到的原因，您的测试环境应该尽可能接近生产：小的部署差异会使您的测试失效。
听起来您认为镜像生产安装对于开发时的测试来说太多了。有两个解决方案。让您的测试环境与生产不同不是其中之一。
首先，让生产安装更容易。这可能是一个手动过程（在这里复制文件，运行这些脚本，更改这些权限......）进入自动化过程。或者它实际上可以减少部署的作用。不知道细节就不能多说。
如果您没有测试环境，您的开发环境将成为您的测试环境，并且必须遵循更严格的规则，即在生产之前成为您唯一的防线。为避免这种情况，请创建要测试的登台服务器。登台服务器是尽可能多地镜像生产的服务器。开发副本首先安装在登台服务器上，然后在推送到生产环境之前进行测试。这为您提供了一个两阶段测试系统。您可以在不太精确的开发环境中进行一些测试，并在分段环境中完成全部测试。完整的测试套件不必一直运行，因此登台服务器不必经常更新。因人而异。然后，您可以在开发环境中进行切入点以加快开发速度，同时仍然知道在生产之前所有内容都将在完整安装中进行测试。
如果您拥有资源，登台服务器是生产中所有硬件和软件的完美镜像。您可能没有，因此它可以是虚拟机或只是子目录。如果您没有从团队的其他成员那里购买，两者都可以在您的开发机器上使用。
自动执行安装过程以及登台服务器意味着您可以开始执行continuous integration testing。这是“在每次提交时在测试服务器上自动运行测试”这个奇特的术语。持续集成系统的一个例子是Jenkins。然后，无论你的部署有多复杂，你的机器人都会为你处理它。
因此，虽然起初看起来好像很多繁琐的工作，但最终它们总结在一起，无需你按下按钮即可进行测试。
最终，您的新代码必须在推送前尽可能在与生产相似的环境中进行测试。有很多方法可以实现这一目标，但这是坚如磐石的规则。