2

我的问题是，如何以一种好的方式对生产环境进行版本控制？

这是我们当前的环境：

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

当我们发布验收测试的新功能时，我们会在 Visual Studio 中发布，压缩更改并将它们应用到测试服务器上。在那里，我们创建了一个备份文件夹（以便我们可以恢复更改）并创建一个发布文件夹，以便我们可以在这些更改被批准后将它们移动到 Staging。

这是创建备份文件夹、发布文件夹、重新创建目录结构并尝试跟踪哪些功能进入哪个版本的大量体力劳动。这很乏味，并且某些开发人员不遵循发布程序总是存在问题。

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

当功能应该从 Test 移动到 Staging 时，我们会导出从上次更新 Staging 环境时所做的更改，并将它们复制到 Staging 应用程序中。在那里我们做了一个提交，稍后可以提取它以发布到生产环境。

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

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

我已经与我们的开发人员讨论过这个问题，他们认为使用 subversion 进行版本控制和备份测试/登台/生产环境有任何问题。恰恰相反，他们会乐于在每次需要发布新功能时不创建发布/备份文件夹。

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

如果你有这样的场景经验，我会很高兴听到它。

迈克尔·伦丁

4

4 回答 4

2

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

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

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

于 2008-11-05T08:45:23.017 回答
1

We use subversion as a way to deploy things to our different servers(prod, demo, dev, etc.) and have not run into any difficulties. The only things to watch out for are database differences and config file differences. The config files can be templatized, so as not to overwrite the files in each different deployment, but then you don't get those versioned for the changes to that specific platform.

With this sort of a system, you can make use of subversion's tags to update/roll back to specific deployment versions easily.

于 2009-02-26T23:04:46.170 回答
1

我一直使用mercurial (Hg) 作为生产版本控制系统。（不是代码，而是实际部署的二进制文件）。这工作得很好。Subversion 不太适合在我的场景中使用，因为我确实希望能够将生产更改（例如配置文件）同步回测试甚至开发。颠覆更难在不同的存储库之间同步/合并（很多手动应对）。并且使用 hg tag 和 hg update 可以轻而易举地恢复到稳定（或不稳定）的标签。

哦，我完全同意，您应该使用 buildserver (cruisecontrol.net) 或其他东西，并将所有东西也保留在那里。我的场景还不够，因为客户生产系统的配置是自定义特定的，即使经过广泛的测试，也可能有一些配置在两个版本之间不再做同样的事情（或传入数据发生了显着变化）

于 2008-11-05T08:43:07.157 回答
0

感谢您的回答和建议。

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

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

也许我正在寻找灵丹妙药:)

于 2008-11-11T08:05:40.757 回答