ツールチェーンおよびパイプラインに関する考慮事項

ほとんどのアプリケーションは、異なるソース・リポジトリーを持つ複数のマイクロサービスで構成されています。 通常、論理的にグループ化されたマイクロサービスをホストするために単一のツールチェーンが使用されます。 一般に、1 つのツールチェーンと 1 つのパイプラインを使用するか、可能な限り少数のパイプラインを使用しますが、複数のトリガーを使用します。 各パイプライン内で、必要な数のトリガー (パイプラインごとに最大 1024 個のトリガー) を複製して構成することができます。 この戦略は、共通のプロセス、スクリプト、および構成ファイルを適用するのに役立ちます。 詳しくは、 1 つの CI ツールチェーンでの複数のアプリケーションの構成 を参照してください。

このアプローチには次のような利点がある：

• 使用するパイプラインの数を減らすことで、重複を回避し、エラーを減らすことができます。 また、環境プロパティーまたはシークレットが追加、編集、または削除された場合などにも、更新の保守が容易になります。
• この方法を使用すると、サービスのオンボーディングにかかる時間が短縮されます。 マイクロサービス用の Git 統合を追加し、 Git と手動トリガーを複製し、必要に応じて変更します。 次に、マイクロサービス用に .pipeline-config.yaml ファイルとスクリプトが実装されていることを確認します。

この方法には、以下の欠点があります。

• 1 回の編集で、同じパイプラインを使用しているすべてのチームに影響を与えることができます。
• ユーザー・アクセスは、 Identity and Access Management(IAM) を使用して管理され、パイプライン・レベルではなくツールチェーン・レベルで設定されます。 そのため、複数のサービスに単一のツールチェーンを使用している場合、チームのすべてのメンバーが他のチームのパイプラインを表示できます。 IAM でのユーザーのアクセス権限によっては、パイプラインを編集、削除、またはトリガーできる場合があります。

課金に関する考慮事項

Continuous Delivery サービスは、CDインスタンスごとの認証ユーザー数と、ツールチェーンに使用するリソースグループの数に基づいて課金を決定します。 リポジトリーへのアクセス権限を持つユーザーも、許可ユーザーと見なされます。 詳しくは、許可ユーザーを参照してください。 コストを削減するには、すべてのツールチェーンを同じリソースグループにまとめるか、 Continuous Delivery、企業アカウント階層内で連結課金を構成する必要があります。 詳細については、 連結請求を 参照のこと。

DevSecOpsリポジトリの考慮事項

複数のマイクロサービスで構成されるアプリケーションを作成する場合、ほとんどの場合、DevSecOps証拠リポジトリを除くリポジトリは、マイクロサービス間で共有できます。

詳細については、どうやってDevSecOpsパイプラインはリポジトリを使用する。

IBM Cloud Object Storage の考慮事項

共有インベントリリポジトリを使用している場合は、 IBM Cloud® Object Storage の共有インスタンスも使用できます。 以下のステップを実行します。

1. ツールチェーンおよびパイプライン全体で使用する IBM Cloud Object Storageのインスタンス を作成します。
2. cos-bucket-name 環境プロパティーを設定して、 IBM Cloud Object Storage バケットを使用するようにパイプラインとトリガーをセットアップします (該当する場合)。

同じCI、CD、CCパイプライン内のすべてのマイクロサービスは、デプロイ環境に関係なく、1つの Object Storage バケットを共有します。 Object Storage バケツは証拠保管所と同様の機能を持つが、実質的な証拠保管所で起こりうるパフォーマンスの問題はない。 かなりの Object Storage バケットではパフォーマンスの問題は発生しないので、 Object Storage バケットからエビデンスを刈り込む必要はない。

複数の環境へのデプロイ

CD パイプラインを使用して複数のターゲット環境にデプロイするには、いくつかの方法があります。

各 targeted environment には、在庫リポジトリー内に対応するブランチが必要です。このブランチでは、変更が source ブランチから target ブランチにプロモートされます。

以下のオプション設計は、ご使用のアーキテクチャーに適合する可能性があります。

• ターゲット環境ごとに 1 つの手動トリガーを使用します。 トリガーを複製してから、新しい環境に合わせて環境プロパティーを編集します。
• ターゲット環境ごとに 1 つのフォルダーを持つ Git 構成リポジトリーを使用します。ここで、特定の構成設定がファイルに保管されます。

実行するスクリプトの識別

ステージに対して実行されるスクリプトを識別するには、パイプライン実行 (できれば CI パイプライン) を開きます。 タスクを展開し、 run-stage をクリックしてログを開きます。 run-stage ログの先頭には、ステージで使用されたスクリプトに関する情報 (スクリプトが置かれているリポジトリーを含む) が示されます。 ログをスクロールすると、実行されたスクリプトに関する詳細を確認できます。 例えば、 code-compliance-checks タスクの run-stage ログには、ステージの環境プロパティーを含む以下の情報が記録されている場合があります。

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

この例では、実行されるスクリプトは /opt/commons/compliance-checks/run.sh です。これは、 commons ライブラリー にあります。 このコモンズ・ライブラリーを、特定のエッジ・ケース用にカスタマイズできるコードをコピーするためのソースとして使用します。 この例では、 compliance-checks/run.sh は compliance-commons ライブラリー にあります。

デフォルト・スクリプトのオーバーライド

デフォルトのスクリプトをオーバーライドするには、以下のステップを実行します。

1. ステージ・ログで、デフォルト・スクリプトを識別するスニペットをコピーします。

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

1. スニペットを .pipeline-config.yaml ファイルに貼り付けます。
2. スクリプトが呼び出される前または後にカスタム・コードを追加します。 このスニペットは、デフォルト のコンプライアンスチェックスクリプト を呼び出します
3. 必要に応じて、プロパティーを編集、削除、または追加します。

以下の例は、 .pipeline-config.yaml ファイル内の更新されたスクリプトを示しています。

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

詳しくは、 カスタム・スクリプト を参照してください。