1

序文：

私の会社は、ほとんどの場合と同様に、いくつかのランタイム環境と、それ自体がさまざまな 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 dev"?

各リリース ビルドに必要な jar バージョンを保存する方法はありますか? 現在、親 pom を含むすべてのファイルをバージョン管理していますが、単に親 pom をバージョン管理するだけでは、その親 pom に関連するリリース バージョンは記録されません。

ビルドのプロセスをさらに自動化するには、他に何ができるでしょうか?

たとえば、親 pom 内でランタイム構成を管理できれば、正しい方向への一歩となりますが、それはスコープ違反のように思えます。

私たちのフレームワークの外にあるツールは、現時点では考えられませんが、遠い将来には考えられません。

概要：

エラーを発生させずにビルド プロセスを最大限に自動化するにはどうすればよいでしょうか。

4

2 に答える 2

0

問題を要約すると、複数の環境にわたるバージョンのリリースを管理する必要があり、リリース配布は実行可能ファイル（jar）と環境プロパティの集合体です。これらのデプロイ可能なディストリビューションのさまざまなバージョンは、独自のenvプロパティのセットを使用して、さまざまな段階でdiff envに伝播し、これらすべてを処理するための共通のロールアウト（またはリリースプロセス）を行う方法を検討しています。

最初の問題は、リリースを伝播するときに、環境ごとにリリースごとにビルドを実行することです。私が間違っていない場合は、最初にアプリアーキテクチャを調べて、環境に依存しないバイナリを作成する方法があるかどうかを確認する必要があります。場合によっては、プロジェクトは、jarと一緒にデプロイされる個別のモジュールとしてプロパティを保持することを好みます。フィギュアがファイルを読み取る種類のプロパティマネージャー。プロパティと呼ばれるMavenモジュールがある場合があります。このモジュールは、プロパティファイルのenvセットごとに1つのzipをバンドルします。デプロイヤースクリプトは、実行中にパラメーターを指定して、プロパティをアプリケーションに読み込むことができる場所に抽出するzipファイルを指定できます。この方法で得られるのは、「

また、リリースするバージョンがPOMにあるバージョンではない場合もありますか？リリースバージョンをPOMに合わせていない場合は、実行する必要があります。つまり、POMは、そのリリースの開発フェーズで作業しているときは1.3-SNAPSHOTであり、リリースしているときはブランチで1.3にバンプオフする必要があります。

そのようなもののすべてのソリューションに適合する1つのサイズはありませんが、これと同様のプラクティスはかなりの程度役立ちます。

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 に答える