Cloud Build を使用して Salesforce 用のサーバーレス DevOps パイプラインを構築する

アーキテクチャ

次の図は、このチュートリアルで作成する CI / CD ワークフローのアーキテクチャを示しています。このアーキテクチャでは、プロジェクトはリリースとして整理されます。機能に取り組む開発者は、リリース ブランチから新しい機能ブランチを作成します。

この図は次のフローを示しています。

1. 開発者は、開発している機能に関して GitHub に機能ブランチを作成します。
2. 開発者は、開発作業を完了したら、Salesforce のスクラッチ組織で単体テストを行います。
3. 開発者は、開発作業を commit し、ソースコード リポジトリ（このチュートリアルでは GitHub）に push します。
4. 開発者は、作業をリリース ブランチにマージする pull リクエストを作成します。
5. pull リクエストが作成されると、テストを実行する Cloud Build ジョブが自動的にトリガーされます。
6. 担当者（通常はチームリーダー）は、pull リクエストを確認して承認し、開発作業をリリース ブランチにマージします。
7. リリース ブランチへのマージにより、コードベースを QA などの Salesforce 環境にデプロイする Cloud Build ジョブが自動的にトリガーされます。
8. 必要に応じて、QA 環境で手動のテストとレビューが実施されます。
9. 担当者は、コードを main ブランチにマージする pull リクエストを作成します。
10. main ブランチへの pull リクエストにより、コードを本番環境にデプロイする Cloud Build ジョブがトリガーされます。

プロジェクトに取り組む開発者は、最初にエンタープライズ ソース管理ツール（このチュートリアルでは GitHub）からプロジェクト リポジトリのクローンを作成します。次の図は、この戦略をグラフで表したものです。

図に示すように、ブランチ戦略は次のものから構成されます。

1. メインブランチ。メインブランチのコードは、本番環境で実行されているコードの現在のバージョンを反映しています。
2. リリース ブランチ。リリース ブランチは、（機能ブランチと比較して）比較的存続期間が長いブランチで、リリースに関連するすべての変更とコードを調整します。組織は、新しいリリースごとに新しいリリース ブランチを作成します。
3. 1 つ以上の機能ブランチ。機能ブランチは、進行中の作業をメインブランチ内の最新バージョンのコードから分離するのに役立ちます。通常、複数の機能ブランチが 1 つのリリース ブランチを構成します。バグの修正のために、開発者が機能ブランチを作成することをおすすめします。

開発者は、プロジェクト リポジトリのクローンを作成した後に、ローカルマシンまたは Salesforce のスクラッチ組織で開発を行います。スクラッチ組織を使用して、変更内容の単体テストを行えます。単体テストに合格すると、コードを commit し、ソースコード リポジトリに push します。次に、コードを親のリリース ブランチにマージする pull リクエストを作成します。

pull リクエストによって、次の処理を行う Cloud Build ジョブが自動的にトリガーされます。

• 単体テストを行うためのスクラッチ組織を新しく作成する。
• テスト結果を受けて pull リクエストを更新する。

この時点で、チームリーダーとプロダクト オーナーは pull リクエストを確認できます。リクエストが承認されると、変更がリリース ブランチにマージされます。

ソフトウェア開発ライフサイクルに応じて、リリース ブランチへのマージによりトリガーされる別の自動ステップを備えることができます。自動ステップの例に、品質保証またはシステム インテグレーション テストなどの上位サンドボックスへの検証済みのコードのデプロイがあります。

また、Cloud Functions や Cloud Run などの Google Cloud ツールを使用し、ビルド通知の送信などの追加アクションを行うように Cloud Build を構成できます（このチュートリアルでは、これらの追加アクションについては説明しません）。この手法により、自社のエンタープライズ DevOps フレームワークに合わせてパイプラインを柔軟にカスタマイズできます。

わかりやすくするため、このチュートリアルでは、サンプル コードベースを単一の Salesforce 組織（Dev Hub）にデプロイします。本番環境用の CI / CD パイプラインを構築すると、前述のアーキテクチャを使用して、ソフトウェア開発ライフサイクルの一部であるサンドボックスへのデプロイを自動化できます。

通常ソフトウェア開発に関わるペルソナ

組織はすべて異なっており、それぞれが独自の構成で役割とチームを備えています。下の表に、このチュートリアルで説明するような Salesforce DevOps パイプラインとインタラクションを行う主要なペルソナ（役割）を示します。

Salesforce パイプラインの設定に関する各役割の責任は異なります。そのため、このチュートリアルには 2 つの道筋があります。一方の道筋は管理者と DevOps リード向けで、もう一方の道筋は開発者向けです。

Salesforce 管理者および DevOps リード用のパイプラインを設定する

このセクションでは、管理者と DevOps のチームが CI / CD ワークフローを設定するために行う必要がある作業について説明します。

Dev Hub 組織を有効にする

1. Salesforce 本番組織にログインします。

2. [設定] タブの [クイック検索] ボックスに「Dev Hub」と入力し、[Dev Hub] を選択します。

   

3. Dev Hub を有効にします。

   このステップでは、スクラッチ組織を設定します。スクラッチ組織を使用して、このチュートリアルのサンプルコードを Salesforce Developer Edition 組織にデプロイします。

証明書と鍵のペアを作成する

Dev Hub 組織を有効にした後、Salesforce Dev Hub 組織の認証に使用できる証明書と鍵のペアを生成する必要があります。この証明書と鍵のペアは、後のステップで Cloud Build を構成する際に使用します。

本番環境の CI / CD パイプラインの場合は、Salesforce サンドボックスの認証用に追加の証明書を生成する必要があります（このチュートリアルでは、これらの追加証明書は作成しません）。各環境の証明書と鍵のペアを生成するときは、次の例のように、識別可能な名前を付けてください。

• 本番環境（Dev Hub 組織）: salesforce.key と salesforce.crt。これらの名前は次の手順で使用します。
• 品質保証サンドボックス（QA）: salesforce_qa.key と salesforce_qa.crt。
• 統合開発サンドボックス（IDEV）: salesforce_dev.key と salesforce_dev.crt。

証明書と鍵のペアの生成手順は次のとおりです。

1. Cloud Shell で、証明書と鍵のペアを生成し、Cloud Build が Salesforce CLI から Salesforce Dev Hub 組織に対して認証できるようにします。

   openssl req -x509 -sha256 -nodes -days 36500 -newkey \
   rsa:2048 -keyout salesforce.key -out \
   salesforce.crt
   

   証明書を識別する詳細情報の入力を求められます。このチュートリアルでは、これらの値は重要でないため、Enter キーを押してデフォルト値を受け入れます。

   このコマンドでは、salesforce.key と salesforce.crt という名前を使用していることに注意してください。これは、Dev Hub 組織の証明書と鍵のペアを作成しているためです。

2. [さらに表示] をクリックして、[ファイルをダウンロード] を選択します。

3. [完全修飾ファイルパス] ボックスに、次のファイル名を入力し、[ダウンロード] をクリックします。

   salesforce.crt
   

   生成された証明書がローカルマシンにダウンロードされます。次のセクションで、証明書を Salesforce 組織にアップロードします。

Salesforce で接続アプリを作成する

このセクションでは、Cloud Build が Salesforce コードのデプロイに使用できる接続アプリケーションを作成します。このチュートリアルでは、Dev Hub 組織にのみコードをデプロイします。本番環境では、Cloud Build に DevOps パイプライン用の Salesforce コードをデプロイさせたい各サンドボックスと本番組織に対して、コードをデプロイします。

このプロセスの一部として、前のセクションで生成した証明書と鍵のペアを使用します。この証明書は、Cloud Shell セッションで Salesforce Dev Hub 組織（Salesforce サンドボックス）に対して Salesforce クライアントを認証するための公開鍵です。この証明書は、自動デプロイでの Cloud Build の認証にも使用されます。

以下の手順の一部は、ご利用の Salesforce のエディションによって細部が異なります。選択した環境に応じた正しい証明書と鍵のペアを使用してください。

1. Salesforce Lightning Experience を使用している場合、アプリ マネージャーを使用して接続アプリを作成します。Salesforce 組織の [設定] から次の操作を行います。

   1. [クイック検索] ボックスに「App」と入力します。
   2. [アプリケーション マネージャー] を選択します。
   3. [新規接続アプリケーション] をクリックします。

   Salesforce Classic を使用している場合、Salesforce 組織の設定から次の操作を行います。

   1. [クイック検索] ボックスに「Apps」と入力します。
   2. [ビルド] > [作成] で [アプリケーション] を選択します。
   3. [接続アプリケーション] で [新規] をクリックします。

2. アプリケーションの名前には、「Google Cloud DevOps」と入力します。

   これにより、[API 名] ボックスに「Google_Cloud_DevOps」と表示されます。

3. 連絡先メール情報とアプリケーションに適切なその他の情報を入力します。

4. [OAuth 設定の有効化] を選択します。

5. [コールバック URL] の値として次の URL を入力します。

   http://localhost:1717/OauthRedirect
   

6. デジタル署名を使用するオプションを有効にするには、[ファイルを選択] をクリックし、以前にダウンロードした salesforce.crt ファイルを選択します。

7. [選択した OAuth 範囲] に次の OAuth 範囲を追加します。

   • データにアクセスして管理する（api）
   • 随時ユーザーに代わってリクエストを実行する（refresh_token、offline_access）
   • ウェブ経由でデータにアクセスする（web）

   

8. [保存] をクリックし、[続行] をクリックします。

9. API セクションに表示される [コンシューマ鍵] の値を書き留めます。これは、後に Cloud Build マニフェストを設定するときに必要になります。

   本番環境で作業している場合、デプロイ環境ごとに鍵があります。

10. [管理] をクリックし、OAuth ポリシーを変更するため、[ポリシーを編集] をクリックします。

11. [許可されているユーザー] を [管理者が承認したユーザーは事前承認済み] に設定し、この選択を確定します。

12. [IP 制限の緩和] を [IP 制限の緩和] に設定します。

13. [保存] をクリックします。

14. [プロファイルの管理] をクリックし、[システム管理者] オプションを選択します。

    この手順を終えると、このプロファイルを持つユーザーは Salesforce CLI にログインできます。

15. [保存] をクリックします。

Google Cloud 環境を初期化する

1. Cloud Shell で、デフォルト プロジェクトとして作成または選択したプロジェクトを設定します。

   gcloud config set project PROJECT_ID
   

   PROJECT_ID は、Google Cloud プロジェクトの ID に置き換えます。

2. リージョンとゾーンを設定します。

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-a
   

   このチュートリアルでは、リージョンとして us-central1 を使用し、ゾーンとして us-central1-a を使用します。

3. 現在の Google プロジェクト ID を GCP_PROJECT_NUMBER という名前の環境変数にエクスポートします。

   export GCP_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
   

Salesforce の鍵を Cloud Storage にアップロードする

1. Cloud Shell で、ビルド プロジェクトに Salesforce 秘密鍵ファイルを保存する Cloud Storage バケットを作成します。

   gsutil mb -p ${DEVSHELL_PROJECT_ID} -l us-central1 \
       gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
   

   バケットにはグローバルに一意の名前が必要です。このコマンドは、Google Cloud プロジェクト ID を含むバケット名を作成します。

2. Dev Hub 組織を有効にするセクションで生成した Salesforce 秘密鍵を新しい Cloud Storage バケットにコピーします。

   gsutil cp salesforce.key gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
   

GitHub リポジトリを作成する

1. Cloud Shell で、このチュートリアルに関連付けられているリポジトリのクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/salesforce-serverless-cicd-cloudbuild
   

2. DEV_REPO_NAME という名前の新しい GitHub リポジトリを作成します。

   DEV_REPO_NAME は、ローカルでリポジトリに割り当てる名前に置き換えます。

   これは、開発者がコードを pull または push するリポジトリです。このチュートリアルでは、このリポジトリを自分の GitHub アカウントに作成します。

3. クローン リポジトリに移動します。

   cd salesforce-serverless-cicd-cloudbuild
   

4. 開発者の GitHub リポジトリをリモート リポジトリとして追加します。

   git remote add github DEV_REPO_NAME
   

Cloud Build を構成する

このセクションでは、作業をリリース ブランチにマージする pull リクエストを開発者が作成したときに Cloud Build ジョブをトリガーするために必要な設定を、手順に沿って行います。

このチュートリアルで作成する CI / CD パイプラインに対し、次の 2 つのトリガーを設定します。

• コードをリリース ブランチにマージする pull リクエストを開発者が作成したときに Cloud Build ジョブを実行するトリガー。このトリガーは通常、単体テストを行うために使用されます。
• pull リクエストがリリース ブランチにマージされたときに Cloud Build ジョブを実行するトリガー。このトリガーは通常、宛先サンドボックス（このチュートリアルでは Dev Hub）に変更をデプロイするために使用されます。

Salesforce DX を含むベースイメージをビルドする

Cloud Build は、ビルドを一連のステップとして実行し、各ステップは Docker コンテナ内で実行されます。Salesforce CLI を含むベース Docker コンテナ イメージをビルドします。Cloud Build は Salesforce CLI コマンドを使用してジョブを実行します。

1. Cloud Shell で、ビルドするイメージの Dockerfile を作成します。

   cat <<EOF > Dockerfile
   FROM debian:buster
   RUN apt-get update && \
   apt-get install -y wget xz-utils
   RUN wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz && \
   mkdir sfdx && \
   tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1 && \
   ./sfdx/install
   ENTRYPOINT [ "sfdx" ]
   EOF
   

2. Docker イメージ名を SFDX_BASE_IMAGE という名前の環境変数にエクスポートします。

   export SFDX_BASE_IMAGE="gcr.io/${DEVSHELL_PROJECT_ID}/salesforcedx-base-image:1"
   

3. Cloud Build でコンテナをビルドし、イメージを Container Registry に公開します。

   gcloud builds submit --tag ${SFDX_BASE_IMAGE}
   

Cloud Build ジョブを構成する

Cloud Build ジョブは、cloudbuild.yaml ファイルを編集して定義します。

1. Cloud Shell で cloudbuild.yaml ファイルを作成し、Cloud Build が Salesforce の Dev Hub 組織にコードをデプロイするときに実行されるジョブステップを定義します。

   cat <<EOF > cloudbuild.yaml
   steps:
   - name: gcr.io/cloud-builders/gsutil
     args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
   - name: "${SFDX_BASE_IMAGE}"
     args:
     - force:auth:jwt:grant
     - --setdefaultusername
     - -u
     - \${_SF_USERNAME}
     - -f
     - ./salesforce.key
     - -i
     - \${_CONSUMER_KEY}
   - name: "${SFDX_BASE_IMAGE}"
     args: ['force:source:deploy', '-p', './force-app/']
   substitutions:
     _BUCKET_NAME: __BUCKET_NAME__
     _SF_USERNAME: __USERNAME__
     _CONSUMER_KEY: __CONSUMER_KEY__
   EOF
   

   このファイルにより、次の処理を行う Cloud Build が構成されます。

   1. Cloud Build が Dev Hub 組織の認証に使用する salesforce.key ファイルをダウンロードする。
   2. Salesforce CLI がインストールされている Docker コンテナを起動し、JWT 付与を使用して Dev Hub 組織に接続する。Cloud Build は、Cloud Build トリガー定義に含まれる構成パラメータであるコンシューマ鍵や Salesforce ユーザー名などを使用します。
   3. 開発者が push したコードを、本番環境の CI / CD パイプラインの Dev Hub 組織または他の宛先サンドボックスにデプロイする。

2. cloudbuild_pr.yaml という別のファイルを作成し、Cloud Build が pull リクエストのコードを一時的な Salesforce スクラッチ組織またはサンドボックスにテスト用にデプロイするときに実行されるジョブステップを定義します。

   cat <<EOF > cloudbuild_pr.yaml
   steps:
   - name: gcr.io/cloud-builders/gsutil
     args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
   - name: "${SFDX_BASE_IMAGE}"
     args:
     - force:auth:jwt:grant
     - -u
     - \${_SF_USERNAME}
     - -f
     - ./salesforce.key
     - -i
     - \${_CONSUMER_KEY}
   - name: "${SFDX_BASE_IMAGE}"
     args:
     - force:org:create
     - --setdefaultusername
     - --definitionfile
     - config/project-scratch-def.json
     - --targetdevhubusername
     - \${_SF_USERNAME}
     - --setalias
     - testing org
   - name: "${SFDX_BASE_IMAGE}"
     args: ['force:source:push']
   - name: "${SFDX_BASE_IMAGE}"
     args: ['force:apex:test:run', '--resultformat', 'tap', '--codecoverage']
   - name: "${SFDX_BASE_IMAGE}"
     args: ['force:org:delete', '--noprompt']
   substitutions:
     _BUCKET_NAME: __BUCKET_NAME__
     _SF_USERNAME: __USERNAME__
     _CONSUMER_KEY: __CONSUMER_KEY__
   EOF
   

   このファイルにより、次の処理を行う Cloud Build が構成されます。

   1. Cloud Build が Dev Hub 組織の認証に使用する salesforce.key ファイルをダウンロードする。
   2. Salesforce DX CLI がインストールされている Docker コンテナを起動し、JWT 付与を使用して Dev Hub 組織に接続する。Cloud Build は、Cloud Build トリガー定義に含まれる構成パラメータであるコンシューマ鍵や Salesforce ユーザー名などを使用します。
   3. 開発者の自動テスト用コードをデプロイするための新しいスクラッチ組織を作成する。
   4. スクラッチ組織で Apex テキストを実行する。
   5. Apex テキストの結果を出力する。この結果は、GitHub の pull リクエストのサマリーで使用できるようになります。
   6. 一時的なスクラッチ組織を削除する。

リポジトリを GitHub に push する

1. Cloud Shell で、新しい cloudbuild yaml ファイルと Dockerfile をリポジトリに add し、DEV_REPO_NAME リポジトリのメインブランチに push します。GitHub へのログインを求められたら、ログインします。

   git add .
   git commit -m "Added cloud build configuration"
   git push github main
   

2. 開発者がコードを pull または push できるリリース ブランチを作成します。このチュートリアルでは、そのブランチに release-sample という名前を付けます。

   git checkout -b release-sample
   

3. ブランチを GitHub に push します。

   git push github release-sample
   

GitHub リポジトリを Cloud Build に接続する

1. GitHub マーケットプレイスの [Cloud Build Application] ページに移動します。
2. 下にスクロールし、[Setup with Google Cloud Build] をクリックします。GitHub へのログインを求められたら、ログインします。
3. リポジトリを Cloud Build に接続します。
   1. [Only select repositories] を選択します。
   2. [Select repositories] リストで、[repository] を選択します。
4. [Install] をクリックします。

5. Google Cloud にログインします。

   [Authorization] ページが表示され、Google Cloud Build アプリケーションが Google Cloud に接続するのを認可するよう求められます。

6. [Authorize Google Cloud Build by GoogleCloudBuild] をクリックします。

   Google Cloud コンソールにリダイレクトされます。

7. Google Cloud プロジェクトを選択します。

8. 利用規約に同意する場合は、同意し、[次へ] をクリックします。

9. [リポジトリを選択] ページで DEV_REPO_NAME GitHub リポジトリを選択します。

10. [リポジトリを接続] をクリックします。

11. [push トリガーを作成] をクリックします。

Cloud Build トリガー定義を更新する

前のセクションで [push トリガーを作成] をクリックしたときに作成された新しいトリガーの詳細を定義します。

1. Google Cloud コンソールで、[Cloud Build トリガー] ページを開きます。

   [Cloud Build トリガー] ページに移動

2. 新しいトリガーの more_vert [メニュー] をクリックし、[編集] をクリックします。

3. [名前] を pull-request-to-release-branch に設定します。

4. 説明を Run unit tests when a pull request is created from a feature branch に変更します。

5. [イベント] を [pull リクエスト（GitHub アプリのみ）] に変更します。

6. [ソース] の [ベースブランチ] テキスト ボックスに、次の式を入力します。

   ^release.*
   

7. [構成] で、[Cloud Build 構成ファイル（yaml または json）] を選択し、テキスト ボックスに「cloudbuild_pr.yaml」と入力します。

8. [代入変数] で、3 つの変数を作成します。変数ごとに、次の操作を行います。

   1. [項目を追加] をクリックします。

   2. [変数] フィールドと [値] フィールドを、次の表に示すように設定します。

      変数	値
      _BUCKET_NAME	Salesforce 鍵ファイルの Cloud Storage バケットの名前。次の形式になります。 salesforce-ref-PROJECT_ID PROJECT_ID は実際の Google Cloud プロジェクトの ID に置き換えます。
      _CONSUMER_KEY	Salesforce の Dev Hub 組織で作成した接続アプリケーションのコンシューマ鍵。
      _SF_USERNAME	Dev Hub 組織の Salesforce ユーザー名。

9. [保存] をクリックします。

   このページを閉じないでください。次の手順では、このページでさらに作業を行います。

2 つ目の Cloud Build トリガーを作成する

次のステップは、リリース ブランチに commit が行われたときに Cloud Build ジョブを開始する別のトリガーの作成です。このトリガーは、Cloud Build ジョブを呼び出し、変更を Dev Build 組織に push します。DevOps パイプラインでは、承認された担当者とプロセスのみが変更をリリース ブランチに commit できるようにする必要があります。

1. [Cloud Build トリガー] ページで、[トリガーを作成] をクリックして、新しいトリガーを作成します。
2. [名前] を commits-to-release-branch に設定します。
3. [トリガーのタイプ] で、[ブランチに push する] を選択します。
4. [リポジトリ] リストで、GitHub Salesforce リポジトリを選択します。

5. [ブランチ（正規表現）] テキスト ボックスに次の式を入力します。

   ^release.*
   

6. [ビルド構成] で、[Cloud Build 構成ファイル] を選択し、「cloudbuild.yaml」と入力します。

7. [代入変数] で、3 つの変数を作成します。変数ごとに、次の操作を行います。

   1. [項目を追加] をクリックします。

   2. [変数] フィールドと [値] フィールドを、次の表に示すように設定します。

      変数	値
      _BUCKET_NAME	Salesforce 鍵ファイルのバケット名を次の形式で入力します。 salesforce-ref-PROJECT_ID PROJECT_ID は実際の Google Cloud プロジェクトの ID に置き換えます。
      _CONSUMER_KEY	Salesforce の Dev Hub 組織で作成した接続アプリケーションのコンシューマ鍵。
      _SF_USERNAME	Dev Hub 組織の Salesforce ユーザー名。

8. [保存] をクリックします。

Cloud Build に Salesforce の鍵の読み取り権限を追加する

• Cloud Shell で、作成された Cloud Storage バケットから Salesforce の鍵を読み取る権限を Cloud Build サービス アカウントに追加します。

  gsutil iam ch serviceAccount:[email protected]:objectViewer \
      gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
  

Salesforce 開発者用のパイプラインを設定する

このセクションで説明するタスクは、Salesforce 開発者を対象としています。

このチュートリアルの管理者およびリード向けのセクションで先に説明した手順を行った場合は、別の認証情報セットを使用してこのセクションの手順を行ってください。

Salesforce DX CLI のインストール手順は、使用している OS によって異なることがあります。このセクションでは、Debian Linux の手順について説明します。macOS と Windows の手順については、Salesforce ドキュメントの Salesforce CLI のインストールをご覧ください。

Salesforce DX CLI を設定する

このセクションでは、Salesforce CLI をインストールして、その CLI が認可されるように設定します。

1. （Cloud Shell 内ではない）ローカルマシンで、ホーム ディレクトリに移動します。

   cd $HOME
   

2. xz-utils と wget をインストールします。

   sudo apt-get install --assume-yes xz-utils wget
   

3. Salesforce CLI をインストールします。

   wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz
   

4. sfdx ディレクトリを作成します。

   mkdir sfdx
   

5. ダウンロードした tar ファイルを展開します。

   tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1
   

6. CLI をインストールします。

   ./sfdx/install
   

   Salesforce CLI は、/usr/local/bin/sfdx にインストールされます。

7. CLI が正しく設定されていることを確認します。

   sfdx
   

   出力は次のようになります。

   VERSION
   sfdx-cli/7.8.1-8f830784cc linux-x64 node-v10.15.3
   
   USAGE
   $ sfdx [COMMAND]
   
   COMMANDS
   commands  list all the commands
   force     tools for the Salesforce developer
   help      display help for sfdx
   plugins   add/remove/create CLI plug-ins
   update    update the sfdx CLI
   which     show which plugin a command is in
   
   TOPICS
   Run help for each topic below to view subcommands
   
   commands  list all the commands
   force     tools for the Salesforce developer
   plugins   add/remove/create CLI plug-ins
   

ローカル開発環境を Salesforce Dev Hub 組織に接続する

1. ローカルマシンから、開発者ロールの認証情報を使用して Salesforce 組織にログインします。

   sfdx force:auth:web:login --setalias YOUR_HUB_ORG
   

   YOUR_HUB_ORG は、Dev Hub 組織の適切なエイリアスに置き換えます。

   このコマンドはローカルマシンでウェブブラウザを開くため、接続先の VM では実行できません。

GitHub リポジトリのクローンを作成する

1. Salesforce 管理者が作成した GitHub リポジトリのクローンを作成します。

   git clone DEV_REPO_NAME -o github
   

2. クローンされたリポジトリのディレクトリに移動します。

   cd DEV_REPO_NAME
   

Salesforce のコードベースとメタデータをスクラッチ組織に push する

このセクションでは、単体テストが可能になるように、コードベースとメタデータをスクラッチ組織に push します。

1. ローカルマシンで、Dev Hub のユーザー名を SALESFORCE_USERNAME という名前の環境変数にエクスポートします。

   export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAME
   

   YOUR_DEVHUB_USERNAME は、先に設定したユーザー名に置き換えます。

2. このチュートリアル用にクローンを作成したリポジトリをテストするためのスクラッチ組織を作成します。

   sfdx force:org:create \
       --setdefaultusername \
       --definitionfile config/project-scratch-def.json \
       --targetdevhubusername ${SALESFORCE_USERNAME} \
       --setalias feature-test-scratch-org
   

3. メタデータとコードをスクラッチ組織に push します。

   sfdx force:source:push
   

4. スクラッチ組織の URL を生成し、ブラウザ ウィンドウでその URL に移動します。

   sfdx force:org:open
   

通常、プロジェクトのライフサイクルにおける次のステップでは、単体テストを実行し、開発した機能を検証します。このチュートリアルでは、事前検証済みのサンプルコードを取り扱っているため、単体テストを行いません。

コードをソースコード リポジトリに push する

1. ローカルマシンで、feature-1 という名前の新しいブランチを作成します。

   git checkout -b feature-1
   

2. 変更をソースコード リポジトリに push します。

   git add .
   git commit -m "Feature 1 changes"
   git push github feature-1
   

   このチュートリアルでは、ソースコード ツールとして GitHub を使用します。

デプロイをテストする

このセクションでは、作成したトリガーが機能することを確認するために実行できるテストについて説明します。Salesforce 管理者が作成したリポジトリには、サンプルのテストクラスが含まれています。

1. （Cloud Shell 内ではない）ローカルマシンで、新しい Git ブランチを作成します。

   git checkout -b feature-1
   

2. テキスト エディタを使用して、次のファイルを開きます。

   ./force-app/main/default/classes/SampleTest.cls
   

3. テストに失敗するには、System.assertEquals ステートメントで 101 の値を 102 に変更します。変更後にファイルを保存します。このファイルは後の手順で再変更するため、開いたままにしておきます。

   @isTest
   public class SampleTest {
   static testmethod void testAddOne() {
       Test.startTest();
       System.assertEquals(Sample.addOne(100), 102); // Change to 102 from 101
       Test.stopTest();
     }
   }
   

4. 変更を add し、機能ブランチに commit します。

   git add .
   git commit -m "Changed test case"
   git push github feature-1
   

5. コードを release-sample ブランチにマージする pull リクエストを作成します。

   新しい Cloud Build ジョブがトリガーされます。しかし、単体テストが失敗するため、ジョブも失敗します。

6. ビルドのステータスを表示するには、Cloud Build ページを開きます。

   Cloud Build ページに移動する

7. Cloud Build ページの履歴セクションに移動します。

   次に示すジョブのビルドログが表示され、テストのアサーションが失敗しています。

   Step #4: not ok 1 SampleTest.testAddOne
   Step #4: # System.AssertException: Assertion Failed: Expected: 101, Actual: 102
   Step #4: # Class.SampleTest.testAddOne: line 24, column 1
   Step #4: # Run "sfdx force:apex:test:report -i 7076300001gEzne --resultformat <format>" to retrieve test results in a different format.
   [. . .]
   Finished Step #4
   ERROR
   ERROR: build step 4 "gcr.io/serverless-devops-sf/salesforcedx-base-image:1" failed: step exited with non-zero status: 100
   

8. テストに成功するには、./force-app/main/default/classes/SampleTest.cls ファイルの 102 の値を 101 に戻します。

   @isTest
   public class SampleTest {
   static testmethod void testAddOne() {
       Test.startTest();
       System.assertEquals(Sample.addOne(100), 101); //Change back to 101 from 102
       Test.stopTest();
     }
   }
   

9. 変更を add し、機能ブランチに commit します。

   git add .
   git commit -m "Changed test case to make it pass"
   git push github feature-1
   

   commit オペレーションにより、Cloud Build ジョブがトリガーされます。

10. ジョブが完了したら、GitHub で pull リクエストを確認し、release-sample ブランチにマージします。

    本番環境のワークフローでは、pull リクエストをマージする権限は通常、DevOps リードと管理者に限定されます。この設定方法の詳細は、GitHub サイトの pull リクエストのマージ可能性を定義するをご覧ください。

11. Google Cloud コンソールで、pull リクエストを release-sample ブランチにマージしたときに自動的にトリガーされる Cloud Build ジョブを確認します。

12. ジョブが完了したら、Dev Hub 組織にログインします。開発者または管理者としてログインできます。

    この Salesforce 組織では、開発者のコードを変更できます。これを確認するには、設定ページに移動し、カスタムコード / Apex クラスをご覧ください。