我希望重新组织我们发布内部软件的方式。所有代码（PHP webapps、一些 Java 应用程序和 Perl 脚本）都被检入 Subversion 存储库，但没有分支或标签，一切都被检入主干（每个应用程序只有大约 1-3 个开发人员）。在生产 linux 服务器上，该软件只是直接从一个工作 svn 副本运行（实际上大部分更改也发生在那里）。
由于我们有很多小应用程序并且经常发布对运行系统的小改动，我正在寻找一种非常精简或透明的方式来进行一些发布工程并清理这些混乱。
是否有任何工具可以帮助我在这样的异构环境（语言方面）中做到这一点？ 或者有谁知道如何以正确的方式做到这一点？
否则我会考虑编写一些发布（shell）脚本，这些脚本会自动从主干创建颠覆标签，然后将相应的标签签出到生产服务器。但这对我来说听起来也有点骇人听闻。
谢谢，
哈斯。
【问题讨论】：
标签： linux svn release-management
持续集成绝对是必经之路 - 任何 CI（甚至是极简批处理文件）都比没有好 - 但它只会与您现有的策略一样好。由于您的文件最终并没有真正成为“二进制”或“可分发”，因此标记发布可能只需要您标记存储库，或者甚至只是将 Subversion 修订号存储在某个地方。您需要的重要策略是任何版本都可以在您需要时重新构建 - 这样您就可以比较当前和以前的版本，或者在出现问题时返回旧版本。不用担心在 svn 中创建标签的“开销”——这非常有效。
执行 subversion 标签的发布脚本听起来不错。 CI 实现（我推荐 CruiseControl，因为它非常适合异构工作，尽管异构需要更多的配置开销）很棒，因为您可以在 subversion checkin 时自动启动该过程，并运行自动化测试来确定它是否好是否足以标记。
我绝对不会自动部署到发布服务器。一个“暂存区”（称之为“夜间构建”、“beta 测试”等等）会更好。在您决定将其推广到生产服务器上之前，让您的用户大吃一惊。而且，只要您制定了能够回滚到较早版本的策略，就可以降低错误推出的可能性。
生产服务器上的自动结帐是唯一的“hackish”部分 - 自动结帐、测试、标记、测试版部署已经足够巧妙了。不过，推广到生产环境应该不是一个简单的按钮。
【讨论】：
使用标签和分支；使其成为开发周期的一部分。当您更新“stable-1.0”分支，测试更改并将其标记为“release-1.0.5”时，您只需在服务器上执行“svn switch”到新标签。试过了还是不行？切换回来，找出问题所在。
但请注意，在 subversion 中进行分支可能会很痛苦，至少在 1.5 之前的版本中是这样。如果您或您的开发人员没有使用分支的经验，那么一开始可能会遇到一些麻烦和/或错误。但只要你已经提交，就不会丢失任何代码（最坏的情况是难以合并）。
您的开发人员确实应该学习如何使用分支；它可用于多种用途（不仅仅是用于发布工程）。
不要自动切换生产服务器上的代码；有人可能不小心按错了按钮。生产更新应始终小心谨慎。添加新标签的脚本，恕我直言，由于它的简单性，它是不必要的，但你的里程可能会有所不同。
最后一件事，不要让任何人对您的生产服务器进行更改。它可能会导致冲突，而这些往往需要时间来解决。更不用说，它会破坏您在不同工作站上重现给定版本的能力（在这里工作正常！为什么不在服务器上？嗯）。
【讨论】：
一些持续集成服务器会做这种事情，例如Hudson，具有颠覆集成。它可以为您标记、运行测试和部署。
【讨论】：
我会使用 Hudson。除了从 svn (ref sblundy) 中获取和标记之外，它还可以用于使用正确的 plugins 进行发布管理。 f.ex.，您可以尝试 a plugin to "promote" 部署到生产环境的构建，并保留提升的构建本身的列表以及各种版本的更改/提交日志。
【讨论】：