6

Hudson の使用を開始しました。現在のワークフローは次のとおりです。

ローカルでチェックアウト > コード > テストを実行 > 更新 > テストを実行 > コミット

ポーリングではなく、Hudson は、ビルドをインスタンス化するまでそのまま待機します。次に:

ローカルでチェックアウト > Phing スクリプトを実行

Phing スクリプトは次のようになります。

svn export latest Revision > テストを実行 (成功した場合) > レポートなどを生成 > エクスポートを圧縮 > scp を本番サーバーに > .. 魔法をかけてサイトをライブにする ...

これはすべて正常に機能しますが、実際には、あらゆる種類の「ステージング」QA を実行できるわけではなく、すべてのビルドでレポ ヘッド リビジョンがビルドされます。理想的には、Hudson が各コミットをビルドしてポスト コミット フックをポーリングまたは使用するようにしたいと考えています。

ローカルでチェックアウト > Phing タスクを実行してテストを実行し、成功した場合はレポートなどを生成します。

次に、特定のビルドごとに「ステージング QA 環境」または「プロダクション」のいずれかに (Phing タスクを介して) 自動展開を手動でインスタンス化できます。すべてのコミットが QA に展開されるわけではありません。

このワークフローは Hudson でも可能ですか、それともデプロイの Phing タスクを後で手動で実行する必要がありますか。

4

3 に答える 3

4

ビルド/テスト ジョブ (job1) とデプロイ ジョブ (job2) を分離しました。Job1 は、コミットのたびにトランクで実行されます (Hudson のポーリングですが、ポスト コミット フックも同様に機能します)。また、ビルド成果物もアーカイブします。Job2 は手動で開始されます。ジョブ 1 から build_number をビルド パラメーターとして取得し (私は run パラメーターが好きです)、ジョブ 1 からアーティファクトを独自のワークスペースにダウンロードします。彼らが展開を実行します。あなたの場合、別のパラメーター (選択パラメーター) を追加して、デプロイする環境を決定します。

ディスクリプション セッター プラグインを使用すると、ジョブ 1 と環境から実行番号を出力でき、ジョブ履歴でどのビルドがいつどの環境にデプロイされたかを簡単に確認できます。

于 2010-11-01T17:53:47.417 に答える
2

最終的に、Peter Schuetze の提案に似たようなことをしました。ただし、唯一のジョブのみを使用しました。deploy (bool)、environment (choice)、revision (text) の 3 つのビルド パラメータを使用します。次に、デプロイ パラメーターが true の場合にのみデプロイを実行するように Phing スクリプトを変更しました。この場合、指定されたリビジョンが指定された環境にデプロイされます。デフォルトでは、デプロイは false、リビジョンはヘッド、環境はステージングです。Hudson が svn をポーリングすると、デプロイ パラメーターが false であることがわかり、デプロイ タスクがバイパスされます。

于 2011-02-02T11:38:40.550 に答える
0

何を達成したいのか完全にはわかりませんが、Phingプラグインを使用しているかどうか疑問に思っていますか? おそらく、あなたが望んでいることは現在 Hudson では実現できず、それを可能にするために開発プロセスを変更する必要があるかもしれません。

于 2010-10-29T18:10:58.973 に答える