8

ビルド（.warファイル）をTomcatに自動的にデプロイできるようにHudsonを構成しようとしています。新しくデプロイされたビルドは、誰かがアプリケーションをテストするために使用します。

Deploy Pluginを使用して.warファイルを自動的にデプロイしようとしましたが、これは機能します。ただし、.warファイルをビルドするジョブは、scmが変更されるたびに（コードがコミットされるたびに）実行されます。Deploy Pluginを使用すると、ビルドが行われるたびに.warファイルがTomcatにデプロイされます。コードは頻繁にコミットされるため、これはWebアプリケーションも頻繁に再起動されることを意味し、これによりテストプロセスが中断されます。

Hudsonがユニットテストを実行し、定期的にビルドを作成しているという事実に感謝しているので、このジョブのトリガーを変更したくありません。

ハドソン内から手動で展開することを決定できる方法を探しています。最初のジョブから.warをデプロイする別のジョブを作成しようとしましたが、これは機能しませんでした。誰かがこのようなものを設定した経験がありますか？

4

2 に答える 2

7

アーティファクトの入手方法

プラグインのデプロイページの「以前のビルドをロールバックまたは再デプロイする方法」のセクションを参照してください。基本的な考え方を説明しています。アーティファクトのコピープラグインを使用して、アーティファクトをビルドジョブから現在のジョブ（デプロイジョブ）にコピーします。そこから、ビルドステップで行ったのと同じことを行います。

デプロイをトリガーする方法

デプロイを開始した後はビルドジョブをトリガーできないため、最初にビルドが実行され、次にデプロイジョブが実行されます。したがって、いくつかのオプションがあります。

  • 手動でビルドをトリガーします。展開を開始するユーザーは、ビルドジョブの特定の実行を選択する必要があります。
  • スケジュールされた展開これは、夜間のタスクの一部である可能性があります。ジョブは特定の間隔でトリガーされます（毎晩または毎週末など）。自動化されているため、デプロイジョブは最後に成功したビルドを取得する必要があります（パラメータ化されたジョブは必要ありません）。ラン番号を渡す機会はありません。
  • ビルドが正常に完了するたびにデプロイジョブがトリガーされます（要件に適合しませんが、リストを完成させるためにリストされます）
  • 他の（難解な）トリガー。これは多くの異なる考えである可能性があります。たとえば、ビルドURLを呼び出すことによってリモートでトリガーされます。呼び出しは、発券システム、テストラボ管理システム、またはその他の任意のシステムのいずれかから発信できます。リリース番号の変更など、ソース管理システムの特定の変更によって展開をトリガーすることもできます（たとえば、コミットメッセージでキーワードでマークされています）。このトリガーは、ハドソンの内外で実装できます。他にも利用可能なトリガーがあります。これには、HTMLページの変更、ファイルシステムの監視対象部分の変更、IMメッセージ、電子メールが含まれますが、これらに限定されません。最初の3つは、Hudsonプラグインによって実装されます。プラグインリストを見て、何が利用可能かを確認するか、どちらの場合も、ビルドジョブが展開に必要なすべてのアーティファクトをアーカイブしていることを確認する必要があります。
于 2011-01-06T20:21:25.913 に答える
1

プロジェクトごとにいくつかのハドソンの仕事があります：

  1. プロジェクトをビルドしてテストを実行するだけのメインジョブ。成功すると、次のジョブが起動します。
  2. コードメトリクスジョブ（PMD、FindBugs、Cobertura、CheckStyle、JavaDoc生成）および
  3. Tomcatを使用してプロジェクトをビルドしmvn package -DskipTests、戦争をデプロイするデプロイジョブ

これらを分離することで物事が簡単になり、最初の仕事だけがSCMの変更をリッスンすることがわかりました。

ただし、別の方法は、3番目のジョブにもSCMをリッスンさせることです（ただし、間隔を長くして、おそらく1時間）。

于 2011-01-06T14:05:45.250 に答える