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



我有一个web应用程序。我正在为它配置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文件夹下的适当位置)。

还有其他方法吗?

如果我理解您的理解,您将为连续构建服务器上的每个环境构建单独的ear/war/jar。这是正确的吗?

我有两种处理方式:智能方式愚蠢方式:

Smart Way

明智的方法是配置应用程序服务器(JBoss、Weblogic等),以便在应用程序服务器中安装的jar/ear/wars外部查找所需的属性文件。通过这种方式,您构建了一组jar/ear/wars,它在任何地方都有效。另外,你做了一些非常非常重要的事情:你导致手指O’Blame指向其他地方。

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

但是,如果属性存储在构建工件之外,则由负责配置出现故障的服务器的团队负责。

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


愚蠢的方式

在我的上一家公司,我们能够以智能方式做事。在我现在的公司里,我们做事都是用愚蠢的方式。属性嵌入在我们的构建工件中,没有简单的方法可以更改它

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

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

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

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

相关内容

  • 没有找到相关文章