Classic Delivery Pipeline の概要
IBM Cloud® Continuous Delivery には、最小限の人的介入でビルド、テスト、デプロイを反復可能な形で行うための Classic Delivery Pipeline が組み込まれています。 パイプラインでは、一連のステージにより入力内容を取得して、 ビルド、テスト、およびデプロイメントなどのジョブを実行します。
ブラウザーを使用するか、 IBM Cloud CLI Developer Tools (ibmcloud dev) コマンドを使用して、Classic デリバリー・パイプラインと Tekton デリバリー・パイプラインの両方を操作できます。 Tekton パイプライン HTTP API および SDKを使用するか、 IBM Cloud Terraform プロバイダーを使用して、Tekton デリバリー・パイプラインを操作することもできます。 Tekton デリバリー・パイプラインについて詳しくは、
Tekton パイプラインの操作を参照してください。
パイプラインを表示、変更、または実行する権限は、パイプラインを所有するツールチェーンのアクセス制御に基づいています。 ツールチェーンのアクセス制御について詳しくは、 リソース・グループ内のツールチェーンへのアクセスの管理を参照してください。
パイプラインによって提供される各種ジョブ・タイプで実行するスクリプトを指定することによって、ジョブの実行内容を直接制御することができます。 スクリプトは Docker イメージ内で実行されますが、このイメージには IBM Cloud ランタイムと対話するために必要なツールを含む標準開発ツールが多数含まれています。 標準の Docker イメージの内容について詳しくは、あらかじめインストールされているリソースを参照してください。 標準イメージでは利用できない開発ツールがジョブに必要である場合や、同じツールの異なるバージョンが必要である場合は、カスタム・イメージを使用することができます。 カスタム・イメージについて詳しくは、カスタム Docker イメージの操作を参照してください。
パイプラインがスクリプトを実行すると、ジョブが実行されているコンテキストを記述するプロパティーが環境変数を使用してスクリプトに渡されます。 例えば、ステージへの入力であるレポの URL、ステージの名前と実行中のジョブの名前、ジョブ・タイプによって指定されたパラメーターなどが渡されます。 使用可能な環境変数のリストを表示するには、あらかじめインストールされているリソースを参照してください。
プロパティーの定義はパイプライン・レベルとステージ・レベルの両方で行うことができます。 パイプライン・プロパティーは、パイプライン内のすべてのステージとジョブで共有されます。 ステージ・プロパティーは特定のステージに固有で、そのステージのすべてのジョブで共有されます。 プロパティーについて詳しくは、環境プロパティー (環境変数) を参照してください。
ステージ
ステージは、コードのビルド、デプロイ、およびテスト時に、入力内容とジョブを編成します。 ステージは、ソース制御リポジトリーからの入力か、他のステージのビルド・ジョブ (ビルド成果物) からの入力を受け入れます。 SCM リポジトリーの入力内容はリポジトリー内の特定のブランチのコンテンツで、ビルド・ジョブの入力内容はジョブによって作成される成果物です。 最初のステージを作成するときに、 「入力」 タブにはデフォルト設定が指定されています。
ステージが実行されると、ステージの入力内容がステージ内の各ジョブに渡されます。 各ジョブにはクリーンなコンテナーが与えられて、それがジョブの実行場所となります。 そのため、ステージ内のジョブ間で相互に成果物を渡すことはできません。 ジョブ内で成果物を渡すには、ジョブを 2 つのステージに分離し、最初のステージのジョブの出力を 2 番目のステージの入力として使用します。 すべてのビルド・ジョブは、他のステージ内にある他のいずれのジョブにも入力として渡すことができます。 デフォルトで、出力は
./ フォルダー内に作成されます。 ビルド・ジョブからの出力が不要な場合は、フォルダーを出力として構成して、そのフォルダーには出力を送らないようにします。
パイプライン・プロパティーを定義する場合と同様に、特定のステージ内のすべてのジョブで使用するステージ・プロパティーを定義することもできます。 例えば、あるステージのデプロイ・ジョブとテスト・ジョブに URL を渡す TEST_URL プロパティーを定義することができます。 デプロイ・ジョブはその URL にデプロイし、テスト・ジョブはその URL で実行中のアプリをテストします。 ステージ・プロパティーは環境変数を使用してジョブ・スクリプトにも渡されます。
同一のプロパティーがパイプライン・レベルとステージ・レベルの両方で定義されている場合、ステージ・プロパティーの値が使用されます。
デフォルトでは、ステージでは、変更がプロジェクトの SCM リポジトリーに送信されるたびに、ビルドとデプロイメントが自動的に実行されます。 ステージとジョブは順次実行され、作業のフロー制御を可能にします。 例えば、デプロイメント・ステージの前にテスト・ステージを配置すること ができます。 テスト・ステージでテストが失敗した場合には、デプロイメント・ステージは実行されません。
Delivery Pipeline は、パブリック・ワーカーとプライベート・ワーカーを使用してステージ内のジョブを実行します。 デフォルトでは、IBM 管理対象のパブリック共有インフラストラクチャー上ではパブリック・ワーカーを使用してパイプライン・ジョブが実行されます。
特定のシナリオでは、Delivery Pipeline が内部リソースまたはオンプレミス・リソースへのアクセス権を必要とする場合があります。 このような状況の場合、Delivery Pipeline プライベート・ワーカーに接続して統合し、独自の Kubernetes インフラストラクチャー上で実行できます。
特定のステージの制御を厳しくすることができます。 入力時に変更が発生するたびにステージが実行されないようにするには、機能を無効にすることができます。 「入力」 タブの「ステージ・トリガー」セクションで、 「このステージが手動で実行されたときにのみジョブを実行」 をクリックします。
Git リポジトリー入力タイプを使用するステージでは、さらにステージ・トリガー・オプションを使用できます。 例えば、選択したブランチ上の Git イベントに対してジョブを自動的に実行することを選択できます。 このトリガー・タイプを選択する場合、以下のイベント・タイプを 1 つ以上選択する必要があります。
- 「コミットのプッシュ時 (When a commit is pushed)」 では、選択したリポジトリー・ブランチにプッシュが行われる際にトリガーします。
- 「プル・リクエスト/マージ・リクエストのオープンまたは更新時 (When a pull/merge request is opened or updated)」 では、プル・リクエストまたはマージ・リクエストを開いたり編集したりする際にトリガーします。
- 「プル・リクエスト/マージ・リクエストのクローズ時 (When a pull/merge request is closed)」 では、プル・リクエストまたはマージ・リクエストを閉じる際に、関連付けられているコミットがなくてもトリガーします。
「プル・リクエスト/マージ・リクエストのオープンまたは更新時 (When a pull/merge request is opened or updated)」 チェック・ボックスを選択すると、パイプラインの状況が Git リポジトリーに返されます。 プル・リクエストまたはマージ・リクエストによりパイプラインがトリガーされると、ページ上にインライン状況検査が表示されます。 状況検査はパイプライン内で実行されるステージごとに表示され、ステージごとにログと履歴へのリンクが提供されます。 状況検査が実行されるにつれて、保留中から成功または失敗に更新されます。 パイプラインに複数のステージが含まれている場合は、チェックリスト内で各ステージの状況が報告されます。
IBM がホストする GitLab Community Edition ツールでも、マージ・リクエストに対してこの状況フィードバックがサポートされています。
Git ブランチ保護ルールを使用して、状況検査の結果に基づいてマージを制限することもできます。 ブランチ保護ルールの作成後は、必須の状況検査がすべて成功になるまで、マージはすべてブロックされます。
Bitbucket Cloud のプル・リクエスト
現在、Bitbucket Cloud は、Continuous Delivery サービスで必要とされる、プル・リクエストのリポジトリー参照をサポートしていません。 この機能は、refs/pull/123/… という形式の参照を使用して、アクセスしたいリポジトリーにプル・リクエストを送信します。
ソース・リポジトリー URL を使用して、 プル要求をローカルでフェッチしてチェックアウトする ことができます。 ただし、ソース・リポジトリーがプライベート・フォーク・リポジトリーである場合、Continuous Delivery サービスには、プル・リクエストの管理に必要なアクセス権限がありません。 この制限を回避するには、フォーク・リポジトリーに対する必要なアクセス権限をパイプライン・スクリプトで明示的に提供する必要があります。
以下のサンプルの bash パイプライン・スクリプトでは、2 人のユーザーが Bitbucket Cloud を使用しており、それぞれがメイン・リポジトリーのプライベート・フォーク (bitbucket.org/userA/repo-forked-A および bitbucket.org/userB/repo-forked-B) を持っています。 このスクリプトは、その 2 つのフォーク・リポジトリーのいずれかからのプル・リクエストのオープン・イベントまたは更新イベントによってビルド・ジョブがトリガーされたときに、プル・リクエストをチェックアウトするように設定されています。
case "$BITBUCKET_PR_SOURCE_HOST" in #BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
*userA*) #userA should be replaced to anything to identify a forked repo's url
url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST" #you need to provide username and password for repo-forked-A
;;
*userB/repo-forked-B*) #userB/repo-forked-B should be replaced to anything to identify a forked repo's url
url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST" #you need to provide username1 and password1 for repo-forked-B
;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH #BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD
ビルド・ ステージ
ビルド・ステージは、成果物のビルド方法を示す ビルダー・タイプ を指定します。
ビルド・ジョブで使用可能なフィールドの多くは、複数のビルダー・タイプ間で共通です。
以下のビルダー・タイプを使用できます。
| ビルダー・タイプ | 説明 | サポートされるジョブ・タイプ |
|---|---|---|
| シンプル | 現在のステージの入力を、将来のステージで使用するために変更しないでアーカイブします。 通常、このビルダー・タイプは、ステージの入力が SCM リポジトリーからである場合にのみ役立ちます。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。 |
| Ant | Apache Ant ファイルを使用してビルド・ジョブを管理します。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| Container registry | Docker イメージをビルドし、IBM Cloud Container Registry にアップロードします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
API キー: アカウント・リソースへの許可を提供するために使用する IBM Cloud API キー。 Container Registry namespace: ビルドしたイメージを保管する名前空間。 Docker イメージ名: このジョブがビルドし、 IBM Cloud Container Registryにアップロードするイメージの名前。 ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| カスタム Docker イメージ | ノード、 Java™、またはその他のツールのバージョンをきめ細かく制御して、カスタム Docker イメージを使用してビルドします。 | Docker イメージ名: このジョブがビルドし、 IBM Cloud Container Registryにアップロードするイメージの名前。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| Gradle | Gradle を使用してビルドします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー -後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| Grunt | Grunt を使用してビルドします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| Maven | Apache Maven を使用してビルドします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| npm | Node Package Manager を使用して依存関係をインストールします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| シェル・スクリプト | UNIX シェル・スクリプト (Bash など) を実行します。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
ビルド・スクリプト : ジョブが実行されるたびに、新しい Ubuntu シェルで動作します。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー: 後続のステージで使用するためにアーカイブするジョブの出力を含むディレクトリーを指定します。 テスト・レポートを使用可能にする : ビルド・ジョブでテストを実行し、その結果ファイルを JUnit XML 形式で出力するように指定する場合は、このチェック・ボックスにチェック・マークを付けます。 結果ファイルに基づいたレポートが、「ジョブ結果 (Job Results)」ページの「テスト (Tests)」タブに表示されます。 テストが失敗した場合、ジョブは失敗とマーク付けされます。 コード・カバレッジ・レポートを使用可能にする : コード・カバレッジ・レポートに使用できるフィールドを追加して表示する場合は、このチェック・ボックスにチェック・マークを付けます。 カバレッジ・ランナー ( JaCoCo、Cobertura など)、カバレッジ結果ファイルの場所、およびカバレッジ結果ディレクトリーを、作業ディレクトリーに対して相対的に指定することができます。 |
| Gradle (Artifactory、Nexus、または SonarQube) | Gradle を Nexus または Artifactory のリポジトリーと併用してビルドおよびデプロイを行います。 Gradle は SonarQube との統合も行います。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
リポジトリー・ツール統合インスタンス: このビルド・ジョブで使用するリポジトリー・ツール統合インスタンスの名前。 リポジトリー・ツール統合タイプ: Gradle 情報を取得するツール統合のタイプ。 SonarQube 統合インスタンス: このビルド・ジョブで使用する SonarQube 統合インスタンスの名前。 ビルド・コマンド : ジョブの実行時に常に実行されるビルド・コマンド。 「スクリプト」 フィールドに、プロジェクトのソース管理に保管されているスクリプトまたは参照スクリプトを入力します。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー : 後続のステージで使用するためにアーカイブするジョブの出力が含まれるディレクトリーを指定します。 |
| Maven (Artifactory、Nexus、または SonarQube) | Maven を Nexus または Artifactory のリポジトリーと併用してビルドおよびデプロイを行います。 Maven は SonarQube との統合も行います。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
リポジトリー・ツール統合インスタンス: このビルド・ジョブで使用するリポジトリー・ツール統合インスタンスの名前。 リポジトリー・ツール統合タイプ: Gradle 情報を取得するツール統合のタイプ。 SonarQube 統合インスタンス: このビルド・ジョブで使用する SonarQube 統合インスタンスの名前。 ビルド・コマンド : ジョブの実行時に常に実行されるビルド・コマンド。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー : 後続のステージで使用するためにアーカイブするジョブの出力が含まれるディレクトリーを指定します。 |
| npm (Artifactory または Nexus) | npm を Nexus または Artifactory のリポジトリーと併用してビルドを行います。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
リポジトリー・ツール統合インスタンス: このビルド・ジョブで使用するリポジトリー・ツール統合インスタンスの名前。 リポジトリー・ツール統合タイプ: Gradle 情報を取得するツール統合のタイプ。 SonarQube 統合インスタンス: このビルド・ジョブで使用する SonarQube 統合インスタンスの名前。 ビルド・コマンド : ジョブの実行時に常に実行されるビルド・コマンド。 「スクリプト」 フィールドに、プロジェクトのソース管理に保管されているスクリプトまたは参照スクリプトを入力します。 スナップショット・モジュール・バージョンのインクリメント: パブリッシュ・ステップで 作業ディレクトリー: スクリプトが実行されるディレクトリーを指定します。 ビルド・アーカイブ・ディレクトリー : 後続のステージで使用するためにアーカイブするジョブの出力が含まれるディレクトリーを指定します。 |
「デプロイ」ステージ
デプロイ・ステージでは、ビルド・ステージからの入力を指定します。 デプロイ・ステージのジョブでは、 デプロイヤー・タイプ を指定します。 以下のデプロイヤー・タイプを使用できます。
| デプロイヤー・タイプ | 説明 | サポートされるジョブ・タイプ |
|---|---|---|
| カスタム Docker イメージ | ノード、 Java™、またはその他のツールのバージョンをきめ細かく制御して、カスタム Docker イメージを使用してデプロイします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
API キー: アカウント・リソースへの許可を提供するために使用する IBM Cloud API キー。 Docker イメージ名: このジョブがビルドし、 IBM Cloud Container Registryにアップロードするイメージの名前。 デプロイ・スクリプト : ジョブの実行時に常に実行されるデプロイ・コマンド。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 |
| Kubernetes | アプリケーションを Kubernetes クラスター (IBM Cloud Container Service で見つかったものなど) にデプロイします。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
API キー: アカウント・リソースへの許可を提供するために使用する IBM Cloud API キー。 クラスター名: Kubernetes クラスターの名前、つまり Kubernetes コンポーネントをデプロイするプラットフォームの名前。 デプロイ・スクリプト : ジョブの実行時に常に実行されるデプロイ・コマンド。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 |
テスト・ステージ
テスト・ステージは、テスト構成を指定します。 テスト・ステージのジョブでは、 テスター・タイプ を指定します。 以下のテスター・タイプを使用できます。
| テスター・タイプ | 説明 | サポートされるジョブ・タイプ |
|---|---|---|
| シンプル | シェル・コマンドを呼び出して自動化テストを実行し、オプションでテスト・レポートを生成します。 | パイプライン・イメージ・バージョン: 使用されません。
テスト・スクリプト : ジョブの実行時に常に実行されるテスト・コマンド。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: テスト・スクリプトが実行されるディレクトリー。 テスト・レポートの有効化: 使用されません。 コード・カバレッジ・レポートの有効化 : 使用されません。 |
| カスタム Docker イメージ | ノード、 Java™、またはその他のツールのバージョンをきめ細かく制御して、カスタム Docker イメージを使用してテストします。 | Docker イメージ名 : ジョブの実行に使用する Docker イメージの名前。 ジョブがクリーンなコンテキストで実行されるようにするため、それらのジョブを Docker コンテナー内で実行してください。
テスト・スクリプト : ジョブの実行時に常に実行されるテスト・コマンド。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: テスト・スクリプトが実行されるディレクトリー。 テスト・レポートの有効化: 使用されません。 コード・カバレッジ・レポートの有効化 : 使用されません。 |
| Vulnerability Advisor | 指定したイメージに対する準拠性検査と脆弱性検査を実行し、その結果を表示します。 問題が見つかった場合、このステージは失敗します。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
API キー: アカウント・リソースへの許可を提供するために使用する IBM Cloud API キー。 Container Registry 名前空間: ビルドされたイメージが保管される名前空間。 Docker イメージ名 : ジョブの実行に使用する Docker イメージの名前。 ジョブがクリーンなコンテキストで実行されるようにするため、それらのジョブを Docker コンテナー内で実行してください。 Docker イメージ・タグ: IBM Cloud Container Registryに表示される Docker イメージのタグ。 テスト・スクリプト : ジョブの実行時に常に実行されるテスト・コマンド。 スクリプト・フィールドに、プロジェクトのソース・コントロールに保管されるスクリプトまたは参照スクリプトを入力してください。 作業ディレクトリー: テスト・スクリプトが実行されるディレクトリー。 テスト・レポートの有効化: 使用されません。 コード・カバレッジ・レポートの有効化 : 使用されません。 |
| Sauce Labs | Sauce Labs を使用して、 JavaScript、 Node、または Java™ のテストを実行します。 | パイプライン・イメージ・バージョン : さまざまな標準装備コマンドを提供する組み込みの Docker イメージを使用して、コンテナー内で実行されます。 より新しいバージョンのコマンドを導入するには、より新しいイメージ・バージョンを使用してください。
サービス・インスタンス : 構成インスタンスを選択するか、それを作成します。 |
非推奨のジョブ・タイプ
IBM Globalization Pipeline ビルド・ジョブ、スペース・シェル・テスト・ジョブ、 DevOps Insights ゲート・テスト・ジョブなど、いくつかのジョブ・タイプが非推奨になりました。 これらのジョブ・タイプは推奨されませんが、ジョブ・タイプが非推奨とを表示されたインディケーターを使用して、それらを UI にロードできる場合があります。 あるいは、警告通知を出して、まだサポートされている別のジョブ・タイプにジョブを戻すこともできます。
非推奨のジョブ・タイプの構成を使用する必要がある場合は、以下のいずれかの方法を使用してパイプライン構成にアクセスします。
-
IBM Cloud Devtool を使用します:
ic dev pipeline-get 7325f511-492a-4c35-a388-5e499e65d6bb -output JSON -
Delivery Pipeline API を使用します:
curl --location --request GET 'https://devops-api.us-south.devops.cloud.ibm.com/v1/pipeline/pipelines/7325f511-492a-4c35-a388-5e499e65d6bb/stages' \ --header 'Authorization: Bearer <IAM Bearer token> -
Delivery Pipeline UI の ネットワーク タブから、パイプライン ID でフィルタリングして、非推奨のジョブ・タイプ・データが含まれているパイプラインを見つけます。
API キー
一部の標準パイプライン・ジョブは、 IBM Cloud API キーを使用してサービスにアクセスします ( Kubernetesへのデプロイなど)。 IBM Cloud の ID およびアクセス管理 (IAM) サービスでは、以下の 2 つのタイプの API キーを利用できます。
- ユーザー API キー : このタイプの API キーでは、対象ユーザーが利用できるすべてのサービスおよびリソースに対するアクセス権限が完全に提供されます。
- サービス API キー : サービス API キーを構成すると、さまざまなサービスおよびリソースに対する限定的なアクセスを提供できます。
一部のサービスでは、サービス ID API キーを使用できません。 そのような場合は、パイプライン・ユーザー・インターフェースから、ユーザー API キーの指定を求めるプロンプトが出されます。
パイプライン・ジョブは、サービス API キーを任意に使用する可能性があるユーザー作成のスクリプトを実行するため、パイプラインでは、特定のキーに適用する一連の制限を判別することはできません。 そのような場合に、パイプラインで API キーを作成するように要求すると、パイプラインはユーザー API キーを作成します。 堅固なセキュリティーを維持するには、代わりに、スクリプトに必要なサービスおよびリソースのみにアクセス権限が制限されたサービス API キーを使用してください。 その場合は、API キーを手動で作成する必要があります。 API キーの作成について詳しくは、『IBM Cloud API キー』を参照してください。
ジョブ
ジョブは、ステージ内の実行単位です。 ステージには複数のジョブを含めることができ、ステージ内のジョブは順次実行されます。 デフォルトでは、ジョブが失敗すると、ステージ内の以降のジョブは実行されません。
ジョブは、各パイプラインの実行用に作成された Docker コンテナー内にある、個別の作業ディレクトリーで実行されます。 ジョブが実行される前に、ステージ・レベルで定義された入力データがその作業ディレクトリーに取り込まれます。 例えば、テスト・ジョブとデプロイ・ジョブを含むステージがあるとします。 1 つのジョブで依存関係をインストールすると、その依存関係はもう一方のジョブ では使用できません。 ただし、ステージの入力で依存関係を使用可能にすると、どちらのジョブでも使用可能となります。
単純タイプのビルド・ジョブを除き、ジョブを構成する際は、ビルド・コマンド、テスト・コマンド、またはデプロイメントの各コマンドを含む UNIX シェル・スクリプトを含めることができます。 ジョブは暫定のコンテナーで実行されるため、複数のジョブが同じステージ の一部である場合でも、1 つのジョブのアクションが他のジョブの実行環境に影響を与えることはできません。
サンプルのビルド・スクリプトおよびデプロイ・スクリプトは、「 https://github.com/open-toolchain/commons」にあります。
さらに、パイプライン・ジョブは、sudo として次のコマンドのみを実行できます。
/usr/sbin/service/usr/bin/apt-get/usr/bin/apt-key/usr/bin/dpkg/usr/bin/add-apt-repository/opt/IBM/node-v0.10.40-linux-x64/npm/opt/IBM/node-v0.12.7-linux-x64/npm/opt/IBM/node-v4.2.2-linux-x64/npm/usr/bin/Xvfb/usr/bin/pip
ジョブの実行後、そのジョブ用に作成されたコンテナーは破棄されます。 ジョブの実行結果は永続できますが、実行環境は永続しません。
ジョブは最大で 60 分実行することができます。 その限界を超えると、ジョブは失敗します。 ジョブが限界を超える場合は、複数の ジョブに分割してください。 例えば、1 つのジョブが 3 つのタスクを実行する場合、1 つのタスクが 1 つのジョブとなるように、そのジョブを 3 つのジョブに分割することができます。
ジョブをステージに追加する方法については、ジョブのステージへの追加を参照してください。
ビルド・ジョブ
ビルド・ジョブは、デプロイメントに備えてプロジェクトをコンパイルします。 ビルド・ジョブは、ビルド・アーカイブ・ディレクトリーに送信することができる成果物を生成しますが、デフォルトで成果物はプロジェクトのルート・ディレクトリーに配置されます。
ビルド・ジョブからの入力データを取得するジョブは、ジョブが作成されたのと同じ構造のビルド成果物を参照する必要があります。 例えば、ビルド・ジョブがビルド成果物を output ディレクトリーにアーカイブする場合、デプロイ・スクリプトは、プロジェクトのルート・ディレクトリーではなく output ディレクトリーを参照して、コンパイルされたプロジェクトをデプロイします。 「ビルド・アーカイブ・ディレクトリー」 フィールドにディレクトリー名を入力することにより、アーカイブするディレクトリーを指定できます。 このフィールドをブランクにしておくと、ルート・ディレクトリーにアーカイブされます。
シンプル ・ビルダー・タイプを使用する場合は、コードのコンパイルはビルドは行われません。パッケージ化され、今後のステージで使用できる状態になります。
デプロイ・ジョブ
デプロイ・ジョブは、プロジェクトをアプリとして IBM Cloud にアップロードし、URL からアクセス可能です。 プロジェクトのデプロイ後は、デプロイされたアプリを IBM Cloud ダッシュボードで検索することができます。
デプロイ・ジョブは、新規アプリをデプロイすることも、既存アプリを更新することもできます。 最初に別の方法でアプリをデプロイした場合でも、デプロイ・ジョブを使用してアプリを更新できます。 デプロイ・ジョブでアプリを更新するには、アプリの名前を使用します。
1 つ以上のリージョンやサービスにデプロイできます。 例えば、1 つ以上のサービスを使用して、1 つのリージョンでテストし、複数のリージョンで実動にデプロイするよう Delivery Pipeline をセットアップできます。
テスト・ジョブ
条件を満たすことが必要な場合は、ビルド・ジョブおよびデプロイ・ジョブの前または後にテスト・ジョブを組み込みます。 必要に応じて、テスト・ジョブを単純タイプまた は複雑タイプにカスタマイズすることができます。 例えば、cURL コマンドを実行して特定の応答を予期することができます。 また、一連の単体テストを実行したり、Sauce Labs などサード・パーティーのテスト・サービスを使用して機能テストを実行したりすることもできます。
テストの結果ファイルが JUnit XML 形式の場合、結果ファイルに基づいたレポートが各テスト結果ページの 「テスト」 タブに表示されます。 テストが不合格の場合は、ジョブも失敗します。
環境プロパティー (環境変数)
事前定義された一式の環境プロパティーは、ジョブの実行環境に関する情報へのアクセスを提供します。 事前定義された環境プロパティーの完全なリストについては、環境プロパティーとリソースを参照してください。
独自の環境プロパティーを定義することも可能です。 例えば、パイプライン内のすべてのスクリプトで IBM Cloud リソースにアクセスするために使用される API 鍵を渡す API_KEY プロパティーを定義することができます。
以下のタイプのプロパティーを追加できます。
- 「テキスト」 : 単一行の値を持つプロパティー・キー。
- 「テキスト域 (Text Area)」 : 複数行の値を持つプロパティー・キー。 各テキスト域のプロパティー値の base64 バージョンも使用できます。 末尾に
_base641サフィックスが付いたプロパティー・キー名を使用して、このバージョンにアクセスできます。 テキスト域プロパティーの base64 バージョンをデコードし、echo "$(echo $multi_base64 | base64 -d)"と入力してエコーできます。multiは定義したプロパティー・キー名で、multi_base64は提供された追加のプロパティーです。 パイプラインの基本イメージには、複数行のエンコーディングを透過的に管理するための組み込みサポートが含まれています。 ただし、カスタム・イメージを使用する場合は、_base64サフィックス・プロパティーを追加して、値が行末で切り捨てられる問題を回避する必要があります。 - 「セキュア」 : AES-128 暗号化で保護された単一行の値を持つプロパティー・キー。 値はアスタリスクとして表示されます。
- 「プロパティー (Properties)」 : プロジェクトのリポジトリーにあるファイル。 このファイルには、複数のプロパティーを含めることができます。 プロパティーはそれぞれ独自の行で指定されている必要があります。 キーと値のペアを区切るには、等号 (=) を使用します。 すべてのストリング値を引用符で囲んでください。 例えば、
MY_STRING="SOME STRING VALUE"です。
パイプライン・ジョブの環境プロパティーを調べるには、ジョブのスクリプトで env コマンドを実行します。
パイプライン・プロパティー
パイプライン・プロパティーを定義するには、「パイプライン」ページのオーバーフロー・メニューから、 「パイプラインの構成」 を選択します。
「パイプライン構成」ページの 「環境プロパティー」 タブから、パイプライン・レベルの環境プロパティーを設定します。
ステージ・プロパティー
ステージ・プロパティーを定義するには、「ステージ構成」ページで 「環境プロパティー」 タブをクリックします。
ステージ・プロパティーを定義するには、初期値 (またはブランク値) を使用してから、環境変数をエクスポートしてジョブ内のその値をオーバーライドします。 初期値をオーバーライドすることにより、ステージ内の後続のジョブでは新しい値を参照できます。 例えば、以下のコマンドを組み込んで、 $API_KEY プロパティーを設定し、ステージ内の別のジョブで使用できるようにすることができます。 export API_KEY=<insert API key here>
算出 (Computed) プロパティー
ステージを実行中に環境プロパティー値を計算し、build.properties ファイルを作成してステージ間で共有できるようにし、次のステージでそのファイルを実行することができます。 例えば、ビルド・ジョブで次のコマンドをビルド・スクリプトに組み込むことができます。
echo "IMAGE_NAME=${FULL_REPOSITORY_NAME}" >> $ARCHIVE_DIR/build.properties
build.properties ファイルがある場合は、それを実行することですべてのジョブが開始されます。
成果物の作成および使用
ビルド・ジョブは、ユーザー・スクリプトが実行される現在のフォルダー内のコンテンツを自動的に取り出します。 後のデプロイメントで git リポジトリー全体を必要としない場合は、明示的な出力ディレクトリーを構成し、そこに関連成果物をコピーまたは作成することをお勧めします。 ジョブ・スクリプトはビルド結果 (出力ディレクトリー) で実行されます。
IBM Cloud Kubernetes Service にデプロイされるデプロイ・ジョブを権限ジョブが実行されているユーザーのプラットフォーム API キー、Dockerfile、およびオプションの Helm チャートを指定する必要があります。
ジョブ・スクリプトは、ジョブがターゲット環境にログインした後に、ターゲット環境に割り当てられたプラットフォーム API キーを使用することで実行されます (それにより、スクリプトで cf push コマンドまたは kubectl コマンドを実行できます)。
サンプル・パイプライン
サンプル・パイプラインには次の 3 つのステージを含めることができます。
- アプリのビルド・プロセスをコンパイルして実行するビルド・ステージ。
- アプリのインスタンスをデプロイして、それに対してテストを実行するテスト・ステージ。
- テスト済みのアプリの実動インスタンスをデプロイする実動ステージ。
次の概念図に、このパイプラインを示しています。
各ステージは、その入力データをリポジトリーとビルド・ジョブから取り出し、ステージ内のジョブは、互いに独立して順次実行されます。 サンプル・パイプラインでは、テスト・ステージと実動ステージの両方がビルド・ステージの出力を入力データとして使用する場合でも、ステージは順次実行されます。