SVN 中的代码冻结 - 构建管理

Posted

技术标签:

【中文标题】SVN 中的代码冻结 - 构建管理【英文标题】:Code freeze in SVN - Build management 【发布时间】:2009-01-07 03:53:13 【问题描述】:

有没有比要求所有开发人员不要签入任何新代码更好的方法在 SVN 中实现代码冻结? 我们正在运行 CruiseControl,它会自动将最新的构建部署到环境中。因此,如果有新代码出现,之前可用的构建将更改为最新的。我希望部署的构建是来自特定分支/标签的构建,这样任何新的代码签入都不会影响已部署的构建。只有当我下次标记/分支时,才应该再次部署新代码。 我们怎样才能做到这一点?

【问题讨论】:

【参考方案1】:

使用 SVN 内置的 branching 功能。以下链接向您展示了有关如何分支的所有详细信息(如果您愿意,也可以使用标签):http://svnbook.red-bean.com/en/1.1/ch04.html

【讨论】:

没错。只需将“冻结”修订版分支为标签,然后构建/发布标签副本而不是主干副本。 可以配置 CruiseControl 来构建标签副本吗? @Akshay:应该可以。更糟糕的是,当您进行 SVN 结帐时,只需抓住正确的分支。 @Stephane 据我了解,Cruise Control 会查找任何代码更改,一旦发生任何更改,它将创建一个新版本。所以早期的构建将丢失。 Cruise Control 有什么方法可以在分支/标签上构建,以便较早的构建是最新的? 只要确保 CC 标记了每个构建。那么你就可以得到你想要的确切配置了。【参考方案2】:

你所说的颠覆惯例是创建一个标签。当然,标签与分支没有什么不同,因为它只是某个版本的某个开发线的副本(通常......有复杂的标签)。然而,颠覆的最佳实践是标签被创建一次并且永远不会被提交——它们只是快照。

所以我的建议是在您想要冻结的修订版上标记您的构建,与您的所有开发人员沟通,不要对该标签进行任何提交(如果他们还不知道的话),然后从您发布的那个标签。如果有人承诺标签,请举起神圣的地狱。

【讨论】:

【参考方案3】:

如果您更愿意强制执行,您可以通过 pre-commit 挂钩脚本禁用任何提交。由于历史原因,我们保留了一些停放的存储库,因此不需要新的提交。这就是我们冻结这些存储库的方式。

#!/bin/sh exit 1

它们仍然可以被访问和签出,但是所有新的提交都会失败。因此,在您的情况下,您可以有一个进程在构建过程的时间表上锁定 repo。

【讨论】:

【参考方案4】:

当然,访问机制也有阻塞——例如调整 authz 文件。

【讨论】:

【参考方案5】:

使用稳定的分支和 Subversion >=1.5(服务器、存储库格式和客户端)。

从 Trunk 创建一个分支并将其指定为您的稳定分支。禁止您的开发人员提交到此分支,最好使用您可用的任何权限的 authz 文件。

制定一项政策,确保在部署之前将任何代码更改提交到 Trunk,即使这些更改源自单独的分支。

有巡航控制手表,从指定的稳定分支而不是主干构建和部署。

在部署新软件时,使用 subversion 的合并功能从主干合并到分支中。始终以这种方式合并,仅从主干合并,合并跟踪(仅 1.5 及更高版本)将确保您可以从主干中挑选并仅包含您想要的更改,同时排除您不想要的内容。它还可以让您直观地检查当前版本包含哪些修订版以及排除哪些修订版。

一旦您合并并检查了结果,提交代码将导致 Cruise Control 发布 - 因此发布只发生在受控点。

如果您需要回滚到以前的版本,请从您的稳定分支的所需修订版中创建一个标签,并在您解决稳定分支上的问题后临时将 Cruise Control 指向该版本而不是您的稳定分支,然后你可以再次从 stable 分支部署,而不是标签。

您可能希望在问题发生之前主动制作标签,可能会自动使用 CruiseControl,以便在您需要切换时标签已经到位。

除了修复合并冲突或合并来自主干以外位置的更改之外,不要在 stable 分支上进行任何开发 - 将很难准确判断部署了什么。

【讨论】:

以上是关于SVN 中的代码冻结 - 构建管理的主要内容,如果未能解决你的问题,请参考以下文章

jenkins+svn+maven+tomcat一键构建部署

jenkins+svn+maven+tomcat一键构建部署

SVN源代码管理规范

如何通过svn,git进行优雅的代码集成

Apache+SVN构建代码仓库平台

淘淘商城maven工程的创建和svn的上传实现