java - 基于Maven的Java应用程序的自动配置，版本控制和部署的可行方法是什么？

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center提供指导。




已关闭8年。




我们正在维护一个合并到单个多(多)模块maven项目中的中型代码库。总体而言，整个构建最多具有十个针对不同系统组件(Web应用程序(.war)，实用程序(.jar)等)的输出 Artifact 。

到目前为止，我们的部署过程基于简单的bash脚本，这些脚本通过maven构建请求的 Artifact ，用有关 Artifact ，目标环境和当前构建时间戳的信息标记scm存储库，然后将 Artifact 上传到选定的环境应用程序服务器并发布命令以重新启动正在运行的守护程序。
构建的 Artifact 的配置通过Maven概要文件和资源过滤进行。因此，我们的构建特定于目标环境。

这个过程为我们提供了很好的服务，但是出于不同的原因，我想朝着更复杂的方法前进。特别是我想摆脱bash脚本。

那么关于基于Maven的Java应用程序的配置，版本控制和部署的最佳实践是什么？

我们的构建是否应该与环境无关，并且可以通过目标系统上的配置文件来完成配置？如果是这样，开发人员将如何照顾到各种应用程序服务器上已部署的配置文件中包含新的配置选项？

我们是否应该使用Maven版本的Maven版本插件来标记各种构建？

配置诸如Jenkins或Teamcity之类的CI服务器来为我们构建和可选地部署我们的 Artifact 是一个好主意吗？

最佳答案

我喜欢考虑两个问题空间:

构建 Artifact (理想情况下是与环境无关的，因为这意味着QA可以对 Artifact 进行哈希处理，在该 Artifact 上进行测试，以及何时需要部署，验证 Ember ，并且您已经对其进行了质量检查。如果您的构建产生了不同的结果 Artifact 取决于QA的环境还是分期环境，还是生产环境，那么您必须做更多的工作以确保投入生产的 Artifact 已经过QA测试并已分阶段进行)

将 Artifact 运送到环境中。在该环境需要对 Artifact 进行配置的情况下，运输过程应包括该配置，方法是将适当的配置文件放入目标环境中，然后让 Artifact 进行拾取，或者通过打开 Artifact ，对其进行配置并将其密封回来(但以可重复和确定性的方式)

Maven专为第一个问题空间而设计。 “Maven方式”就是关于生成与环境无关的构建 Artifact 并将其发布到二进制 Artifact 存储中。如果查看Maven生命周期，您会发现在将 Artifact deploy编码到Maven存储库(二进制 Artifact 存储)之后，该阶段会停止。简而言之，Maven认为自己的工作已经完成。此外，单元 test和 integration-test都有生命周期阶段，使用不可知论的环境，这两个阶段都应该是可能的，但这并不是您需要的全套测试...而是要完成测试，您需要实际将构建的 Artifact 部署到实际环境中。

许多人试图劫持Maven以超越其目标(包括我自己)。例如，您拥有 cargo-maven-plugin 和 ship-maven-plugin ，它们涉及Maven最终游戏以外的方面(即，在 Artifact 到达Maven存储库之后)。我个人认为，其中的 ship-maven-plugin(我写过，写着我以前的“myself included”)最接近于“after maven”，因为默认情况下，它是设计来运行的，而不是在您所使用的项目的 -SNAPSHOT版本上运行已在磁盘上 check out ，但在从远程存储库中提取的同一项目的发行版中 check out ，例如

mvn ship:ship -DshipVersion=2.5.1

IMO， cargo 的目标是在生命周期内的 integration-test阶段周围使用，但是同样，您可以劫持该 cargo 以用于其他目的。

如果要生产收缩包装的软件(即用户购买并安装在系统上的那种软件)，则安装程序本身就是为最终用户环境配置应用程序而设计的。让Maven构建产生安装程序是很好的，因为实际的安装程序(至少在某种程度上)与环境无关。好的，它可能是仅Microsoft Windows的安装程序，也可能是仅Linux的安装程序，但它并不关心安装该计算机的用户。

但是，如今，我们倾向于将更多的精力放在软件即服务上，因此我们将软件部署到我们控制的服务器上。转向“Maven黑暗面”变得更加诱人，在该处，构建配置文件用于调整构建 Artifact 的内部配置(毕竟我们只部署了三个环境)，并且我们正在快速发展，所以不想花些时间使应用程序从构建的 Artifact (从外部熟悉)中拾取特定于环境的配置。我称其为阴暗面的原因是您确实在与Maven想要工作的方式作斗争...您总是想知道本地存储库中的jar是否是在 Activity 的其他配置文件下构建的，因此您最终必须完成全部工作始终保持清洁状态。当需要从质量保证过渡到阶段或从阶段过渡到生产时，您需要完成整个软件的构建...并且所有单元和集成测试最终都将再次运行(或者最终跳过它们并进入跳过他们可能会在正在构建的 Artifact 上提供的理智性)，因此实际上，您正在使生活变得更加困难和更加复杂。。。只是为了将一些配置文件放入 maven pom.xml中……想想，如果您遵循 maven 的方法，您只需从存储库中获取 Artifact ，然后将其沿未修改，毫不费力的不同环境移动，并使用MD5，SHA1(并希望是GPG)签名来证明它是相同的 Artifact 。

所以，你问，我们如何编码运输到生产的……

好了，有很多方法可以解决这个问题。他们都有着相似的核心原则，即

在源代码管理系统

中保留将要发送到环境的配方

理想情况下，配方应包含两个部分，一个与环境无关的部分，以及一个特定于环境的部分。

您可以使用良好的旧bash脚本，也可以使用针对此第二个问题空间而设计的更多“现代”工具，例如Chef和Puppet。

推荐建议

您应该使用正确的工具完成正确的工作。

如果是我，这是我会做的:

使用Maven Release Plugin剪切版本

所构建的 Artifact 应始终与环境无关。

对于所有配置选项，构建的 Artifact 应包含“合理的默认值”。换句话说，如果缺少没有合理默认值的必需配置选项，它们应该迅速崩溃，或者如果未指定 optional ，则它们应该以明智的方式执行。所需的配置选项的一个示例可能是数据库连接详细信息(除非该应用程序愿意与内存数据库一起运行)

在“主厨与人偶” war 中选择一方(无论哪一方都可以，如果愿意，可以更改一方。如果您具有ANT的心态，则厨师可能更适合您，如果您喜欢依赖管理魔术，则p可能适合你更好)

开发人员应该在定义要部署的Chef/Puppet脚本(至少是那些脚本中与环境无关的部分)时有发言权。

操作应定义厨师/人偶部署的特定于生产环境的细节

将所有这些脚本保留在SCM中。

使用Jenkins或任何CI，使尽可能多的步骤自动化。 Jenkins (Jenkins)推荐的构建插件是您的 friend 。

最终的结果是，每次提交(只要它通过了所有必需的测试)就可以(可能会)自动部署到生产中(或者可能有人说“继续”)被部署到生产中……请注意，并不是说您实际上在做每次提交都需要这个，只有你可以

关于java - 基于Maven的Java应用程序的自动配置，版本控制和部署的可行方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14650468/

上一篇：.net - vb.net 重新绑定(bind)数据网格以显示 vb.net 中的更改

下一篇：d3.js - d3.js 强制布局是否允许动态链接距离？

相关文章：

java - 基于输入的动态日志文件命名？

maven - Maven中dependencyManagement和dependencies的区别

deployment - 使用 TeamCity 进行持续部署

java - Android - 为什么我在 SQLiteOpenHelper onCreate 中收到 NullPointerException？

java - hibernate 与 Derby : Cannot close a connection while a transaction is still active

Java 功能测试

java - eclipse 未在 java 8 项目中插入 "diamond"运算符

java - Maven:无法找到或加载主类

deployment - 如何将中间人站点部署到 GitHub 用户页面

java - 借助小程序运行网页中的普通Jar文件

Answer 1

我喜欢考虑两个问题空间:

构建 Artifact (理想情况下是与环境无关的，因为这意味着QA可以对 Artifact 进行哈希处理，在该 Artifact 上进行测试，以及何时需要部署，验证 Ember ，并且您已经对其进行了质量检查。如果您的构建产生了不同的结果 Artifact 取决于QA的环境还是分期环境，还是生产环境，那么您必须做更多的工作以确保投入生产的 Artifact 已经过QA测试并已分阶段进行)

将 Artifact 运送到环境中。在该环境需要对 Artifact 进行配置的情况下，运输过程应包括该配置，方法是将适当的配置文件放入目标环境中，然后让 Artifact 进行拾取，或者通过打开 Artifact ，对其进行配置并将其密封回来(但以可重复和确定性的方式)

Maven专为第一个问题空间而设计。 “Maven方式”就是关于生成与环境无关的构建 Artifact 并将其发布到二进制 Artifact 存储中。如果查看Maven生命周期，您会发现在将 Artifact deploy编码到Maven存储库(二进制 Artifact 存储)之后，该阶段会停止。简而言之，Maven认为自己的工作已经完成。此外，单元 test和 integration-test都有生命周期阶段，使用不可知论的环境，这两个阶段都应该是可能的，但这并不是您需要的全套测试...而是要完成测试，您需要实际将构建的 Artifact 部署到实际环境中。

许多人试图劫持Maven以超越其目标(包括我自己)。例如，您拥有 cargo-maven-plugin 和 ship-maven-plugin ，它们涉及Maven最终游戏以外的方面(即，在 Artifact 到达Maven存储库之后)。我个人认为，其中的 ship-maven-plugin(我写过，写着我以前的“myself included”)最接近于“after maven”，因为默认情况下，它是设计来运行的，而不是在您所使用的项目的 -SNAPSHOT版本上运行已在磁盘上 check out ，但在从远程存储库中提取的同一项目的发行版中 check out ，例如

mvn ship:ship -DshipVersion=2.5.1

IMO， cargo 的目标是在生命周期内的 integration-test阶段周围使用，但是同样，您可以劫持该 cargo 以用于其他目的。

如果要生产收缩包装的软件(即用户购买并安装在系统上的那种软件)，则安装程序本身就是为最终用户环境配置应用程序而设计的。让Maven构建产生安装程序是很好的，因为实际的安装程序(至少在某种程度上)与环境无关。好的，它可能是仅Microsoft Windows的安装程序，也可能是仅Linux的安装程序，但它并不关心安装该计算机的用户。

但是，如今，我们倾向于将更多的精力放在软件即服务上，因此我们将软件部署到我们控制的服务器上。转向“Maven黑暗面”变得更加诱人，在该处，构建配置文件用于调整构建 Artifact 的内部配置(毕竟我们只部署了三个环境)，并且我们正在快速发展，所以不想花些时间使应用程序从构建的 Artifact (从外部熟悉)中拾取特定于环境的配置。我称其为阴暗面的原因是您确实在与Maven想要工作的方式作斗争...您总是想知道本地存储库中的jar是否是在 Activity 的其他配置文件下构建的，因此您最终必须完成全部工作始终保持清洁状态。当需要从质量保证过渡到阶段或从阶段过渡到生产时，您需要完成整个软件的构建...并且所有单元和集成测试最终都将再次运行(或者最终跳过它们并进入跳过他们可能会在正在构建的 Artifact 上提供的理智性)，因此实际上，您正在使生活变得更加困难和更加复杂。。。只是为了将一些配置文件放入 maven pom.xml中……想想，如果您遵循 maven 的方法，您只需从存储库中获取 Artifact ，然后将其沿未修改，毫不费力的不同环境移动，并使用MD5，SHA1(并希望是GPG)签名来证明它是相同的 Artifact 。

所以，你问，我们如何编码运输到生产的……

好了，有很多方法可以解决这个问题。他们都有着相似的核心原则，即

在源代码管理系统

中保留将要发送到环境的配方

理想情况下，配方应包含两个部分，一个与环境无关的部分，以及一个特定于环境的部分。

您可以使用良好的旧bash脚本，也可以使用针对此第二个问题空间而设计的更多“现代”工具，例如Chef和Puppet。

推荐建议

您应该使用正确的工具完成正确的工作。

如果是我，这是我会做的:

使用Maven Release Plugin剪切版本

所构建的 Artifact 应始终与环境无关。

对于所有配置选项，构建的 Artifact 应包含“合理的默认值”。换句话说，如果缺少没有合理默认值的必需配置选项，它们应该迅速崩溃，或者如果未指定 optional ，则它们应该以明智的方式执行。所需的配置选项的一个示例可能是数据库连接详细信息(除非该应用程序愿意与内存数据库一起运行)

在“主厨与人偶” war 中选择一方(无论哪一方都可以，如果愿意，可以更改一方。如果您具有ANT的心态，则厨师可能更适合您，如果您喜欢依赖管理魔术，则p可能适合你更好)

开发人员应该在定义要部署的Chef/Puppet脚本(至少是那些脚本中与环境无关的部分)时有发言权。

操作应定义厨师/人偶部署的特定于生产环境的细节

将所有这些脚本保留在SCM中。

使用Jenkins或任何CI，使尽可能多的步骤自动化。 Jenkins (Jenkins)推荐的构建插件是您的 friend 。

最终的结果是，每次提交(只要它通过了所有必需的测试)就可以(可能会)自动部署到生产中(或者可能有人说“继续”)被部署到生产中……请注意，并不是说您实际上在做每次提交都需要这个，只有你可以