为什么不直接从git或bzr存储库部署代码？

Question

在开发/测试设置为Web应用程序，使用DVCS（BZR，GIT）时，为什么会是错误的实际运行从仓库目录的应用程序？

我遇到的所有团队都有一个单独的部署脚本，可以将存储库签出导出到另一个目录或服务器，但我真的从不明白原因，并且害怕要求“长大”不要显得“愚蠢”。我的意思是，无论如何，这是一个开发服务器，而不是产品，所以...？

Answer 1

为了澄清，这个问题是不是真正的如何部署，这完全是另外一个问题。更深层的原理是，由于@DaveE提到的原因，测试环境应尽可能接近生产：小的部署差异可能会使测试失效。

听起来真是你认为镜像制作安装为您的测试而开发的工作太多了。有两个解决方案。让您的测试环境与生产不同，不是其中之一。

首先，使生产更容易安装。这可能是一个手动过程（在这里复制文件，运行这些脚本，更改这些权限......）到一个自动化过程。或者它可能实际上减少了部署的功能。如果不知道细节，就不能多说。

如果您没有测试环境，您的开发环境会变为您的测试环境，并且必须遵守在生产之前作为您唯一防线的更严格规则。为了避免这种情况，请创建一个登台服务器进行测试。临时服务器是尽可能多地反映生产的服务器。开发副本首先安装在登台服务器上，并在推向生产之前进行测试。这给你一个两阶段测试系统。您可以在不太确切的开发环境中进行一些测试，并在分级环境中完成全部测试。完整的测试套件不必一直运行，因此登台服务器不必一直更新。因人而异。然后，您可以在开发环境中切入角落以加快开发速度，同时仍然知道在生产之前所有内容都将在完整安装中进行测试。

如果你有资源，一个临时服务器是所有生产的硬件和软件的完美的镜子。你可能没有，所以它可以是虚拟机或只是一个子目录。如果您没有从团队的其他成员那里购买，两者都可以在您的开发机器上运行。

自动执行安装过程加上临时服务器意味着您可以开始执行continuous integration testing。这是“在每次提交时自动在测试服务器上运行测试”的奇特术语。持续集成系统的一个例子是Jenkins。然后，无论您的部署有多复杂，机器人都会为您处理它。

因此，虽然起初它看起来像很多繁琐的工作，但它最终都会结合在一起，以便在没有按下按钮的情况下进行测试。

最终，您的新代码必须在被推送之前在类似于生产的环境中进行测试。有很多方法可以实现，但这是一个坚实的规则。

Answer 2

您是否希望看看路径和权限接近的运行时间，因为任何错误都可能反映真实情况，或者您是否愿意花时间运行古怪问题以解决问题标准部署特性？你知道，像

• 你是本地管理员，因此所有资源都提供给你，但是当 东西被部署在用户帐户是不是管理员，它 失败
• 路径克鲁夫特在本地而不是解决罚款部署 安装
• 是一个新的东西，并没有使之成为 [您|别人的]办理登机手续，所以“！它可以在我的机器”（TM）

或其他任何可减慢速度但无助于提供高质量代码的东西。

TL;博士：什么@Schwern下面说。