Hudson CI サーバーは、クールな安定性「天気」を表示します。また、別のプロジェクトの成功したビルドに基づいて、1 つのプロジェクトのビルドを開始できます。しかし、その二次プロジェクトを、最初のプロジェクトの複数のビルドの安定性にさらに依存させるにはどうすればよいでしょうか?
具体的には、プロジェクト「stable_deploy」は、バージョン 8.3.4.1233 との「統合」プロジェクトが少なくとも 8 回連続してビルドおよびテストに成功した場合にのみ、バージョンを「安定版」に昇格するために開始する必要があります。それまでは、まだ統合モードです。
重要: これに対する重要な注意点は、Hudson プロジェクトの単一セットが、リリースまでの各新しいバージョンを処理するための「パイプライン」として使用されることです。したがって、プロジェクトは連続して 8 回正常にビルドされた可能性がありますが、最新バージョン 8.3.4.1233 は最新の 2 回のビルドのみである可能性があります。それより前のビルドは、以前のバージョンである可能性があります。
これを完全に再編成することは可能ですが、パイプラインのアイデアにより、手動でのプロジェクトの作成と削除の量が大幅に削減されたようです。バージョン リリースの「パイプライン」を追跡するより良い方法はありますか? 特に、古いバージョンへの修正またはパッチにより、将来、このパイプラインに複数のバージョンが同時に存在することになります。バージョンごとに新しいパイプライン プロジェクトを作成するのは本当に面倒ですが、その方法はまだわかりません。
背景の詳細は次のとおりです。
TickZoom アプリケーションには、リアルタイム取引環境をシミュレートするいくつかの非常に完全な単体テストがあります。それに加えて、TickZoom はマルチコア コンピューターを活用するために並列化を精巧に利用します。言うまでもなく、新しいバージョンの開発中は、ビルドと自動テストを繰り返し実行することで明らかになる統合テスト中に安定性の問題が発生する可能性があります。ビルドとテストを 8 回続けて変更せずにクリーンに行い、さらにユーザーによる実際のテストを行ったバージョンは、「安定」と見なされ、安定版ブランチに昇格されます。
Hudson プロジェクトは次のようになります。
test - ビルドのテスト専用で、ユーザーの可視性はありません。integrate_deploy - テスト プロジェクトのビルドを促進してブランチを統合し、UA テストで公開できるようにします。統合 - 安定したブランチに昇格するのに十分安定しているかどうかを判断するために、統合ブランチを繰り返しビルドします。これにより、毎晩ビルドとテストが 1 時間ごとに実行されます。stable_deploy - 統合プロジェクト ビルドを安定版ブランチに昇格させ、最新かつ最高のものを望むユーザーに公開します。stable - 安定したブランチを毎晩 1 回ビルドします。2 週間の成功したビルド (14 ビルド) の後、「リリース候補」に進むことができます。
などなど…「リリース候補」、「リリース」と続きます。