如何在构建服务器和开发人员的机器上使用不同的属性文件集？

Question

我有一个网络应用程序。我正在为它配置 CI。

我们没有使用构建工具（Ant 和 Maven 都没有），而是通过 IDE 进行构建。 现在我正在编写一个 Ant 脚本，我们的构建系统将使用它。

当项目在构建服务器上而不是在本地机器上构建时，有几个属性文件应该具有不同的属性值。

处理这种情况的常用方法是什么？

如果我们使用 Maven，我可能会使用不同的配置文件，但我们有 Ant。

我可以看到的一个可能的解决方案是为所有属性文件集创建一个根文件夹，并将每个集存储在一个单独的子文件夹中（参见下面的架构）。

/profiles
    /dev1
       prop1.properties
       prop2.properties
    /dev2
       prop1.properties
       prop2.properties
    /build-server
       prop1.properties
       prop2.properties
/webapp
    /WEB-INF

然后在 Ant 构建期间，我们可以将正确的集合复制到正确的位置。但是像我们以前那样通过 IDE 进行构建可能会出现问题（因为属性文件不再存储在 src 文件夹下的适当位置）。

还有其他方法吗？

Answer 1

如果我理解你的话，你会在你的持续构建服务器上为每个环境构建单独的 ear/war/jars。对吗？

我有两种处理方式：聪明的方式和愚蠢的方式：

智能方式

明智的方法是配置您的应用服务器（JBoss、Weblogic 等）以查找安装在应用服务器中的 jar/ear/wars 外部所需的属性文件。这样，您构建了一组 jar/ear/wars，它可以在任何地方工作。另外，你做了一件非常非常重要的事情：你让Finger O' Blame指向别处。

如果属性文件被打包为 jar/ear/war 的一部分，并且服务器上的某些内容发生了更改，那么您将受到指责，因为您的构建错误。当然，您无法知道他们更改了环境，但您确实在生产服务器上安装了那个错误的构建文件。

但是，如果属性存储在构建工件之外，那么有问题的是负责配置服务器的团队。

实际上，负责配置应用程序服务器的团队处理问题要容易得多。他们知道发生了什么变化，并且可以更新属性文件以反映该变化。不仅如此，您只需构建和分发一组工件。您不必担心是否设置了新环境，或者旧环境中的某些内容是否发生了变化。事实上，无需强制您发布新版本即可轻松进行更改。

---

笨方法

在我上一家公司时，我们能够以 Smart Way 的方式做事。在我现在的公司，我们以愚蠢的方式做事。这些属性嵌入在我们的构建工件中，没有简单的方法可以更改它。

我按后缀而不是不同的目录（即 build.properties.dev1、build.properties.dev2 等）划分了每组属性文件。我们将属性文件放在一个目录中。

当我进行构建时，我使用AntContrib<for> 任务多次循环构建过程，每次使用不同的属性文件。然后，我为每组属性文件构建一个工件。我将属性文件上的后缀用作存储构建工件的target 目录中的文件夹名称。这样，每次构建都会为所有环境生成所有工件。

这样，如果工件在 dev 环境中工作，它将在 QA 和 Production 中工作。唯一的问题是我在 Jenkins 服务器上存储的工件数量是 5 到 10 倍，所以我需要 5 到 10 倍的磁盘空间。

顺便说一句，只要我可以定义一个<fileset> 来查找属性文件，我就可以使用<for> 任务，所以你可以使用不同的目录。并且，您可以使用<basename> 来提取目录名称。