版本控制的生产环境
我的问题是，如何更好地对生产环境进行版本控制？
这是我们当前的环境：（
- 内部服务器）开发 - 版本控制源代码
- （客户服务器）验收测试环境
- （客户服务器）登台环境
- （客户服务器）生产环境
当我们发布用于验收测试的新功能时，我们会在 Visual 中发布Studio，压缩更改并将其应用到测试服务器上。 在那里，我们创建一个备份文件夹（以便我们可以恢复更改），并创建一个发布文件夹，以便我们可以在这些更改获得批准后将其移至暂存。
创建备份文件夹、发布文件夹、重新创建目录结构并尝试跟踪哪个版本包含哪些功能，需要大量的体力劳动。 这是乏味的，而且总是存在一些开发人员不遵循发布程序的问题。
理论上我可以为测试环境创建一个存储库。 （忘记源代码，这是关于已发布的应用程序）在每个版本中，开发人员都会进行提交并提供有关他所发布的功能的评论。
当功能应从测试转移到暂存时，我们会导出自上次更新暂存环境以来所做的更改，并将它们复制到暂存应用程序中。 在那里我们进行了一次提交，稍后可以将其提取以发布到生产环境。
这样做的缺点是使用 subversion 会使应用程序与这些 .svn 目录变得混乱。 这可以通过禁止访问 IIS 或 web.config 中的这些目录来修复。 另一种解决方案是在应用程序根目录上方的目录中使用 Git。 但对于没有经验的开发人员来说，在 Windows 环境中使用 Git 比较困难。
有人有这个问题的经验吗？ 如何对生产环境进行版本控制？ 如果您需要恢复某个版本，您是否有在该版本之前创建的备份文件夹？
我已经与我们的开发人员讨论过这个问题，他们看不出使用 subversion 进行测试/登台/生产环境的版本控制和备份有任何问题。 恰恰相反，他们会很高兴不在每次需要发布新功能时都创建发布/备份文件夹。
同时也存在一些不安全感。 以前没有人听说过这一点，将应用程序放在版本控制系统中，我们不确定会有什么缺点。
如果您有过这样的经历，我很高兴听到。
米凯尔伦丁
My question is, how do I version control the production environment in a good way?
This is our current environment:
- (Internal server) Development - Version controlled source code
- (Customer server) Acceptance test environment
- (Customer server) Staging environment
- (Customer server) Production environment
When we release new functionality for acceptance testing, we make a publish in Visual Studio, zip up the changes and apply them on the Test Server. There we make a backup folder (so that we can revert the changes) and we make a release folder so that we can move these changes to Staging when they're approved.
This is a lot of manual labour creating backup folders, release folders, recreating the directory structure and try to track what functionality that goes into what release. It is teadious and there is always problem with some developer not following the release procedure.
In theory I could make a repository for the test environment. (forget source code, this is about the published application) On every release the developer do a commit and supply a comment about the functionality he's releasing.
When functionality should be moved from Test to Staging we export changes made from the last date Staging environment was updated and copy them into the Staging application. There we do a commit that later can be extracted for release to Production environment.
The drawbacks of this is that using subversion will clutter the application with those .svn directories. This may be mended by disallowing access to those directories in the IIS or web.config. Another solution would be using Git on the directory above the root directory of the application. But Git is harder to work with for an unexperienced developer in a windows environment.
Does anyone have experience of this problem? How do you version control your production environment? What if you need to revert a release, do you have a backup folder that you created before the release?
I've discussed this with our developers, and they can't see any problem with using subversion for versioning and backup of the test/staging/production environment. Quite the opposite would they be happy not to create release/backup folders every time they need to release new functionality.
At the same time there is some insecurity about this. None have heard of this before, having the application in a version control system and we are unsure what the drawbacks would be.
If you have experience of a scenario like this, I would be happy to hear about it.
Mikael Lundin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我一直在使用 mercurial (Hg) 作为生产版本控制系统。
（不是代码，而是实际部署的二进制文件）。
这效果很好。
Subversion 不太适合在我的场景中使用，因为我确实希望能够将生产更改（例如配置文件）同步回测试甚至开发。 subversion 更难在不同存储库之间同步/合并（大量手动应对）。
通过 hg 标签和 hg 更新，可以轻松恢复到稳定（或不稳定）标签。
哦，我完全同意，你应该使用构建服务器（cruisecontrol.net）或其他东西，并将所有东西也保留在那里。
我的场景还不够，因为客户生产系统的配置是特定于自定义的，即使进行了广泛的测试，也可能存在某些配置在两个版本（或传入的版本）之间不再执行相同的操作数据发生显着变化）
I been using mercurial (Hg) as a production version control system.
(Not the code, but the actually deployed binaries).
That works quite well.
Subversion isn't quite right to use in my scenario because I do want to be able to sync production changes (such as config files) back to testing and maybe even development. subversion is harder to sync/merge between different repositories ( a lot of manually coping).
And with hg tag and hg update there is a breeze to revert to a stable (or unstable) tag.
Oh, and I totaly agree, you should use a buildserver (cruisecontrol.net) or something and keep all your things there as well.
I my scenario that isn't enough because the config of a customers production system is, well, custom specific, and even with extensive testing and what not there can be some config that no longer do the same thing between two releases (or the incoming data has significantly changed)
我们使用 subversion 作为将东西部署到不同服务器（prod、demo、dev 等）的一种方式，并且没有遇到任何困难。 唯一需要注意的是数据库差异和配置文件差异。 配置文件可以模板化，以免覆盖每个不同部署中的文件，但是您不会获得针对特定平台的更改的这些版本。
有了这种系统，您可以利用 subversion 的标签轻松更新/回滚到特定的部署版本。
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.
感谢您的回答和建议。
我发现我需要重新考虑我们处理这些环境的发布的方式。 拥有一个包含所有发布版本的构建服务器可以解决部分问题。 我将获得源代码的提交评论，并更好地控制哪些功能进入哪些构建。 我仍然需要跟踪构建在什么环境中，以便在出现问题时能够恢复版本。
@琼克
我将看一下 Mercurial。 如果您有一个构建系统，其中每个版本都有版本控制的源代码，那么版本控制的生产环境可能有点过分了。 但如果在部署新功能期间出现任何问题，我仍然希望有一种快速方法将更改恢复到以前的版本。 我也喜欢在服务器上获取版本控制配置文件的方式，因为生产环境始终具有与开发环境不同的配置。
也许我正在寻找灵丹妙药:)
Thank you for your answers and suggestions.
I see that I need to rethink the way we handle releases to these environments. Having a build server with all the releases ever made could solve a part of the problem. I will get the commit comments on the source code, and much better control of what feature goes into what build. I still need to keep track on what build is in what environment to be able to revert a release if something went wrong.
@Jonke
I will take a look at Mercurial. Maybe a version controlled production environment is overkill if you have a build system where each revision has version controlled source code. But I would still like to have a fast way to revert changes to a previous revision if anything goes wrong during deployment of new functionality. I also like the way you get version controlled configuration files on the server, since production environment always have different configuration from the development environment.
Maybe I'm looking for the silver bullet :)
另一种方法是使用构建服务器。 每次您签入代码时，构建服务器都会在开发环境中构建并打包新的构建。 然后使用您的代码签入可部署包。
然后，您可以将打包的构建部署到其他环境。 这样您就不必在那里备份版本，因为您的主存储库中已经拥有所有构建的版本。 如果您确保部署完全自动化并且可以通过一个命令（powershell？）完成，则无需再在服务器上保留备份。
这实际上比您提出的解决方案更好且更易于维护。 由于构建的每个版本都与代码一起保存，因此您始终可以找到适用于任何构建包的完整开发环境。 如果您单独对服务器进行版本控制，并且在某处发现错误，则可能很难找到导致该错误的代码版本。
Another way to do things would be to use a build server. Every time you check in code the build server builds and packages up the new build inside the development environment. Then checks in the deployable package with your code.
You can then deploy the packaged build to the other environments. This way you don't have to back up the versions there because you already have all the built versions in your main repository. If you make sure deployment is fully automated and can be done with one command (powershell?) there's no need to keep backups on the servers anymore.
This is actually better and more maintainable than the solution you propose. Because every version of the build is kept alongside the code you can always find a complete development environment for any build package. If you version-control your servers separately and you find a bug somewhere it can be hard to find the version of the code that causes the bug.