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

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

1. ツールチェーンのパイプライン上でビルドしたいアプリケーションごとに、「 GitHub 」ツールの統合を追加してください。

2. 特定のアプリケーション用に構成できる追加の 問題、 インベントリー、および エビデンス ・リポジトリーの GitHub 統合を追加します。

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

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

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

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

   • Inventory リポジトリは、ビルド記録を保存するための単一の統合リポジトリとして十分です。記録はすでに app-name によって分類されているため、そのパラメータが異なっていれば、記録が失われたり混同されたりすることはありません。 ただし、このリポジトリの主な役割は、継続的デプロイメント・パイプラインにおけるデプロイメントのサポートにあるため、このリポジトリの扱い方については、 インベントリのドキュメントを 参照することをお勧めします。

3. IBM Cloud® Object Storage のバケットを設定します。

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

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

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

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

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

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

   • 既存のトリガーをコピーして、トリガーの作成時に一部のテジウムを保存します。
   • 各トリガーが、必要な GitHub のリポジトリとブランチを指していることを確認してください。
   • 以下のトリガーのプロパティが設定されていることを確認してください：
     • app-name (text): アプリケーション名は、異なるアプリケーション間で固有でなければなりません。 これは、アプリ名がインベントリなどで、アーティファクトと共に配置・記録される際の一意の識別子として使用されるためです。
     • cos-bucket-name (text): アプリケーションの証拠が格納されている「 Object Storage 」バケットの名前。

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

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

3. optional step 各アプリケーションごとに手動トリガーを設定してください。

   • 呼び出し時にプロパティを編集できるため、厳密には手動トリガーは1つだけで済みますが、アプリ間のあらゆる細かい違いをすべて記述する手間を省くために、あらかじめ作成された手動トリガーを用意しておくと、チームにとって役立つかもしれません。

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

   • アプリケーションを頻繁に再ビルドして再検証することは、コンプライアンスや脆弱性の問題、さらにはビルド上の問題についても常に把握しておくために、推奨される手法です。
   • タイマートリガーは、単にタイマーが設定された手動トリガーに過ぎないため、手動トリガーを設定したのと同じ方法でトリガーのプロパティを設定してください。
   • cronジョブの実行タイミングを互いにずらしてください。そうしないと、ワーカークラスターに過負荷がかかり、ジョブのビルド時間が長くなったり、ステージ間の遅延が発生したりする可能性があります。

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