问题标签 [release-management]

不久前，我们使用 Microsoft VSS 作为我们的版本控制工具，并用于在每个版本结束后创建我们的代码分支并将其部署到我们的客户。

现在我们已经转移到 SVN 并且最近有很多关于标签/分支的讨论，我们应该在开发特定版本之后标记/分支我们的代码吗？

SVN 实际上为此目的推荐了“标签”，但也建议不要进一步对其进行任何更改，那么我们将在哪里修复此版本中出现的令人发指的错误？

正在做的另一件事是创建标签和分支，将标签部署到客户端，如果出现任何错误，将对分支进行修复，然后再次标记:-(

其他人做什么？

我有一个生产系统，其中有多个服务器担任多个角色。我想通过部署到该特定服务器来测试新的应用服务器，而不必重新部署到生产中的每个服务器。有没有办法让 Capistrano 部署到特定的服务器？理想情况下，我希望能够运行类似的东西

如果我只想部署到 app2.example.com。

谢谢！

[更新]我通过执行尝试了wulong建议的解决方案：

但 capistrano 似乎试图在该服务器上执行除应用程序任务之外的其他角色的任务。也许我需要更新我的 cap 版本（我正在运行 v2.2.0）？

我很想知道术语 alpha、beta 和 RC1 是在整个软件行业中使用的术语，还是只是 MS。

定义是什么？

马尔科姆

发布托管 Web 应用程序新版本的最佳方法是什么？您通常多久发布一次？您是否选择任意日期，例如每周、每月等来推出一组累积的修复（可能使用类似于Joel 的发货日期方法）？等待比这更长的时间似乎破坏了托管应用程序的部分主要优势。另一方面，您不希望不断推出可能使用户感到困惑的新功能（即，如果他/她每次登录时都有不同的东西）。

直到最近，我的经验主要是安装基于服务器或桌面应用程序。我很想知道人们在托管应用程序中使用什么类型的发布管理。

我总是通过 FTP（有时甚至是 xcopy）部署我的 Web 应用程序，然后自己手动运行数据库脚本。

我在 90 年代开始以这种方式部署，但最近，我看到了一些带有安装程序的 Web 应用程序。我开始质疑，如果我被锁定在一个过时的过程中。我是一名顾问，我的应用程序通常是内部的，所以我不担心分发和让其他人安装它们。

但我很好奇；是否有人创建安装程序来部署内部 asp.net Web 应用程序？

如果是这样，为什么？（自愿、强制或自动化过程的一部分）

你这样做有什么问题吗？

根据我的经验，我们在 web 开发过程中遇到的一个更大的问题是在不同的服务器上保持不同的设置更新和安全。

我的公司拥有自己的 CMS，目前安装在 100 多台服务器上。目前，我们使用基于 FTP 的黑客方法，结合特定位置的升级脚本来升级我们所有的 CMS 设置。当涉及多个自定义模块时，有效管理这些设置变得越来越困难和风险。

• 保持 Web 应用程序的多个设置安全和最新的最佳方法是什么？
• 你是怎么做到的？
• 是否有任何关于应用程序模块化的具体技巧，以保持对我们客户的灵活性，但仍然能够有效地管理应用程序的多个“分支”？

一些上下文信息：我们主要在 LAMP 堆栈上开发。帮助我们销售 CMS 的主要因素之一是我们几乎可以插入客户想要的任何东西。这可以是 10 到 10.000 行自定义代码。

许多定制工作由非常小的代码组成；在 Subversion 中管理所有这些小段代码对我来说似乎相当乏味和低效（因为我们每周交付大约 2 个网站，这会导致很多分支）。

如果有什么我忽略了，我很想听听你的意见。

提前致谢。

综述：首先，感谢您的所有回答。所有这些都非常有帮助。

我很可能会使用基于 SVN 的方法，这使得benlumley的解决方案最接近我将使用的解决方案。由于这个问题的答案在其他用例中可能会有所不同，因此我将在运行结束时接受得票最多的答案。

请检查答案并投票给您认为具有最大附加值的答案。

我们有一个非常酷的小型 Web 框架，我们已在数十个客户项目中成功使用它。我们计划将此软件发布到社区。但是，我正在为新的开源软件项目页面上应该/不应该做什么而绞尽脑汁。网站必须具备的东西是什么？文档？一个维基？有下载链接吗？还有什么？

而且，一个相关但可能不同的问题是我们如何开始标记版本号。我们在内部使用的只是 SVN 标记。有没有一种好方法来确定何时开始调用 0.9 版本与 1.0 和 1.1 等等？

当我查看 SVN 日志时，我真的希望我能看到告诉我发布何时完成的标记。我在 PVCS 和Perforce等其他版本控制系统中看到了这一点。

这可以在SVN中完成吗？我做了一些研究，到目前为止，似乎不支持这种事情。

编辑

我们不希望每次发布都将源代码复制到不同的文件夹中。这会导致开发人员机器上出现大量不必要的文件重复， 并且只为我们提供了每个版本的修订号的记录。我可以使用文本文档来做到这一点！

编辑2

我的目标是有一个单一的视图来显示我的版本的年表，在这之间我可以看到每个版本之间发生的所有代码更改。这样就可以更轻松地编译发行说明。

我有配置文件和各种文档，我想使用 Maven2 从开发环境复制到 dev-server 目录。奇怪的是，Maven 似乎不擅长这项任务。

一些选项：

• 在 Maven 中简单使用复制任务

• 使用 Ant 插件从 Ant 执行复制。

  • 构造一个zip类型的工件，以及通常是jar类型的 POM 的“主”工件，然后将该工件从存储库解压缩到目标目录中。

  • maven-resources插件，如下所述。

  • Maven Assembly 插件——但这似乎需要大量手动定义，当我想简单而“传统地”做事时。

  • 这个页面甚至展示了如何构建一个插件来进行复制！

  • maven-upload插件，如下所述。

  • maven-dependency-plugin和copy，如下所述。

所有这些似乎都是不必要的临时性：Maven 应该擅长于完成这些标准任务而无需大惊小怪。

有什么建议吗？

我想知道这一点，因为我刚刚意识到，我以前从未与提供过候选版本的公司打交道，而且我看到这些天越来越多地使用这个词，所以我想更清楚地了解他们影响。

对于以前为提供 RC 的公司实际工作过的任何人……是否有任何更正式的规范来说明候选版本的实际需要（例如 RC 和 Beta 之间的区别），或者它只是一个政策每个公司自己决定的事情？

如果您碰巧在一家拥有此类规范的公司工作，您能否提供一些示例，说明它所阅读的某些指南确实将版本提升为“候选发布版”。