版本控制生产环境

Question

我的问题是，如何更好地控制生产环境？

这是我们目前的环境：

• (内部服务器)开发-版本控制源代码
• (客户服务器)验收测试环境
• (客户服务器)暂存环境
• (客户服务器)生产环境

当我们发布用于验收测试的新功能时，我们在Visual中发布，压缩这些更改并将它们应用到testing上。在那里，我们创建了一个备份文件夹(这样我们就可以恢复更改)，并且我们创建了一个发布文件夹，这样我们就可以在它们被批准时将这些更改移到暂存状态。

这是很多手工劳动--创建备份文件夹、释放文件夹、重新创建目录结构，并试图跟踪哪些功能进入了什么版本。这是一个棘手的问题，有些开发人员不遵循发布过程总是会有问题。

理论上，我可以为测试环境创建一个存储库。(忘了源代码，这是关于已发布的应用程序的)在每次发布时，开发人员都会提交并提供关于他正在发布的功能的评论。

当功能从Test移到暂存时，我们导出从上次日期开始的更改，更新了暂存环境，并将它们复制到暂存应用程序中。在这里，我们做了一个提交，以后可以提取出来，以便发布到生产环境中。

这样做的缺点是，使用subversion会使应用程序与那些.svn目录混淆。可以通过不允许访问IIS或web.config中的这些目录来解决这一问题。另一种解决方案是在应用程序根目录上方的目录上使用Git。但是对于一个没有经验的开发人员来说，在windows环境下使用Git要困难得多。

有人对这个问题有经验吗？如何控制您的生产环境？如果您需要还原一个版本，那么在发布之前创建的备份文件夹呢？

我已经与我们的开发人员讨论过这一点，他们认为使用subversion对测试/阶段/生产环境的版本控制和备份没有任何问题。相反，每当他们需要发布新功能时，他们都不愿意创建发布/备份文件夹。

同时，这方面也存在一些不安全因素。以前没有人听说过这一点，在版本控制系统中有应用程序，我们不知道会有什么缺点。

如果你有这种情况的经验，我会很高兴听到它。

米克尔·隆丁

Answer 1

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

然后，可以将打包的构建部署到其他环境中。这样，您就不必在那里备份版本，因为您已经在主存储库中拥有了所有构建的版本。如果您确保部署是完全自动化的，并且可以使用一个命令(powershell?)没有必要在服务器上保留备份了。

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

Answer 2

我一直使用汞 (Hg)作为生产版本控制系统。(不是代码，而是实际部署的二进制文件)。效果很好。在我的场景中使用Subversion是不太正确的，因为我确实希望能够同步生产更改(例如配置文件)，回到测试，甚至可能是开发。subversion很难在不同的存储库之间同步/合并(很多手工处理)。使用hg标记和hg更新，可以轻松地恢复到稳定(或不稳定)标记。

哦，我完全同意，你应该使用一个构建服务器( buildserver，cruisecontrol.net)或者什么的，并且把你所有的东西都保存在那里。我的方案还不够，因为客户生产系统的配置是特定于客户的，而且即使进行了广泛的测试，也可能有一些配置在两个版本之间不再做相同的事情(或者传入的数据已经发生了很大的变化)。

Answer 3

我们使用subversion作为将东西部署到不同服务器(prod、demo、dev等)的方法。也没有遇到任何困难。唯一需要注意的是数据库差异和配置文件差异。可以对配置文件进行模板化，这样就不会在每个不同的部署中覆盖这些文件，但是这样就不会对特定平台的更改进行版本化。

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