問題タブ [delivery-pipeline]

Jenkinsを使用して上記の「配信パイプライン」を構築しようとしています。

「手動ステップ」を除くすべてのジョブは、上流のジョブが成功して終了すると実行されます。私の問題は、2 つのジョブ間で「結合」を実行できないことです (「手動ステップ」と「自動ステップ」を並行して実行し、「最終ステップ」の前に 2 つが正常に終了するのを待ちます)。Jenkinsでこれを可能にする方法はありますか? たぶん何かのプラグイン？

この質問は、複数の同時アップストリーム ジョブが成功した後に Jenkins ジョブを開始するにはどうすればよいですか?と非常によく似ています。

しかし、私が本当に知りたいのは、2 つの異なるタイプのジョブ (手動で実行するジョブと自動で実行するジョブ) を並列化できるかどうかを知ることです。

Delivery Pipelineと の展開機能の主な違いを理解しようとしていますActive Deploy。

Active Deployさまざまなドキュメントから、ダウンタイムなしで展開でき、ロールバックをサポートできることがわかりました。

の展開機能について知りたいですDelivery Pipeline。

Bluemix では、まったく同じアプリケーションを異なる地域 (英国と米国南部) にデプロイする必要があります。配信パイプラインの 1 つのインスタンスを使用して、これらの各リージョンの異なるスペースにデプロイする方法はありますか? 助けに感謝します

いくつかの配信パイプライン インスタンスを jenkins Delivery Pipeline View に表示しようとしています。

デリバリー パイプライン インスタンスが「フリー スタイル」または「マルチジョブ プロジェクト」として定義されている場合、すべて正常に動作しますが、「パイプライン」として定義されている場合、ジョブはデリバリー パイプライン ビューに表示されません。

私は次のことを試しました: ビルド後のアクションとしての my_pipeline-job -> 他のプロジェクトのビルド (手動ステップ) -> ダウンストリーム プロジェクト名 -> my_pipeline_job 結果はエラー メッセージでした: my_pipeline_job cannot be build!

次のようにビルドしようとすると、メッセージが消えます: my_pipeline-job as Post-Build-action ->Trigger parameterized build on other projects-> Build Triggers-> Projects to build->my_pipeline_job しかし、結果は Delivery Pipeline に表示されません意見。

デリバリー パイプライン サービスを使用して、QA/製品チーム メンバーが機能/不具合修正をテストしてから、それらの変更が本番ブランチにマージされるステージング/QA 環境にアーティファクトをデプロイしたいと考えています。

プル リクエストが作成されたときに、これらの一時的なテスト環境を起動するにはどうすればよいですか?

Jenkins で「 Delivery Pipeline」プラグインを使用しています。「 DeliveryPipeline 」というビューを定義しました。ビューは、初期ジョブとして「Initialize」というジョブを受け取ります。

以下の図に示すように、初期ジョブのビルド番号が表示されます。これは、通常のジョブのデフォルトの動作です。

そのため、ビルド番号をクリックすると; 38 と言うと、次のページが開きます。

しかし、予想されるのは、最初のジョブ「初期化」でビルド番号 (ここでは 38 など) をクリックすると、以下のページが表示されるはずです (ビルド 38 のパイプライン ビューです)。

どうすれば同じことを達成できますか?

ジョブをステージにグループ化するためにデリバリー パイプラインプラグインを使用しています。現在、ビュー内の特定の古いパイプライン インスタンスに直接移動するメカニズムはないようです。JobIの特定のビルドをクリックするたびに、パイプラインビューの特定のパイプラインインスタンスに直接リダイレクトされるように、パイプラインの初期ジョブ ( JobI )にメカニズム (おそらくリンク) を提供したかった. また、ビルド パイプラインなどの他のパイプライン プラグインを使用して上記の動作を実現しようとしましたが、解決策はありませんでした。ユーザーが特定のインスタンスにたどり着くためにすべてのインスタンスをスクロールする手間を省けるように、ビューを使いやすくすることが目的です。

「ビューのバージョン」またはそれに類似した「ジョブのビルド」の動作を複製したい。

どんな助け/提案も素晴らしいでしょう。

これはプログラミングに関する質問ではなく、配信パイプラインに関する質問です。

当社の製品は、いくつかの Maven アーティファクトで構築されており、スナップショット (2.0.1-SNAPSHOT) を毎日リリースし、バージョン (2.0.1) を毎週リリースしています。開発中、アーティファクトは他のアーティファクトのスナップショットを使用して完全にテストされ、すべて正常に動作します。多くの場合、アーティファクトは同時に開発されるため、下位互換性なしで相互に依存します

パイプラインの最終段階では、特定のアーティファクトのリリース候補を他のアーティファクトのリリース バージョンでテストするため、アーティファクト B の 2.3.5-SNAPSHOT でテストされ、合格したアーティファクト A の 2.0.1 をリリースしようとしています。 . 合格するとアーティファクトAが解放される（2.0.1-SNAPSHOTが2.0.1になる）

アーティファクト B はまだ 2.3.5 をリリースしていないため (数時間後にリリースされます)、ここで行き止まりになります。したがって、アーティファクト B の 2.3.4 (B の最新リリース) に対してテストされているため、明らかにアーティファクト A はこの段階で失敗します。

すべてのアーティファクトに同じパイプラインがあると仮定しましょう。

要約すると： Artifact A is at 2.0.1-SNAPSHOT attempting to release 2.0.1, its latest release is 2.0.0 Artifact B is at 2.5.2-SNAPSHOT attempting to release 2.5.2, its latest release is 2.5.1

stage 0 test -> A 2.0.0 with B 2.5.1 - PASSED

stage 1 test -> A 2.0.1-SNAPSHOT with B 2.5.2-SNAPSHOT - PASSED

stage 2 test -> A 2.0.1-SNAPSHOT with B 2.5.1- FAILED

B リリース 2.5.2 まで失敗し続けることは理解していますが、配信パイプラインでそれをどのように考慮すればよいでしょうか。アーティファクト A を毎週リリースできるようにしてほしい。

私が探しているのは、配信パイプラインのこの穴を修正することです。パイプラインに別のステージが必要ですか? 収集したスナップショットの別のスナップショットをリリースしますか?