梅文 + SSDM 构建和运行时环境自动化
前言：
我的公司和大多数公司一样，有几个运行时环境和几个发行版本，它们本身是由不同版本的各种jar组成的。
例如，让我们考虑 Software 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 拾取器，然后 SSDM 拾取器配置并创建由我们软件的构建版本定义的服务。
--
问题：
是否有任何程序/工具可以用来仅通过提供运行时环境和版本号来构建我们的产品？ IE“构建 1.1 开发”？
我们是否可以为每个发布版本存储所需的 jar 版本？我们当前正在对所有文件进行版本控制，包括父 pom，但仅仅对父 pom 进行版本控制并不会记录哪个发行版本与该父 pom 相关。
我们还能做些什么来进一步自动化构建过程？
例如，如果我们可以在父 pom 中管理运行时配置，这将是朝着正确方向迈出的一步，但这似乎违反了范围。
目前，我们框架之外的任何工具都是不可想象的，但在遥远的将来并非如此。
简介：
我们如何才能最大程度地自动化构建过程而不容易出错？
Preface:
My Company, like most, has several run-time environments and several release versions which themselves are composed of different versions of various jars.
For example, let us consider release versions 1.1, 1.2, and 1.3 of Software X, which may be deployed to a developer computer, testing, or production.
Software-x-1.1 is itself composed of jarA-0.9.1 and jarB-0.7.5, but software-x-1.3 is composed of jarA-1.7.31 and jarB-0.8.1.
Currently we use Spring's PropertyPlaceholderConfigurer to configure run-time variables (such as database credentials), however, properties also change with release versions.
We also use Maven 2 POM version 4 to specify which versions of our code need to be used. We place the version numbers of our jars as properties within profiles (dev,test,prod) inside of the parent pom and then reference those version numbers in all project poms.
As of right now, we have no way to specify which project versions pertain to a given release other than the most current one. Moreover, we deploy our run-time configurations to the SSDM pickup which then configures and creates the services defined by the built versions of our software.
--
Questions:
Is there any procedure/tool we can use to build our product by merely providing the run-time environment and version number? IE "build 1.1 dev"?
Is there anyway we can store the required jar versions for each release build? We are currently versioning all files, including the parent pom, but merely versioning the parent pom does not record which release version is pertinent to that parent pom.
What else can we do to further automate the process of builds?
For example, if we could manage run-time configurations within the parent pom that would be a step in the right direction, but that seems like a violation of scope.
Any tool outside of our framework is inconceivable at this point, but not in the far future.
Summary:
How can we automate our build process to the fullest extent without being error prone?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据 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）。可能是我忽略了你真正的问题。
Based on the part for released version 1.1, 1.2 and 1.3 of the Software X it seemed to be right way to use profiles to handle differences between test, production etc. environments.
The software itself is an other story. I assume you are using a version control tool (VCT) to store the state of your development. So during the preparation of Software-x-1.1 you change your root pom and define the dependencies (jarA-0.9.1, jarB-0.7.5). Make a Tag Release 1.1. and than continue to Release 1.2...during the development of Release 1.3 you decided to change the dependencies (to jarA-1.7.31 and jarB-0.8.1) which results in a change to the pom's or your root pom only). May be i oversight your real problem.
如果我总结一下您的问题：您想要跨多个环境管理版本的发布，并且您发布的发行版是可执行文件（jar）以及环境属性的聚合。这些可部署发行版的不同版本在不同阶段传播到 diff env，并具有自己的一组 env 属性，并且您正在寻找一种方法来进行公共部署（或者可能是发布过程）来处理所有这些。
看来您遇到的第一个问题是，当您传播版本时，您需要为每个环境的每个版本运行一个构建。如果我没记错的话，您应该首先尝试查看您的应用程序架构，看看是否有一种方法可以创建与环境无关的二进制文件，在某些情况下，项目更喜欢将属性保留为与 jar 一起部署的单独模块，并且属性管理器会读取文件，因此您可能有一个名为“properties”的 Maven 模块，它为每个 env 属性文件集捆绑一个 zip。然后，在运行哪个 zip 文件时，可以为您的部署程序脚本提供一个参数，以将其提取到可以将属性读入应用程序的位置。通过这种方式，您获得的是“为每个版本创建一个版本发行版 - 其内容可在所有环境上运行”。
另外，您发布的版本是否“不是”POM 中的版本？如果没有将您的发布版本与 POM 对齐，则应该完成。即，当您正在该版本的开发阶段工作时，POM 应该是 1.3-SNAPSHOT，并且当您发布它时，在分支中应降至 1.3。
对于此类问题，没有一种适合所有解决方案的解决方案，但与此类似的做法确实在很大程度上有所帮助。
PS 如果我解决了你的问题，或者最终拐弯抹角，请告诉我;-) DS。
If I summarize your problem: you want to manage release of versions across multiple environments, and you release distribution is an aggregate of executable (jars) as well as environments properties. Different versions of these deploy-able distributions propagate to diff env at different stages with there own set of env properties and you are looking at a way to have a common roll out (or may be release process) to handle all of this.
It seems the first problem you have is that you run a build per release per environment when you are propagating a release. If I am not wrong, you should try looking at your app architecture first to see if there is a way you can create environment independent binaries, in some cases projects prefer keeping properties as a separate module which is deployed along with the jars, and a Property Manager of sorts which figures reads the files, so you may have a maven module called properties, which bundles one zip each for every env set of property files. Your deployer script can then be given a parameter while running on which zip file to extract to a location from where the properties can be read into the application. What you gain this way is that you "create one release distribution per release - which has contents to run on all environments".
Also, is it the case that you release version is "not" the version that you have in POM? if not aligning your release version to POMs should be done. i.e. POM should be 1.3-SNAPSHOT when you are working on development phase of that release, and be bumped off to 1.3 in a branch when you are releasing it.
There are no one size fits all solutions for such things but practices similar to this one do help to a good extent.
PS Do let me know if I got your problem right, or have ended up beating around the bushes ;-) DS.