问题标签 [release-management]

有没有办法在 Tomcat 服务器上部署给定的战争文件？我想在不使用 Web 界面的情况下执行此操作。

我有许多在 Linux/PHP 网站的幕后运行的批处理过程。它们的数量和复杂性开始增长，所以我想对它们进行少量处理。

我的源代码树有一堆 cpp 文件和脚本，以开发而非部署为目的进行组织。编译完所有可执行文件后，我需要将各种脚本和二进制文件放在一组机器上。不同的机器的批处理需要不同的可执行文件、脚本和配置文件。我还编写了一些属于每台机器的工具。目前，此部署过程是手动的且容易出错。

我猜我最终会得到一个脚本，该脚本在源代码树的根部运行，并为任何机器所需的一切构建一个较小的树。然后，我将把它同步到适当的机器上。但我很好奇其他人是如何处理这类问题的。有任何想法吗？

我应该在为 CommonUtils 等常见项目发布版本时包含依赖项，还是应该简单地指定在使用它们时应该引用哪些依赖项？

我有一个适用于 EJB 的 java 应用程序，但是如果：

1. EJB 得到更新，应用程序损坏。
2. 应用服务器已更新，应用已损坏。

在没有人工参与的情况下，是否有一种首选方法来更新应用服务器和 bean 的客户端 jar？

如果首选方法取决于应用服务器，则假设为 jboss。

我希望重新组织我们发布内部软件的方式。所有代码（PHP webapps、一些 Java 应用程序和 Perl 脚本）都检入 Subversion 存储库，但没有分支或标签，所有代码都检入主干（每个应用程序只有大约 1-3 个开发人员）。在生产 linux 服务器上，该软件只是直接从一个工作 svn 副本运行（实际上大部分更改也发生在那里）。

由于我们有很多小应用程序并且经常对正在运行的系统发布小的更改，我正在寻找一种非常精简或透明的方式来进行一些发布工程并清理这些混乱。

是否有任何工具可以帮助我在这样的异构环境（语言方面）中这样做？或者有谁知道如何以正确的方式做到这一点？

否则我会考虑编写一些发布（shell）脚本，自动从主干创建颠覆标签，然后将相应的标签签出到生产服务器。但这对我来说听起来也有点骇人听闻。

谢谢，

海斯。

我正在开发一个用于其他应用程序的库，并且由于 NLog，这个库有很多调试和日志记录语句。

切换到发布模式时是否可以排除对 NLog.dll 的引用？

干杯，

我public/files通过 Web 界面不断地将文件上传到 Rails 应用程序的文件夹。

我不想将这些文件保存在源代码管理中，因为它们占用了将近 2 GB，所以每次我这样做时，cap deploy它都会将这些文件保存在其中，releases/并用存储在存储库中的原始副本替换目录。

我想知道将这些文件保存在服务器current目录中的最佳方法是什么。我的一些想法是：

• 从源代码管理中删除目录并将其替换为指向不受 Capistrano 管理的外部目录的链接。
• 创建 Capistrano 任务以在部署前将目录复制到 /tmp，然后在部署完成后将其复制回 /public。

有标准的方法来做到这一点吗？

大多数时候，我看到发布管理作为一个已定义的过程处理，支持工具作为版本控制系统（通常通过分支和标记）。但是，有没有专门用于发布管理的工具？我正在寻找开源和闭源工具，如果有的话。

有没有人有关于提前发布/经常发布商业软件的经验/例子？它有效吗？

我在考虑 VMware，他们在每个主要版本之间都有很多修订版本。而且安装体验很糟糕，有时它们会破坏现有的虚拟机，有时客户操作系统中的 VMware Tools 会出现故障/无法安装。这太可怕了。

我也在考虑 ClickOnce 部署，因为当您更新软件时，使用 ClickOnce，所有客户端都会自动收到发布通知，并且只需单击一下，它们就会更新到新版本。如果您的软件有错误，那么它们也会自动“升级”以获取这些错误。

您是否有将提前发布/经常发布原则应用于商业软件的经验\示例\建议？

我想把它应用到一个。

我用过直接的 Mongrel，我用过 Apache 后面的 Mongrel 集群，我看过 Thin，我对Passenger 很感兴趣。我也看过 Nginx。我看过 MRI、Ruby Enterprise Edition、Rubinius 和 JRuby。有很多选择，每个都声称是新的圣杯。

对于全新的、完全最新的部署，最好的选择是什么？唯一的假设是：

• 该应用程序基于 Rails 2.2。（我知道 2.2 还没有完全发布，但是这个部署也没有。）
• 服务器是基于 Linux 的。可能是 Ubuntu Hardy，但实际上，在这种情况下效果最好。
• Rails 需要功能齐全，并且可能与 MySQL 数据库通信。
• 其他一切都可以商量。

考虑到这些特别广泛的限制，在并发性和低开销方面，哪种软件组合将产生最佳结果？

我倾向于使用“worker”mpm 和Passenger + Ruby Enterprise Edition 的Apache，仅仅是因为它提供了即时的稳定性以及设置和维护的简单性。

我可能会因为另一种选择而变得特别好？