在同一构建期间为 Tomcat 创建和部署特定于环境的战争构建答案

【问题标题】：Create and deploy environment-specific war builds for Tomcat during same build在同一构建期间为 Tomcat 创建和部署特定于环境的战争构建
【发布时间】：2010-07-13 17:12:05
【问题描述】：

我希望能够构建一个战争文件并将其部署在多个环境中。我知道我可以创建一个 ant 任务来获取环境并在战争中包含文件，或者根据需要替换令牌。但是，这会导致与环境（dev、QA、DR、prod 等）一样多的不同战争文件。似乎这会创建一个从未经过测试的生产战争文件。是的，只有特定于环境的属性应该更改，但如果出现问题，则无法仅在 dev 中部署该 war 文件。

有没有一种简单的方法可以创建一个 war 文件并将所有配置文件设为外部文件？我应该在 startup.sh 脚本中设置位置吗？这似乎需要更改代码才能从该外部位置获取文件，而且我不确定这将如何与某些特定于框架的项目（如数据库配置）一起使用。目前，我使用 dev 配置创建了一个 war 文件，然后我将它部署到每个环境以便它被分解，然后我运行一个脚本来复制环境特定的属性文件，然后重新启动 tomcat 使这些属性生效，但这不会t 似乎是一个很好的解决方案。

我需要的属性文件是数据库配置、特定于应用程序的属性（例如邮件服务器的位置）以及 log4j.properties。

我将这些部署在运行 Tomcat 的 Linux 服务器上，并且我拥有对服务器的完全访问权限，因此我可以创建任何我需要的 ant、bash 等脚本。

【问题讨论】：

我也有同样的问题，我同意大卫的观点。不同环境下的不同战争不是解决办法。每次构建战争时，jar 等文件的 md5sum 都会不同。如果您在 prod 构建而不是测试战中遇到问题，您将遇到问题。一定有更好的方法。

标签： tomcat ant build build-process environment-variables

【解决方案1】：

您可以做的一件事是将 JNDI 用于数据源之类的事情，这样您的应用程序就可以从容器中获取资源。但该解决方案不适用于所有已配置的内容。

总的来说，我认为为每个环境创建一个战争/耳朵是“正常”的做法。我不同意您的说法，即您正在“部署一个从未经过测试的战争文件”。您正在部署未测试配置的战争文件更准确。也许您可以编写一些单元测试来验证生产配置并在构建产品战时运行它们，这样您就可以检查您的“测试产品战”要求...

【讨论】：