1

前言：

像大多数公司一样，我的公司有几个运行时环境和几个发布版本，它们本身由各种 jar 的不同版本组成。

例如，让我们考虑软件 X 的发布版本 1.1、1.2 和 1.3，它们可以部署到开发人员计算机、测试或生产。

software-x-1.1 本身是由 jarA-0.9.1 和 jarB-0.7.5 组成的，而 software-x-1.3 是由 jarA-1.7.31 和 jarB-0.8.1 组成的。

目前我们使用 Spring 的 PropertyPlaceholderConfigurer 来配置运行时变量（例如数据库凭据），但是，属性也会随着发布版本而变化。

我们还使用 Maven 2 POM 版本 4 来指定需要使用我们的代码的哪些版本。我们将 jar 的版本号作为属性放在父 pom 内的配置文件（dev、test、prod）中，然后在所有项目 pom 中引用这些版本号。

截至目前，除了最新版本之外，我们无法指定与给定版本相关的项目版本。此外，我们将运行时配置部署到 SSDM 拾取器，然后由我们的软件构建版本配置和创建定义的服务。

--

问题：
是否有任何程序/工具可以通过仅提供运行时环境和版本号来构建我们的产品？IE“构建 1.1 开发”？

无论如何，我们可以为每个发布版本存储所需的 jar 版本吗？我们目前正在对所有文件进行版本控制，包括父 pom，但仅对父 pom 进行版本控制不会记录哪个发布版本与该父 pom 相关。

我们还能做些什么来进一步自动化构建过程？

例如，如果我们可以在父 pom 中管理运行时配置，这将是朝着正确方向迈出的一步，但这似乎违反了范围。

在这一点上，我们框架之外的任何工具都是不可想象的，但在遥远的将来也不会。

概括：

我们如何才能最大限度地自动化我们的构建过程而不容易出错？

4

2 回答 2

0

如果我总结您的问题：您想管理跨多个环境的版本发布，并且您的发布分发是可执行文件（jar）以及环境属性的集合。这些可部署发行版的不同版本在不同阶段传播到具有自己的一组 env 属性的 diff env，您正在寻找一种方法来进行通用推出（或可能是发布过程）来处理所有这些。

似乎您遇到的第一个问题是，在传播版本时，您在每个环境中运行每个版本的构建。如果我没记错的话，您应该首先尝试查看您的应用程序架构，看看是否有一种方法可以创建独立于环境的二进制文件，在某些情况下，项目更喜欢将属性保留为与 jar 一起部署的单独模块，以及各种图形的属性管理器读取文件，因此您可能有一个称为属性的 maven 模块，它为每个 env 属性文件集捆绑一个 zip。然后可以在运行时为您的部署脚本提供一个参数，以将哪个 zip 文件提取到可以将属性读入应用程序的位置。你通过这种方式获得的是“

另外，您发布的版本是否“不是”您在 POM 中拥有的版本？如果没有将您的发布版本与 POM 对齐，则应该完成。即，当您在该版本的开发阶段工作时，POM 应该是 1.3-SNAPSHOT，而当您发布它时，它应该在分支中被撞到 1.3。

没有一种适合所有解决方案的解决方案，但与此类似的做法确实在很大程度上有所帮助。

PS如果我解决了你的问题，或者最终绕过灌木丛，请告诉我;-) DS。

于 2011-04-25T11:16:16.837 回答
0

基于已发布的 Software X 版本 1.1、1.2 和 1.3 的部分，使用配置文件处理测试、生产等环境之间的差异似乎是正确的方法。软件本身是另一回事。我假设您正在使用版本控制工具 (VCT) 来存储您的开发状态。因此，在准备 Software-x-1.1 期间，您更改了根 pom 并定义了依赖项（jarA-0.9.1、jarB-0.7.5）。制作标签版本 1.1。而不是继续发布 1.2...在发布 1.3 的开发过程中，您决定更改依赖项（更改为 jarA-1.7.31 和 jarB-0.8.1），这会导致 pom 或您的根 pom 的更改）。可能是我忽略了你真正的问题。

于 2010-04-21T07:08:13.310 回答