外部の Jenkins オーケストレーションの解決策があるかどうか疑問に思っていますか?
最初にセットアップについて説明します。
- 継続的インテグレーション パイプラインを通じてテストする必要がある巨大な Java アーティファクトがいくつかあります
Aジョブは、コミット後にコードを取得し、単体テストを実行し、アーティファクト自体を構築するように構成されていますBジョブ (現在のところ 4 つ) は、空のデータベースを使用して、異なるセットのスモーク テストを並行して実行します。それらは、ジョブが成功した後にのみトリガーされました。Aこれらのジョブは、外部リソース (アーティファクトがデプロイされるクラウド ノード) と DB プールのデータベースを使用します。ジョブは、Jenkins で 3 つのステータスを返すことができます。- 緑: クラウド ノードが正常に取得され、アーティファクトがデプロイされ、すべてのテストに合格しました
- 黄色: インフラストラクチャの障害は検出されていませんが、一部 (またはすべて) のテストが失敗しました --> ここで開発者/QA を責めます
- 赤: もう 1 つのインフラストラクチャ障害がありました: クラウドの混乱、データベースの利用不可、アーティファクトのデプロイの失敗。--> ここで DevOps のせいにする
Cjob:すべてのジョブが緑色の場合にのみ実行します。Bそうでなければ、フローの終わり。Nexus へのアーティファクトのアップロードDジョブ: 機能テストを実行します。ここにあるいくつかのジョブはB、デプロイの時間を節約するために、ジョブからクラウド ノードを再利用します。緑、黄、赤のいずれの状態になるかは気にしません。結果を記録するだけです。ただし、ここにはAクラスター構成のジョブから元のアーティファクトをデプロイする 2 つのジョブがあり、デプロイが成功した場合はEジョブが個別に開始されます (つまり、D1ジョブが失敗しE1た場合は開始されませんがD2、同じワークフローでジョブが成功した場合E2はトリガーされる必要があります) 。 .
ワークフローが終了したら、ステータスを決定する必要があります。致命的なエラー (赤色のビルド) があった場合、ワークフローは失敗ステータスでなければなりません。
ワークフローが完了したら、すべてのリソース (クラウド ノードとデータベース) を解放する必要があります。
そのようなロジックを実装するために、どのワークフロー/プロセス フロー ツールまたはライブラリを利用できますか?
フローが異なるパイプラインが他にもいくつかあるため、柔軟にする必要があります。
現在の実装には、非常に複雑なロジックと、共有リソースを処理するいくつかの技術的なジョブがあります。そのロジックを 1 か所に実装したいと考えています。つまり、Jenkins ジョブを外部でトリガーし、実行するパラメーターを供給するオーケストレーターです。