版本控制和发布管理

Question

是否还有支持实际版本管理/部署的所谓“版本控制系统”？

我以前工作的大型机商店有一个自动发布管理工具，它不仅控制对源的并发修改，而且还负责运行编译器，预编译器，数据库绑定实用程序等等，使它成为我们的完全自动化的部署工具。

我的理解是“更现代”的版本控制工具仅支持源管理部分。这种理解是否正确？

Answer 1

版本控制与发布管理或部署几乎没有关系，因此VCS也不会尝试这样做。

我在这方面看到的是构建或Continuous Integration (CI) servers。这些会听取VCS中的更改，对任何提交进行新的检查，然后尝试构建所有内容。因此，他们集成了VCS和构建工具，从中收集日志并在一个漂亮的Web UI中显示所有内容。

这样，每个工具都可以保持简单。

[编辑]增加了CI服务器的价值：

1. 它可以分析构建脚本的输出，并在邮件或网页中显示概述。

2. 确保在提交后运行所有测试。不再“但它适合我”。

3. 其中一些支持延迟提交（它只会在所有测试运行时提交对VCS的更改）

4. 它可以在几个相互依赖的项目上运行构建。

Answer 2

这绝对不正确。任何现代版本控制工具都支持前提交和后提交挂钩，此时您可以运行任何所需的代码。

在subversion中，每次开发人员检查代码时，我们都会使用post-commit钩子将应用程序的副本部署到开发服务器。

在我们的实际生产服务器中，我们有代码验证然后部署稳定的次要版本标记，因为它们由发布经理提交给回购。

Answer 3

这取决于您希望在此类系统中投入多少金钱和时间。 很多人使用简单的版本控制 - 比如svn，并手动管理版本（使用标签和分支） 还有其他（免费）工具可以持续集成（不断构建应用程序），例如cruisecontrol。

在数据库领域，我对自由世界一无所知，但是有人可能会完成这个。所以到现在我手动管理数据库版本......

Answer 4

我认为你在这里所谓的发布管理通常被称为build automation。这个空间中有各种工具（make，ant，Nant等），但它们往往作为单独的工具存在。通常可以从单独的源代码控制中提取代码，并且您可以获得用于监视进程的产品（在自动完成时称为持续集成。）

有些供应商提供符合Application Lifecycle Management

标题的端到端工具

Answer 5

- ＆GT;我的理解是“更现代”的版本控制工具仅支持源管理部分。这种理解是否正确？

VCS只处理源代码管理部分，如果您无法获得有关更改的通知，那么毫无意义（在有人实现了vcs基础之后，提供此功能将毫无困难;-)）

- ＆GT;我曾经工作的大型机商店有一个自动发布管理工具，它不仅控制对源的并发修改，而且还负责运行编译器，预编译器，数据库绑定实用程序等，使其成为我们的全自动部署工具也是如此。

这称为构建自动化，是的，如果项目的最佳位在有人进行更改但没有必要时“准备发货”，这是非常理想的。您可以 使用前面提到的工具做任何你想做的事情（它们是可扩展的）。

持续集成实践是对这些点的插值 这样你在存储库中只有一个干净，稳定，高贵的代码。 有所谓的CI服务器连接VC和BA部分。

点击此页面查看CI http://martinfowler.com/articles/continuousIntegration.html

如果有人需要与许多BA工具和许多VCS兼容的CI服务器 看看JetBrains TeamCity

希望这会有所帮助

Answer 6

在ruby on rails世界中，Capistrano是首选的部署工具。

http://www.capify.org/index.php/Capistrano

Answer 7

我目前正在为发布管理开发一个Web应用程序，如果您想成为测试用户，请告诉我们。我有一个基本版本管理流程的工作版本，例如能够通过挑选您想要的更改来创建版本（同时自动处理依赖项更改），以及推出或回滚到发布历史记录中的任何点到许多不同的环境（测试或生产）服务器）。目前，它支持与SVN的集成。

请http://www.ngashint.com了解该项目的博客网站。你可以留下你的电子邮件开始接收测试版或给我发电子邮件kzt001 [at] gmail.com

Answer 8

由于

，这个问题引起了我的注意

  

'... 所谓的“版本控制系统”......'

问题中的

，并且由于问题被标记为version-control ...

我来自大型机世界（也是），大型机'SCM'（=软件变更管理）是我们过去25年左右所做的一切。

看到version-control标签的所有所谓的同义词，我有点惊讶（也许是“震惊”？）。特别是scm标签（我不确定SE过程建议不再将其视为同义词）。 SCM，至少在大型机领域，不仅仅是版本控制（这只是SCM的一部分）。那些与某些相关的主题（恕我直言，SCM的子功能）中的任何一个怎么样：

• 发布管理（原问题的一部分）。
• 部署过程（原始问题的一部分）。
• 影响分析。
• 审批工作流程。
• 值得信赖且可用的测试环境。
• 紧急程序，例如在非工作时间。
• 仅需几秒钟的自动回滚（退出）。
• 审计（治理流程）。
• ...（依次列出）。

为了说明所有这些问题的重要性，我经常会问这个问题：“应用（bug？）需要什么？ - 修复飞机上的自动驾驶软件......飞行！？！ ？”换句话说：“在您开始航班期间应用此类修补程序之前，必须采取的所有步骤和程序是什么？”。

根据之前提供的各种答案，我不确定（还有）其中哪一个（如果有的话）选择这种机上错误修正。