使用 CI/Hudson 支持为多个环境 [prod、test、dev] 生成工件的 Maven 最佳实践？

Posted 2023-02-27

【中文标题】使用 CI/Hudson 支持为多个环境 [prod、test、dev] 生成工件的 Maven 最佳实践？

【英文标题】：Maven best practice for generating artifacts for multiple environments [prod, test, dev] with CI/Hudson support?

【发布时间】：2011-01-26 07:36:50

【问题描述】：

我有一个项目需要部署到多个环境（prod、test、dev）。主要区别主要在于配置属性/文件。

我的想法是使用配置文件和覆盖来复制/配置专门的输出。但是如果我必须使用专门的分类器生成多个工件（例如：“my-app-1.0-prod.zip/jar”、“my-app-1.0-dev.zip/jar”）或者我应该创建多个项目，每个环境一个项目？！ 我应该使用 maven-assembly-plugin 为每个环境生成多个工件吗？ 无论如何，我需要一次生成所有它们，所以它会显示配置文件不适合......仍然感到困惑:(

任何提示/示例/链接都将受到欢迎。

作为一个附带问题，我还想知道如何在 CI Hudson/Bamboo 中实现这一点，以便为所有环境生成这些生成的工件并将其部署到适当的服务器（例如：使用 SCP Hudson 插件）？

【问题讨论】：

您的开发配置文件中的 .settings 文件中有哪些信息？诸如休眠等的数据库信息之类的东西？自己设置一个“开发”配置文件，只是想知道将来我需要通过 .properties 文件指定哪些类型的东西，以及开发配置文件和发布配置文件之间的区别

【参考方案1】：

我更喜欢将配置文件与应用程序分开打包。这允许您运行完全相同的应用程序并在运行时提供配置。它还允许您事后为构建时不知道需要的环境生成配置文件。例如证书 我使用“汇编”工具将每个域的配置文件压缩到命名文件中。

【讨论】：

所以您建议为每个环境添加额外的单独项目？你能举个例子吗？

是的。每个输出都需要单独的模块。或者，您可以将它们全部压缩到一个包中，然后让安装程序仅提取必要的文件夹。

我也喜欢这样做，虽然有点麻烦。拥有一个可以在任何环境中工作并从一个环境升级到另一个环境的单一二进制文件是个好主意（例如 DEV->TEST->PROD）。

我们还在他们自己的单独项目中对配置文件进行版本控制，以便对其进行控制，但这会导致 maven 项目的爆炸式增长……如果有人提出更好的方案会感兴趣。跨度>

这里是一个生成环境特定配置的示例项目：bitbucket.org/bartswen/public-sandbox/raw/master/config-demo

【参考方案2】：

我会使用 version 元素（如 1.0-SNAPSHOT、1.0-UAT、1.0-PROD），因此在 VCS 级别上的标签/分支与配置文件结合使用（用于环境特定的东西，如机器名称、用户名密码等），以构建各种工件。

【讨论】：

嗯.. 但是 PROD 的快照版本会是什么样子？我考虑改用分类器，所以我可以使用 1.0-SNAPSHOT-PROD.jar 和程序集插件来生成它们......由于环境/暂存问题非常普遍，我认为在这方面存在最佳实践。如果你有一个简单（和现实）的例子会很有帮助

@jaguard PROD 工件怎么可能是 SNAPSHOT？ PROD 工件通常是已发布 工件，即具有固定版本（非 SNAPSHOT）的工件。我不明白你的问题。

你是对的，所以我会改写它：从快照中，我需要以这种格式（例如: 01.01.09.32.Tue-1730-dev.zip 使用这个时间格式：yy.ww.EE-HHmm)。由于几乎每天都会从快照生成构建（开发/测试），我只是在寻找一种生成它们的好做法（配置文件、不同的项目/CI 构建）......等等

【参考方案3】：

我们使用以下方法实现了一个 m2 插件来构建最终的 .properties：

从 common.properties 中读取通用的、环境无感知的设置。 从 dev.properties、test.properties 或 production.properties 读取特定的环境感知设置，因此在必要时覆盖默认值。 在按给定顺序读取文件后，最终的 .properties 文件与 Properties 实例一起写入磁盘。 根据目标环境捆绑此类 .properties 文件。

【参考方案4】：

我们使用配置文件来实现这一点，但我们只有默认配置文件 - 我们称之为“开发”配置文件，上面有配置文件，我们有一个“发布”配置文件，其中不包含配置文件（以便在安装应用程序时正确配置它们）。

我将使用配置文件来执行此操作，如果您需要部署它，我会将配置文件附加到工件名称中。我认为这有点类似于 Pascal 的建议，只是您将使用配置文件而不是版本。

PS：我们只有 dev/release 配置文件的另一个原因是，每当我们为 UAT 或 PROD 发送一些东西时，它已经被释放，所以如果有错误，我们可以追踪代码的状态是什么时候应用程序已发布 - 在 SVN 中标记它比尝试从提交历史记录中找到它的状态更容易。

【讨论】：

我们几乎每天都会为 DEV 和 TEST 生成构建，因为对于 PROD 将只计算完整版本......所以会得到很多“快照”构建......任何好的做法如何实现这个？

【参考方案5】：

去年夏天我遇到了这种情况。

我最终为每个带有分类器的高级环境使用了配置文件。默认配置文件是“不伤害”开发版本。我有 DEV、INT、UAT、QA 和 PROD 配置文件。

我最终在 Hudson 中定义了多个作业，以生成特定于区域的工件。

我会做不同的一件事是对项目进行稍微不同的架构，以便特定于区域的构建位于模块化主项目之外。也就是说，它只会为每个特定构建引入最新的工件，而不是为每个区域重新构建​​整个项目。

事实上，当我设置作业时，QA 和 PROD 作业总是设置为构建一个标签。显然，您可以根据具体的工作场所部署规则来定制。

【参考方案6】：

尝试使用https://github.com/khmarbaise/multienv-maven-plugin 为每个环境创建一个主WAR 和一个配置JAR。