1

このタイプのワークフローをサポートするようにMavenを構成するにはどうすればよいですか?

ワンタイムセットアップMavenを呼び出して、次のような開発者マシンのワンタイムセットアップを実行します。

  1. このアプリケーション用に構成されたTomcatのカスタムバージョンを作成します
  2. 開発者のマシンにローカルのpostgresデータベースを作成します
  3. サンプルデータをデータベースにロードする
  4. junitテストを実行して、アプリケーションの実行に必要な他のリソースを構成します

統合テストMavenを呼び出して、次の統合テストを実行します。

  1. 統合テストデータベースを作成する
  2. データベースを設定する
  3. dbに対してコマンドライン統合テストを実行します
  4. アプリケーションを含むTomcatのテストバージョンを実行します
  5. アプリケーションによって公開されるRESTfulサービスをテストするコマンドラインjunitテストを実行します

リリースビルドmavenを呼び出して、システムのリリースビルドを実行します

  1. 統合テストのすべての手順を実行します
  2. 本番環境ではなくサーバーで使用されるリソースと構成を生成する
  3. 最終結果をgitリポジトリにデポジットし、コミットして、変更を本番環境にプッシュします

テストビルドMavenを呼び出して、システムのテストビルドを実行します

  1. リリースビルドのすべての手順を実行しますが、テストサーバー構成を使用してテストリリースパッケージを構成します

私が苦労している主なことは、Mavenには単一のビルドライフサイクルがあり、フェーズのシーケンスが明確に定義されており、ビルドするワークフローがMavenに適しているかどうかがわかりません。

このタイプのワークフロー用にMavenを構成できますか?はいの場合、Mavenを使用する4つの主な方法のさまざまな構成を可能にするMavenの主な機能は何ですか?

更新このワークフローの意味するところは、次のようなことができるようになりたいということです。

mvn setup 
mvn integration 
mvn prod-release
mvn test-release 

私は上記の例がアリのように見えることを知っています。私は長年のアリのユーザーであり、Mavenを使用した完全な初心者です。

4

1 に答える 1

2

あなたはそれをすべて行うようにMavenをセットアップすることができます...

あなたはおそらくこれのいくつかを達成するために(ショックホラー)プロファイルを使用するでしょう...

しかし、あなたはそれをしたくない

あなたはANTスタイルの考え方に従っています...そのスタイルの考え方が好きなら、ANTまたはGradleを使用して幸せになってください。

Mavenの方法に従いたい場合は、問題を別の方法で解決します。

Mavenの方法から来て、ここに私の考えがあります:

  1. なぜ1回限りのセットアップが必要なのですか?私は通常run、正しいアプリケーションサーバーを動的にプロビジョニングし、アプリがデプロイされた状態でサーバーを起動し、後でヒットしたときにすべてを破棄するプロファイルを持っています^C。通常、これには1つまたは2つのデータベースサーバーの起動が含まれます...したがって、cassandra-maven-pluginのように私が開発したものです。そうすれば、別のプロジェクトに取り組んでいるときに(10分かかる可能性があります)、バックグラウンドデータベースサーバーがラップトップのRAMをすべて使い果たすことを心配する必要はありません。

  2. 上記が機能している場合、統合テストは実際には簡単です...実際、私はプラグインの実行を統合テストの適切なフェーズに結び付けるのを簡単にするためにMavenフェイルセーフプラグインを作成しました。run-itsMavenの規則では、統合テストを実行するために呼び出されるプロファイルがあります。

  3. リリースビルドはテストビルドとは異なります...うーん!環境にとらわれないアーティファクトを構築する必要があります。デプロイされている環境から構成を取得してもらいます。これにより、「テスト」ビルドと「本番」ビルドの間で何かが変更されたという心配がなくなります。本当に構成をバンドルする必要がある場合は、通常、不可知論的なアーティファクトを取得して必要な構成に再バンドルするために、別のモジュールを使用します。そうすれば、再現可能な変換があり、QAに行ったものとOpsに行ったものの間で何も変わっていないことを簡単に証明できます。

  4. 私は常にリリースビルドに統合テストを含めるようにしています。

だから通常、私は次のようなプロジェクトを持っています

$ mvn -Prun

ゼロからアプリケーションを起動します。^ Cを押すと、すべてが再び破棄されますmvn clean。極端な状況では、より複雑なセットアッププロセスがあり、キャッシュが必要な場合mvn post-clean(本当にクリーンだと思います)、runプロファイルが機能するものはすべて削除されます。

統合テストを実行するために、私は通常行います

$ mvn -Prun-its verify

リリースを作成するために、私は通常行います

$ mvn release:prepare release:perform -B

それは(私の見解では)あなたが必要とする上記のステップを処理する理想的な方法です。

HTH。

ところで、私は特にPostgreSQLを使用する必要はありませんでした(通常、私の統合テストとrunプロファイルは、derbyhsqldbなどの純粋なJavaデータベースでうまくいく可能性があり、アーティファクトは環境に依存しないため、統合テスト/開発フライウェイトアプリサーバーに注入させるのは簡単です正しいJDBCURL)なので、PostgreSQLに関していくつかの問題が発生する可能性があります

于 2012-11-10T14:06:18.210 に答える