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