我的问题是，如何以良好的方式对生产环境进行版本控制？
这是我们目前的环境：
当我们发布验证测试的新功能时，我们在Visual Studio中进行发布，压缩更改并将它们应用于测试服务器。在那里我们创建了一个备份文件夹（以便我们可以恢复更改）并创建一个发布文件夹，以便我们可以在批准后将这些更改移动到暂存。
这是创建备份文件夹，发布文件夹，重新创建目录结构以及尝试跟踪哪些功能进入哪个版本的手工劳动。它很乏味，并且一些开发人员不遵循发布过程总会出现问题。
理论上，我可以为测试环境建立一个存储库。 （忘记源代码，这是关于已发布的应用程序）在每个版本中，开发人员都会提交并提供有关他正在发布的功能的评论。
当应将功能从Test移至Staging时，我们会导出从上次更新Staging环境所做的更改，并将它们复制到Staging应用程序中。我们在那里进行提交，以后可以提取以便发布到生产环境。
这样做的缺点是使用subversion会使应用程序与那些.svn目录混乱。这可以通过禁止访问IIS或web.config中的那些目录来修复。另一种解决方案是在应用程序根目录上方的目录上使用Git。但是对于Windows环境中没有经验的开发人员来说，Git更难与之合作。
有没有人有这方面的经验？您如何控制生产环境的版本？如果您需要恢复发布，如果您有一个在发布之前创建的备份文件夹，该怎么办？
我与我们的开发人员讨论过这个问题，他们看不到使用subversion进行版本控制和测试/登台/生产环境备份的任何问题。恰恰相反，他们很乐意每次需要发布新功能时都不创建发布/备份文件夹。
与此同时，对此存在一些不安全因素。之前没有人听说过这个，将应用程序放在版本控制系统中，我们不确定会有什么缺点。
如果你有这样的情景经验，我会很高兴听到它。
Mikael Lundin
答案 0 :(得分：2)
另一种方法是使用构建服务器。每次签入代码时，构建服务器都会在开发环境中构建并打包新构建。然后使用您的代码检查可部署包。
然后，您可以将打包的构建部署到其他环境。这样您就不必备份那里的版本，因为您已经在主存储库中拥有所有构建的版本。如果确保部署完全自动化并且可以使用一个命令（powershell？）完成，则无需再在服务器上保留备份。
这实际上比您提出的解决方案更好，更易于维护。因为构建的每个版本都与代码一起保存，所以您始终可以为任何构建包找到完整的开发环境。如果您单独对版本控制服务器并且在某处发现错误，则很难找到导致该错误的代码版本。
答案 1 :(得分：1)
我一直使用mercurial（Hg）作为生产版本控制系统。 （不是代码，而是实际部署的二进制文件）。 这非常有效。 Subversion在我的场景中使用不太正确，因为我确实希望能够将生产更改（例如配置文件）同步回测试甚至开发。 subversion很难在不同的存储库之间同步/合并（很多人工处理）。 使用hg标签和hg更新，可以轻松恢复到稳定（或不稳定）标签。
哦，我完全同意，你应该使用buildserver（cruisecontrol.net）或其他东西，并保留你所有的东西。 我的情况还不够，因为客户生产系统的配置是特定于自定义的，甚至还有大量的测试，而且在两个版本（或传入版本）之间不会有一些配置不再相同数据发生了重大变化）
答案 2 :(得分：1)
我们使用subversion作为将事物部署到不同服务器（prod，demo，dev等）的方法，并且没有遇到任何困难。唯一需要注意的是数据库差异和配置文件差异。配置文件可以进行模板化，以免覆盖每个不同部署中的文件，但是您不会为那个特定平台的更改获得版本。
使用这种系统，您可以使用subversion的标签轻松更新/回滚到特定的部署版本。
答案 3 :(得分：0)
感谢您的回答和建议。
我看到我需要重新思考我们处理这些环境的版本的方式。拥有一个包含所有版本的构建服务器可以解决部分问题。我将获得有关源代码的提交注释，并更好地控制什么功能进入什么版本。我仍然需要跟踪哪些构建在什么环境中能够在出现问题时还原版本。
@Jonke 我将看看Mercurial。如果你有一个构建系统，每个版本都有版本控制的源代码，那么版本控制的生产环境可能是过度的。但是，如果在部署新功能时出现任何问题，我仍然希望能够快速恢复以前版本的更改。我也喜欢在服务器上获得版本控制配置文件的方式，因为生产环境总是与开发环境有不同的配置。
也许我正在寻找银弹：）