ツールチェーンのカスタマイズ

ツールチェーンをカスタマイズするには、ツールチェーンを複数のアプリに追加し、その機能を向上させます。 手順は次のとおりです。

1. ツールチェーンパイプライン上で構築したい各アプリケーションに対して、ツール統合を追加 GitHub してください。
2. 特定のアプリケーション用に構成できる追加の 問題、 インベントリー、および エビデンス ・リポジトリーの GitHub 統合を追加します。

• アプリケーションにこれらの追加のリポジトリーが必要かどうかは、文書ページおよびベスト・プラクティスを参照して判断してください。

• サブシステムとは、相互に依存し、一緒に開発および展開される関連サービスのグループである。

  • 単一サブシステム内のサービスは、共通のインベントリリポジトリと証拠保管庫を共有しなければならない。 各サブシステムは、そのインベントリリポジトリと証拠保管庫の間で1対1の関係を維持しなければならない。 複数のロッカーにまたがる証拠の検索はサポートされていません。検索範囲が拡大し、データの矛盾リスクが高まるためです。
  • 複数のサブシステムをグループ化して、同じ共有インベントリとロッカーを使用することもできます。
  • 例： 関連するサービス（例： auth と user-profile）を1つのサブシステムにまとめる。 このモデルは、環境 Continuous Delivery におけるスケーラブルなマイクロサービス管理をサポートします。

• アプリケーションリポジトリは、それ自体の課題リポジトリとしても機能します。 これは、ツール統合で GitHub 問題オプションが有効になっている場合にのみ適用されます。

• インベントリリポジトリは、ビルド記録を単一の統合リポジトリとして記録するのに十分である。記録は既に で区切られているため、その app-name パラメータが異なる限り、何も失われたり混乱したりすることはない。 このリポジトリの扱い方については、 インベントリドキュメント を参照することをお勧めします。その主な機能は、継続的デプロイメントパイプラインにおけるデプロイメントのサポートを補助することにあるためです。

1. バケット IBM Cloud® Object Storage を設定する。

   IBM Cloud Object Storage は、パイプライン・エビデンス成果物のための推奨のエビデンス・ロッカー・メソッドであり、監査コンプライアンスに必要です。 CI ツールチェーンに取り込むアプリケーションごとに同じ Object Storage バケットを使用します。 また、CI ツールチェーンを CD または CC ツールチェーンと統合する場合は、同じ Object Storage バケットを再利用してください。

2. オプション: 追加の Hashicorp Vault 統合。

   HashiCorp Vault ツール統合は 1 つのパスのみをサポートするため、 HashiCorp Vault シークレットの構成方法によっては、さらに多くのパスが必要になる場合があります。 アプリケーションによっては、相互に異なる資格情報または他の資格情報が必要になる場合があります。

CIおよびPRパイプラインのカスタマイズ

以下のステップを使用して CI および PR パイプラインを構成することにより、それらをカスタマイズします。

1. 各アプリケーション用の Git トリガーを作成します。

   • 既存のトリガーをコピーして、トリガーの作成時に一部のテジウムを保存します。
   • 各トリガーが指定された GitHub リポジトリとブランチを指していることを確認してください。
   • 以下のトリガープロパティが設定されていることを確認してください：
     • app-name (text): アプリケーション名は、異なるアプリケーション間で固有でなければなりません。 これは、アプリ名が、成果物とともに配置および記録されるときに、インベントリー、 DevOps 洞察、およびその他のもので固有 ID として使用されるためです。
     • cos-bucket-name アプリケーションの証拠が格納 Object Storage されるバケットの名前。

2. アプリケーションごとに環境プロパティーが変更されます。

   • 以下は、アプリケーションごとに別の値に変更する必要があると考えられる環境プロパティーのリストです。 これは、パイプライントリガーのトリガープロパティを使用することで実現できます。これにより、環境プロパティがユーザー自身が選択した値で上書きされます。
     • app-name アプリ名は、異なるアプリケーション間で常に一意である必要があります。これは、アセットの配置や記録時に、 DevOps インベントリやインサイトなどで一意の識別子としてアプリ名が使用されるためです。
     • cos-bucket-name アプリケーションの証拠が格納 Object Storage されるバケットの名前。
     • repository (テキスト): このパラメーターは、さまざまなコンプライアンスおよびセキュリティーのタスクのために、どのアプリケーション・リポジトリーがパイプラインに複製されて CI および PR のパイプラインのターゲットとして機能するのかを制御します。
     • オプション: evidence-repo (テキスト): アプリケーションの証拠保管 URL 庫として機能するリポジトリの。
     • オプション: incident-repo (テキスト): アプリケーションの課題 URL リポジトリとして機能するリポジトリの。
     • オプション: inventory-repo (テキスト): アプリケーションの URL インベントリリポジトリとして機能するリポジトリの。

3. optional step 各アプリケーションに対して手動トリガーを設定します。

   • 技術的には手動トリガーは1つだけで十分です。そのプロパティは呼び出し時に編集できるためです。しかし、チームが事前に作成した手動トリガーを用意しておくと、アプリ間のあらゆる細かい差異を記述する手間を省けるため有用かもしれません。

4. optional step アプリケーション用にタイマートリガーを作成します。

   • アプリケーションを頻繁に再構築し再検証することは良い慣行です。これにより、コンプライアンスや脆弱性に関する問題、およびビルド上の問題に対処し続けることができます。
   • 手動トリガーを設定したのと同じ方法でトリガープロパティを設定してください。タイマートリガーは、単にタイマーで動作する手動トリガーだからです。
   • cronジョブは互いに間隔を空けて実行してください。そうしないとワーカークラスターに負荷がかかり、ジョブのビルド時間が長くなったり、ステージ間の遅延が発生する可能性があります。

パイプライン トリガーまたは環境プロパティ内で設定可能なその他のプロパティについては、 パイプライン パラメーター カタログ を参照してください。