使用 SVN 管理发布的正确方法是什么？答案

【问题标题】：What's the right way to manage a release with SVN?使用 SVN 管理发布的正确方法是什么？
【发布时间】：2010-12-12 18:57:25
【问题描述】：

我的上一位雇主开发了一个精心设计的系统，该系统位于 SVN 之上以处理正在进行的开发：（变更管理）在通过标记进行提交时查看错误/问题并将它们与提交相关联SVN 中的错误 ID 编号和（发布管理）标记项，作为基于错误/问题跟踪系统的特定版本的一部分。第二部分有一个与之相关的工作流程，以从用户/管理层获得批准。然后，到了发布的时间（通常是每个星期四晚上），他们可以运行一个命令来检查所有标记的代码并进行部署。

我的新公司要小得多，我有兴趣找到一个低成本/低维护的等价物，即使这只是意味着直接与 SVN 打交道。特别是，我经常发现在游戏后期提交会破坏我们的构建，并且很难理清我们可以包含的内容。（就管理 SVN 而言，我更喜欢标签的想法而不是分支的想法，因为它不需要预先考虑，但我很高兴被说服。）

人们使用什么来标记发布的提交并进行后续部署？是否有任何好的开源解决方案来管理发布周期，允许您从 Web 浏览器浏览 SVN 并标记问题/提交以进行发布？到目前为止我看到的最好的东西是Jira，但这看起来是一个非常大的工具（很难配置/维护吗？）。 Apache 基金会为此目的充分利用了 Jira（例如，参见 the Mahout roadmap）。

更进一步的做法是让同一系统也包含持续集成，以便我们的单元测试可以在每次提交时运行，然后每个错误/问题也将关联这些信息。

注意：stackoverflow 上有一些稍微相关的问题，但我没有看到任何涉及部署周期和发布管理这方面的内容（请参阅release-management-in-svn、manage-your-project-life-cycle 和 best-way-to-handle-change-management）。

【问题讨论】：

标签： svn deployment release-management change-management

【解决方案1】：

您研究过 Tortoise SVN 修订图吗？如果您标记每个版本（正如其他人指出的那样，这不涉及在服务器或工作站上复制文件），那么您可以按时间顺序查看所有修订，标签指示实际版本。您可以通过突出显示您感兴趣的两个修订并从上下文菜单中选择差异来区分版本和/或主干

【讨论】：

【解决方案2】：

如果您在游戏中发现构建破坏签入太晚而无法有效修复它们，那么您绝对应该在开始担心发布过程之前跳上 CI 火车。让开发人员对构建的完整性负责是一个更容易的过程，因为每次有人检查某些东西时都会发出电子邮件，这会搞砸狗。让它成为一个游戏；破坏构建的人必须照看它，直到下一次破坏为止。

使用 CruiseControl 启动和运行（我使用 CC.NET）对 subversion 来说并不难（我让我们在大约一个月内从没有构建过程到使用 CC.NET 和 NAnt 完全自动化构建和部署），当然还有其他职责）。

我们也使用 JIRA，在那里很难出错。您可以让 JIRA 监视诸如“Fixed PROJECT-11”之类的颠覆提交消息，它会自动关闭相应的 JIRA 项目。您可以从那里构建您的发行说明。

【讨论】：