svn - 使用 TeamCity 进行 Subversion 发布管理

Question

我们目前使用 Subversion 进行发布管理，并标记我们所有的发布(包括 QA 和我们的生产服务器)。但是，我们希望创建一个反射(reflect)我们最新版本的单个 Release 目录。通过这种方式，我们可以让 TeamCity 始终从同一文件夹中提取以进行连续构建。此外，如果有人必须对生产进行快速错误修复，他们不会意外地将其转到错误的分支。

例如，下面是我们添加了“发布”文件夹的当前结构。是否有一种简单的方法可以每次将标记的分支移动到“发布”，或者甚至让“发布”成为指向最新 release_* 版本的链接？



澄清

以下是我们的构建/发布过程当前如何工作的示例:

今天，在 TeamCity 成功构建后，我向 QA 发布了一个版本的 Web 应用程序。这样做时，我会对其进行分支/标记

从明天开始，开发人员将继续在主干中进行更新。在下一个 QA 版本发布之前，这些不会被推送到 QA

周三，我们的 QA 团队通知我们他们发现了一个错误。我们对 QA 分支进行了错误修复，将更改合并回主干，并将更新后的 QA 分支推送回 QA。问题 #1:TeamCity 不再为我们工作，因为我们处于 #'d QA 分支

周五，QA 批准发布生产，所以我们发布和分支/标记

周一，一位客户打电话询问需要对生产进行小幅更改的问题。我们在发布分支中进行更改并合并回主干。问题#2:再一次，我们在没有 TeamCity 帮助的情况下进行更改

Answer 1

我会(并且会)对此采取稍微不同的方法。源代码控制管理主要是为了管理源代码并将其视为跟踪或暗示发布的一种手段，这会使生活变得有点棘手。这确实是您的持续集成环境的目的，它比 SVN 做得更好。

我使用 TeamCity 作为识别从 SVN 中提取的路径和修订号的方法。在构建运行时定义它很容易，任何发布到生产总是谨慎完成(即仔细检查路径和修订版)。在绝对最坏的情况下，如果你搞砸了，你总是可以使用修改后的参数重新运行构建。

您真的不希望最终直接对“Releases”文件夹进行代码更改 - 如果它是主流开发，这就是主干的用途，或者如果您必须调整较早的修订版，则这是分支的用途。做一些不是它的核心力量的事情，这有点像在说服 SVN 屈服!在这方面，您可能会在 The 10 commandments of good source control management 中找到一些提示。有用。