Question

在我继承的基础设施中，这些人使用jenkins和maven来构建jar和配置文件。

所以，jenkins检查了一些代码，然后maven构建了一些东西。然后Jenkins发布构建任务从mavens目标目录复制文件并将它们复制到＆＃34;构建共享＆＃34; （eeks），例如

来源

**/target/*.jar

目标

releases/env_name/project/lib

来源

**/target/classes/some-service.xml

目标

releases/env_name/project/conf

我敢说这不太理想。

在新的配置项目中，来自构建的罐子被部署到Nexus中。反过来，我然后使用maven rpm插件使用GAV构建RPM来识别打包的罐子。我还没有捕获配置文件。

我可以将配置文件发布到Nexus吗？是的他们很小，但仍然是文物。他们还有一个maven快照或发布坐标，可以适应我的版本。我没试过，但我想我可以在现有的RPM构建pom中添加一个部分，以便在运行mvn deploy时将所需的纯文本文件上传到Nexus。

某些文件需要在部署后进行修改以适应环境 - 这会进一步增加头痛。

定义RPM的poms的长度也会显着增长。如果我能确定这是正确的方法，那本身就不是问题。

问题：在多环境设置中，其他人如何管理jar和配置文件？

Answer 1

既然你在问别人是怎么做的，我会说我的做法，在你的情况下可能适合或不适合。

二进制文件（.jar或whatnot）由Jenkins从SVN的源代码构建。
SVN源代码包含配置文件，但大多数情况下，这些配置文件是针对DEV或本地环境配置的。我让他们拥有它，以便开发人员的本地构建可以很简单，但就我而言，他们并不存在。
SVN还有一个单独的位置（DEV无法访问，只有发布经理和系统团队可访问），此位置包含所有环境的配置文件（包括从CI服务器部署时的DEV环境）
由于我们有很多特定于环境的设置，因此保留每个环境的单独副本是有意义的。
如果添加了新的配置参数，它将从DEV配置文件一直合并到PROD，就像合并其他源代码更改一样，但只有RM或Systems团队可以这样做。
部署过程（在我们的例子中是一个shell脚本，但可以是任何东西）负责从SVN中提取正确的配置文件，并将它们与二进制文件一起推送到远程服务器。部署服务器后，“in-jar”配置将完全由来自SVN的配置文件替换。
我通过ENV组织配置文件，然后按TYPE组织，例如：QA/WEB，QA/API，然后是PROD/WEB，PROD/API。所以我不必为每台远程机器维护配置文件。
但是，有时配置特定于远程计算机，例如计算机的IP地址。在这些情况下，SVN配置文件包含一个令牌，如[local_ip]。当部署脚本将此文件推送到远程服务器时，它会知道用远程计算机的真实IP替换令牌