使用TeamCity进行subversion发布管理

Question

我们目前使用Subversion进行发布管理,并标记我们的所有版本(包括QA和我们的生产服务器).但是,我们想要创建一个反映我们最新版本的单一版本目录.这样我们就可以让TeamCity从同一个文件夹中拉出来进行连续构建.此外,如果有人必须对生产进行快速错误修复,他们不会意外地将其转移到错误的分支.

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

澄清

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

• 今天,在TeamCity成功构建之后,我将我们的Web应用程序版本发布到QA.这样做时,我会分支/标记它
• 明天以后,开发者继续在后备箱中进行更新.在下一次QA发布之前,这些不会被推送到QA
• 星期三,我们的QA团队通知我们他们发现了一个错误.我们在QA分支上修复了错误,将更改合并回主干,并将更新的QA分支推回到QA.问题#1:TeamCity不再为我们工作,因为我们在一个QA分支机构
• 星期五,QA批准发布生产,因此我们发布和分支/标记
• 周一,客户打电话时需要对生产进行少量更改.我们在发布分支中进行更改并合并回主干.问题#2:我们再一次在没有TeamCity帮助我们的情况下做出改变

Answer 1

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

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

您真的不想最终直接对“Releases”文件夹进行代码更改 - 如果是主流开发，这就是主干的用途；如果您必须调整早期版本，则这就是分支的用途。这有点让 SVN 屈服，去做一些不是其核心优势的事情！在这方面，您可能会发现良好源代码控制管理的 10 条戒律中的一些提示很有用。