版本控制的生产环境

Question

我的问题是，如何以良好的方式版本控制生产环境？

这是我们目前的环境：

• （内部服务器）开发 - 版本控制源代码
• （客户服务器）验收测试环境
• （客户服务器）临时环境
• （客户服务器）生产环境

当我们发布接受新功能ance测试，我们在Visual Studio中进行发布，压缩更改并将其应用到测试服务器上。在那里，我们创建了一个备份文件夹（以便我们可以恢复更改），并制作发布文件夹，以便我们在批准时将这些更改移至暂存。

这是大量的手工劳动创建备份文件夹，释放文件夹，重新创建目录结构，并尝试跟踪什么功能进入什么版本。这是很费时的，并且一些开发者没有遵循释放过程总是有问题。

---

在理论上我可以让测试环境的存储库。 （忘记源代码，这是关于已发布的应用程序）在每个版本中，开发人员都会进行提交并提供有关他正在发布的功能的评论。

当功能应从测试移动到分段时，我们导出从上次更新分段环境进行更新并将其复制到分段应用程序中。在那里我们做了一个提交，稍后可以将其提交到生产环境。

这样做的缺点是使用Subversion会使应用程序与这些.svn目录混乱。这可以通过禁止访问IIS或web.config中的这些目录来修补。另一种解决方案是在应用程序根目录上的目录中使用Git。但Git很难与Windows环境中的无经验的开发人员一起工作。

有没有人有这个问题的经验？您如何版本控制您的生产环境？如果您需要恢复发行版，那么您是否有发布之前创建的备份文件夹？

我已经与我们的开发人员讨论过这个问题，他们看不到使用Subversion进行测试/临时/生产环境的版本控制和备份的任何问题。相反，他们会很高兴不要在每次需要发布新功能时都创建发布/备份文件夹。

同时对此也有一些不安全感。之前没有人听说过这个，在版本控制系统中有应用，我们不确定会有什么缺点。

如果您有这种情况的经验，我很乐意听到它。

的Mikael伦丁

Answer 1

我已经使用mercurial（汞柱）作为生产版本控制系统。 （不是代码，但实际部署的二进制文件）。 这工作得很好。 Subversion在我的场景中使用不太正确，因为我确实希望能够将生产更改（如配置文件）同步回测试甚至是开发。颠覆很难在不同的仓库之间同步/合并（大量的手动应对）。 与hg标签和hg更新有一个微风恢复到稳定（或不稳定）的标签。

哦，我完全同意，你应该使用buildserver（cruisecontrol.net）或其他东西，并保留所有的东西。 我的情况是不够的，因为客户生产系统的配置是自定义特定的，甚至是广泛的测试，什么不可能有一些配置不再在两个版本之间做同样的事情（或传入的数据已经发生了很大的变化）

Answer 2

另一种做事的方法是使用构建服务器。每次检入代码时，构建服务器都会在开发环境中构建并打包新构建。然后用代码检查可部署的程序包。

然后，您可以将打包的版本部署到其他环境。这样，您不必在那里备份版本，因为您已经拥有主存储库中的所有内置版本。如果确保部署完全自动化并且可以使用一个命令（powershell？）完成，则不需要在服务器上保留备份。

这实际上比您提出的解决方案更好，更易维护。因为构建的每个版本都与代码一起保存，所以您始终可以为任何构建包找到完整的开发环境。如果您单独版本控制您的服务器，并且在某处发现错误，则很难找到导致该错误的代码版本。

Answer 3

谢谢你的回答和建议。

我看到我需要重新考虑处理这些环境的发布方式。拥有所有版本的构建服务器可以解决问题的一部分。我将得到关于源代码的提交评论，并更好地控制什么功能进入什么构建。我仍然需要跟踪在什么环境下什么样的版本能够在出现问题时恢复发布。

@Jonke 我会看看Mercurial。如果您有一个构建系统，其中每个版本都有版本控制的源代码，那么版本控制的生产环境可能会过度杀伤。但是，如果在部署新功能期间出现任何问题，我仍然希望能够快速恢复到之前版本的更改。我还喜欢在服务器上获得版本控制配置文件的方式，因为生产环境始终与开发环境具有不同的配置。

也许我寻找的银弹:)

Answer 4

我们用颠覆的方式来部署的事情对我们的不同的服务器（产品，演示，开发等），并没有遇到任何困难。唯一需要注意的是数据库差异和配置文件差异。配置文件可以进行模板化，以免覆盖每个不同部署中的文件，但是您没有获得针对该特定平台更改的版本。

通过这种系统，您可以使用subversion的标签轻松更新/回滚到特定的部署版本。