via pixabay.com
Salesforce開発では、本番組織をコピーしたSandbox環境で設定やコード開発を行い、変更セットやpackage.xmlで上位環境へリリースする手法が一般的です。しかし、チーム開発の規模が大きくなったり、開発でAIツールを使用したりするにつれて、以下のような課題が発生する可能性が高まります。
環境同士の乖離
Sandbox環境で使用しないデータを残し続けたり、検証用に設定を変更したりすると、本番組織とSandboxで差分が広がってしまいます。
復旧不可のリスク
AIツールは一度に大量のコードやメタデータを書き換えられます。Sandbox組織に依存した開発でAIツールを使用すると、AIによるコードの上書きの発生や、破壊的変更時に復旧が不可能となるリスクがあります。
このような課題を解決するのが「ソース駆動開発(Source-Driven Development)」です。
環境同士の乖離
Sandbox環境で使用しないデータを残し続けたり、検証用に設定を変更したりすると、本番組織とSandboxで差分が広がってしまいます。
復旧不可のリスク
AIツールは一度に大量のコードやメタデータを書き換えられます。Sandbox組織に依存した開発でAIツールを使用すると、AIによるコードの上書きの発生や、破壊的変更時に復旧が不可能となるリスクがあります。
このような課題を解決するのが「ソース駆動開発(Source-Driven Development)」です。
ソース駆動開発とは
ソース駆動開発とは、組織のメタデータをGitなどのバージョン管理システムで管理し、そのデータを中心に開発を進める手法です。従来の開発はSalesforce組織の設定やコードを正として開発を進めます。一方、ソース駆動開発では、バージョン管理システム上のデータを正として開発を進めます。また、ソース駆動開発ではSandbox環境だけでなく、スクラッチ組織という組織を用いて開発を行います。
スクラッチ組織
スクラッチ組織(Scratch Org)とは、定義ファイルとソースコードから作成できる「使い捨ての開発専用Salesforce組織」です。スクラッチ組織は開発者ごとに独立した環境を立ち上げ、他人の作業と干渉せずに安全に開発・検証を行うために使用します。Sandboxとスクラッチ組織は用途によって使い分けます。
| 観点 | Sandbox | スクラッチ組織 |
|---|---|---|
| 作成元 | 本番組織のコピー | 定義ファイルからの新規作成 |
| 有効期限 | 無期限(更新間隔の制限有) | 最大30日で自動失効 |
| 初期メタデータ | 本番組織の設定・カスタマイズを引き継ぐ | ソースを展開して構築 |
| データ | コピー可能(Partial/Full) | 原則なし。テストデータを投入。 |
| 同時利用 | 組織のライセンスに応じた数 | Dev Hubの割り当て数範囲での数 |
| 主な用途 | 結合テスト/UAT/リリース準備 | 機能開発/レビュー/検証 |
ソース駆動開発のメリット
Salesforce開発でソース駆動開発を行うメリットとして、主に以下の点が挙げられます。
資材の一元管理が可能
Gitリポジトリ上のソースコードを開発の基準とすることで、資材の一元管理が可能になり、同じ構成の環境を再現しやすくなります。
思いがけない上書きや干渉の防止
開発者ごとにスクラッチ組織という独立した環境で作業を進められるため、他メンバーの作業と衝突せず、意図しないコードの上書きを防ぐことができます。
変更履歴の追跡とコードレビューの強化
「誰が・いつ・なぜ修正したか」という履歴を残すことができます。また、プルリクエストという機能を通じたコードレビューを定着させることで、チーム全体のコード品質向上につなげることができます。
環境破壊を恐れずに試せる高い検証性
スクラッチ組織は定義ファイルから数分で新しく作り直すことができます。また、スクラッチ組織は使い捨てできるので、AIが生成したコードの検証など、実験的な検証をリスクなく安全に行うことができます。
デプロイ作業の自動化とミスの削減
CI/CDパイプライン(GitHub ActionsやJenkinsなど)とSalesforce CLIを組み合わせた自動デプロイを構築することで、デプロイ漏れを防ぐことができます。
資材の一元管理が可能
Gitリポジトリ上のソースコードを開発の基準とすることで、資材の一元管理が可能になり、同じ構成の環境を再現しやすくなります。
思いがけない上書きや干渉の防止
開発者ごとにスクラッチ組織という独立した環境で作業を進められるため、他メンバーの作業と衝突せず、意図しないコードの上書きを防ぐことができます。
変更履歴の追跡とコードレビューの強化
「誰が・いつ・なぜ修正したか」という履歴を残すことができます。また、プルリクエストという機能を通じたコードレビューを定着させることで、チーム全体のコード品質向上につなげることができます。
環境破壊を恐れずに試せる高い検証性
スクラッチ組織は定義ファイルから数分で新しく作り直すことができます。また、スクラッチ組織は使い捨てできるので、AIが生成したコードの検証など、実験的な検証をリスクなく安全に行うことができます。
デプロイ作業の自動化とミスの削減
CI/CDパイプライン(GitHub ActionsやJenkinsなど)とSalesforce CLIを組み合わせた自動デプロイを構築することで、デプロイ漏れを防ぐことができます。
事前準備
ソース駆動開発を実施するための初期セットアップを5つのステップで解説します。
Step 1:開発ツールの準備
まずはPCに4つのツールを準備します。各ツールをインストールした後、ターミナルでバージョン確認コマンドを実行して、正しく認識されているかをチェックします。Salesforce CLI は最新版にアップデートしておきましょう。
| ツール | 用途 | 参考 |
|---|---|---|
| Salesforce CLI | スクラッチ組織の作成・管理やソースのデプロイ | https://developer.salesforce.com/docs/atlas.ja-jp.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm |
| VSCode + Salesforce Extension Pack | 開発用エディタおよびSalesforce開発プラグイン | https://base.terrasky.co.jp/articles/5f2tk |
| Git | ソースコードのバージョン管理 | https://base.terrasky.co.jp/articles/hiV4z |
| GitHub(アカウント登録) | チームでのソースコード共有・レビュー | https://github.co.jp/ |
Step 2:Dev Hub(親組織)の準備
Dev Hub組織とスクラッチ組織の関係
スクラッチ組織を発行・管理するための親組織となる「Dev Hub」を用意します。
①Developer Edition組織の取得
学習や個人検証用の場合、Salesforceの開発者向けサイトから無料の Developer Edition 組織を取得します。
②Dev Hubの有効化
取得した組織にログインし、設定画面の検索ボックスで「Dev Hub」を検索して開きます。
次に、「Dev Hub を有効化」をオンに切り替えます。
①Developer Edition組織の取得
学習や個人検証用の場合、Salesforceの開発者向けサイトから無料の Developer Edition 組織を取得します。
②Dev Hubの有効化
取得した組織にログインし、設定画面の検索ボックスで「Dev Hub」を検索して開きます。
次に、「Dev Hub を有効化」をオンに切り替えます。
Dev Hub 有効化
【注意】
※Dev Hub機能は一度有効化すると無効に戻せません。
※Developer Edition組織をDev Hubにする場合、同時に保有できるスクラッチ組織は最大3個(アクティブ数)、1日に作成できる上限は6個までとなります。
※Dev Hub組織はコードを書く場所ではなく、管理・発行元として使用します。
※スクラッチ組織の作成可能枠の残数は、以下のコマンドでいつでも確認できます。
※Dev Hub機能は一度有効化すると無効に戻せません。
※Developer Edition組織をDev Hubにする場合、同時に保有できるスクラッチ組織は最大3個(アクティブ数)、1日に作成できる上限は6個までとなります。
※Dev Hub組織はコードを書く場所ではなく、管理・発行元として使用します。
※スクラッチ組織の作成可能枠の残数は、以下のコマンドでいつでも確認できます。
sf limits api display --target-org <Dev Hub のエイリアス>
スクラッチ組織の作成可能枠の残数確認
Step 3:Salesforce CLIからDev Hubへの認証ログイン
VSCodeのターミナルを開き、Salesforce CLIを使って先ほど準備したDev Hub組織へWeb認証でログインします。
sf org login web --set-default-dev-hub --alias 〈Dev Hub のエイリアス〉
Dev Hub組織へWeb認証でログイン
§ --set-default-dev-hub:以降作成するスクラッチ組織のデフォルト親組織として設定するオプションです。
§ --alias my-devhub:組織に短縮名(エイリアス)を付ける指定で、以降のコマンドで長いユーザー名の代わりに指定できます。
ブラウザが自動起動したら、Dev Hubを有効化した組織のユーザー名とパスワードでログインしてアクセスを許可します。
§ --alias my-devhub:組織に短縮名(エイリアス)を付ける指定で、以降のコマンドで長いユーザー名の代わりに指定できます。
ブラウザが自動起動したら、Dev Hubを有効化した組織のユーザー名とパスワードでログインしてアクセスを許可します。
Step 4:SFDXプロジェクトの生成とGit初期設定
ローカル上にSalesforce用のプロジェクト構造を生成し、Gitのバージョン管理を開始します。
あわせて、開発のベースとなる既存組織からメタデータを取得(Retrieve)して初期コミットを作成します。
①SFDXプロジェクトの作成
ターミナルで以下のコマンドを実行すると〈プロジェクト名〉のフォルダが作成され、標準的なSalesforce DXのディレクトリ構成(force-appやconfig/project-scratch-def.jsonなど)が自動生成されます。
あわせて、開発のベースとなる既存組織からメタデータを取得(Retrieve)して初期コミットを作成します。
①SFDXプロジェクトの作成
ターミナルで以下のコマンドを実行すると〈プロジェクト名〉のフォルダが作成され、標準的なSalesforce DXのディレクトリ構成(force-appやconfig/project-scratch-def.jsonなど)が自動生成されます。
sf project generate --name 〈プロジェクト名〉
標準的なSalesforce DXの自動生成
②プロジェクトフォルダを開く
VSCodeのメニュー[File] > [Open File...]から①で作成した〈プロジェクト名〉のフォルダを開きます。
VSCodeのメニュー[File] > [Open File...]から①で作成した〈プロジェクト名〉のフォルダを開きます。
③既存組織からのメタデータ取得(Retrieve)
開発のベースとなる既存組織にログインし、現在組織にあるカスタムオブジェクトや権限セットなどのメタデータをローカルプロジェクトに取り込みます。
〈マニフェストファイルのパス〉には「manifest/package.xml」などを指定します。
開発のベースとなる既存組織にログインし、現在組織にあるカスタムオブジェクトや権限セットなどのメタデータをローカルプロジェクトに取り込みます。
〈マニフェストファイルのパス〉には「manifest/package.xml」などを指定します。
# 取得元の組織へログイン sf org login web --alias 〈取得元組織のエイリアス〉 # 既存組織からメタデータを取得 sf project retrieve start --target-org 〈取得元組織のエイリアス〉 --manifest 〈マニフェストファイルのパス〉
既存組織からのメタデータ取得
④Gitリポジトリの初期化とユーザー情報設定・初回コミット
VSCodeのターミナルで以下を実行し、Gitリポジトリの初期化とコミットログ用のユーザー情報を登録します。
ユーザー名とメールアドレスを事前に設定しておくことで、コミットした人物の情報が履歴に正しく記録されます。
VSCodeのターミナルで以下を実行し、Gitリポジトリの初期化とコミットログ用のユーザー情報を登録します。
ユーザー名とメールアドレスを事前に設定しておくことで、コミットした人物の情報が履歴に正しく記録されます。
# 今後git init実行時のデフォルトブランチ名をmainに設定(初回のみ)
git config --global init.defaultBranch main
# Gitリポジトリの初期化(これで最初からmainブランチになります)
git init
# コミット者情報の設定(初回のみ)
git config --global user.name "〈名前〉"
git config --global user.email "〈メールアドレス〉"
# プロジェクト構造と取得したメタデータの初回コミット
git add .
git commit -m "feat: 初期プロジェクト構造と既存組織メタデータの追加"Gitリポジトリの初期化とユーザー情報設定
【補足】
すでにリモートリポジトリが存在する場合は、Step 4および次のStep 5の実施は不要になります。
以下コマンドで既存リポジトリをローカルに取得し、プロジェクトフォルダを開いて開発をスタートしてください。
すでにリモートリポジトリが存在する場合は、Step 4および次のStep 5の実施は不要になります。
以下コマンドで既存リポジトリをローカルに取得し、プロジェクトフォルダを開いて開発をスタートしてください。
# リモートリポジトリのローカルへの取得 git clone 〈リモートリポジトリのURL〉 # クローンしたフォルダへ移動 cd 〈クローンしたフォルダ〉
既存リポジトリの取得
Step 5:リモートリポジトリ(GitHub)の作成&ローカルとの接続
ローカルPCでGitリポジトリを初期化したら、最後にソースコードの共同保管場所となる「リモートリポジトリ」をGitHub上に作成し、ローカルと接続します。
この設定を行うことで、ローカルでの変更をクラウド上へバックアップ(プッシュ)したり、チームメンバーとコードを共有したりできるようになります。
この設定を行うことで、ローカルでの変更をクラウド上へバックアップ(プッシュ)したり、チームメンバーとコードを共有したりできるようになります。
①GitHub上で空のリポジトリを作成する
画面右上の「+」アイコンから「New repository」を選択し、リポジトリを新規作成します。
その際、「Add a README file」などの設定はすべてオフ(チェックを外す/Noneを選択)にします。 これは、Step 4でローカル側にすでにプロジェクト構造を作成済みであるためです。リモートリポジトリ側でも初期ファイルを生成してしまうと、初回の接続(push)時に競合エラーが発生する原因となります。
画面右上の「+」アイコンから「New repository」を選択し、リポジトリを新規作成します。
その際、「Add a README file」などの設定はすべてオフ(チェックを外す/Noneを選択)にします。 これは、Step 4でローカル側にすでにプロジェクト構造を作成済みであるためです。リモートリポジトリ側でも初期ファイルを生成してしまうと、初回の接続(push)時に競合エラーが発生する原因となります。
リモートリポジトリの作成
②ローカルとリモートリポジトリを紐付ける
VSCodeのターミナルを開き以下のコマンドを実行して、ローカルのGitリポジトリに対して「送信先(リモート)」のURLを登録します。
VSCodeのターミナルを開き以下のコマンドを実行して、ローカルのGitリポジトリに対して「送信先(リモート)」のURLを登録します。
# リモートリポジトリ(origin)の登録 git remote add origin https://github.com/<GitHubのユーザー名>/〈プロジェクト名〉.git
リモートリポジトリ(origin)の登録
③初回ソースコードのプッシュ(アップロード)
紐付けが完了したら、ローカルにある初期コードをGitHubへプッシュ(アップロード)します。
紐付けが完了したら、ローカルにある初期コードをGitHubへプッシュ(アップロード)します。
# デフォルトブランチ名をmainに設定(未設定の場合) git branch -M main # ローカルのmainブランチの内容をリモートへ初回プッシュ git push -u origin main
ローカルからリモートへの初回プッシュ
初めてGitHubへプッシュした場合は認証の画面が出てくるので、認証を行います。
GitHubの画面を再読み込みし、ローカルのSalesforceプロジェクトファイル(force-appフォルダなど)が表示されていれば、リモート連携は完了です!
GitHubの画面を再読み込みし、ローカルのSalesforceプロジェクトファイル(force-appフォルダなど)が表示されていれば、リモート連携は完了です!
Git×スクラッチ組織の開発サイクル
開発サイクルの全体像(実践8ステップ)
ソース駆動開発の開発サイクルは以下の8ステップで進行します。
「課題ごとに環境を作って開発し、完了したら環境とブランチを綺麗に捨てる」というのがソース駆動開発の基本思想です。
「課題ごとに環境を作って開発し、完了したら環境とブランチを綺麗に捨てる」というのがソース駆動開発の基本思想です。
Git×スクラッチ組織 開発サイクル
Step 1:課題の受け取り&作業ブランチの作成
BacklogやJiraなどで開発タスクを受け取ったら、Gitの最新のメインブランチ(mainやdevelop)から、そのタスク専用の作業ブランチを作成します。
ブランチ名は「feature/」のように機能開発用のブランチであることを示す接頭辞を付け、それに続けて「add-custom-field」などのように具体的なタスク内容を示す名前を付けることを推奨します。
ブランチ名は「feature/」のように機能開発用のブランチであることを示す接頭辞を付け、それに続けて「add-custom-field」などのように具体的なタスク内容を示す名前を付けることを推奨します。
# メインブランチに切り替えて最新化 git switch main git pull # タスク専用の機能ブランチを作成して切り替え git switch -c 〈ブランチ名〉
タスク専用のブランチの作成
Step 2:スクラッチ組織の作成
定義ファイル(project-scratch-def.json)を読み込み、自分専用のまっさらなスクラッチ組織を生成します。
sf org create scratch --definition-file config/project-scratch-def.json --alias 〈スクラッチ組織のエイリアス〉 --target-dev-hub 〈Dev Hub のエイリアス〉 --duration-days 7
スクラッチ組織生成
§ --duration-days 7:スクラッチ組織の有効期限を指定します(既定7日・最大30日)
Step 3:ローカルソースのデプロイ&権限の割り当て
Gitリポジトリにある最新のソースコード(メタデータ)をスクラッチ組織へデプロイし、自分に権限セットを割り当てます。
スクラッチ組織にメタデータをデプロイしただけの状態では、ログインユーザーに権限が付与されておらず、デプロイしたオブジェクトや項目が画面に表示されません。そのため、開発や検証に必要な権限を権限セット経由で付与する必要があります。
実際のプロジェクトでは、本番組織や開発用Sandboxから取得(Retrieve)してGitで管理しているメタデータをスクラッチ組織へデプロイし、その中に含まれる権限セットをユーザーに割り当てます。
スクラッチ組織にメタデータをデプロイしただけの状態では、ログインユーザーに権限が付与されておらず、デプロイしたオブジェクトや項目が画面に表示されません。そのため、開発や検証に必要な権限を権限セット経由で付与する必要があります。
実際のプロジェクトでは、本番組織や開発用Sandboxから取得(Retrieve)してGitで管理しているメタデータをスクラッチ組織へデプロイし、その中に含まれる権限セットをユーザーに割り当てます。
# ローカルのソースをスクラッチ組織へデプロイ sf project deploy start --target-org 〈スクラッチ組織のエイリアス〉 # 自分自身に権限セットを割り当てる sf org assign permset --name 〈スクラッチ組織の権限セットのAPI参照名〉 --target-org 〈スクラッチ組織のエイリアス〉 # スクラッチ組織をブラウザで開く sf org open --target-org 〈スクラッチ組織のエイリアス〉
スクラッチ組織へのデプロイと権限セットの割り当て
Step 4:開発&検証
スクラッチ組織が開いたら、修正や機能追加の作業を行います。
コード改修(Apex/LWCなど)⇒VSCodeやAIツールを使ってローカルで修正し、『sf project deploy start』でスクラッチ組織に送信して動かします。
宣言型開発(オブジェクト/フロー/画面設定など)⇒スクラッチ組織の設定画面上で直接設定変更を行います。
コード改修(Apex/LWCなど)⇒VSCodeやAIツールを使ってローカルで修正し、『sf project deploy start』でスクラッチ組織に送信して動かします。
宣言型開発(オブジェクト/フロー/画面設定など)⇒スクラッチ組織の設定画面上で直接設定変更を行います。
sf project deploy start --target-org 〈スクラッチ組織のエイリアス〉
差分のあるファイルをスクラッチ組織へデプロイ
Step 5:組織の設定変更をローカルへ回収(双方向同期)
スクラッチ組織の画面上で行ったカスタム項目やフローの変更は、自動的にはローカルファイルやGitには入りません。必ず回収(retrieve)コマンドを実行して、ローカルPCへ引き取る必要があります。
sf project retrieve start --target-org 〈スクラッチ組織のエイリアス〉
スクラッチ組織の変更をローカルPCへ回収
Step 6:差分確認&コミット・プッシュ
回収(retrieve)が完了したら、『git diff』で差分を確認し、意図しないファイルが混ざっていないかチェックしてからコミット(ローカルへの保存)・プッシュ(リモートへの送信)します。
①add(ステージング)
変更したファイルの中から、「今回の履歴として保存したいファイル」を選んで、準備エリア(ステージ)に乗せる操作です。
②commit(コミット)
準備エリアに乗せた変更を、ローカルリポジトリに履歴として確定・保存する操作です。このとき、「何を変更したか」のメモ(コメント)を必ず一緒に残します。
〈コミットメッセージ〉には「feat: ボタンの色を変更」などのように、後から履歴を振り返ったときに「どこで、どんな変更をしたのか」がわかるメッセージを書くことが推奨されます。
③push(プッシュ)
コミットした履歴を、サーバー上(リモートリポジトリ)へアップロードする操作です。これで初めて、他のメンバーもあなたの変更を見られるようになります。
①add(ステージング)
変更したファイルの中から、「今回の履歴として保存したいファイル」を選んで、準備エリア(ステージ)に乗せる操作です。
②commit(コミット)
準備エリアに乗せた変更を、ローカルリポジトリに履歴として確定・保存する操作です。このとき、「何を変更したか」のメモ(コメント)を必ず一緒に残します。
〈コミットメッセージ〉には「feat: ボタンの色を変更」などのように、後から履歴を振り返ったときに「どこで、どんな変更をしたのか」がわかるメッセージを書くことが推奨されます。
③push(プッシュ)
コミットした履歴を、サーバー上(リモートリポジトリ)へアップロードする操作です。これで初めて、他のメンバーもあなたの変更を見られるようになります。
# 変更差分の確認(意図しないファイルがないか確認) git diff # コミットとリモートへの送信 # すべての変更をステージングエリアへ追加 git add . #指定したファイルだけを追加(不要な差分が混ざってしまっている場合に使用) git add 〈追加したいファイルのパス〉 # ステージングエリアへ追加した変更をコミット(ローカルへの保存) git commit -m "〈コミットメッセージ〉" # コミットをリモートのブランチにプッシュ(送信する) git push -u origin 〈ブランチ名〉
差分確認&コミット・プッシュ
Step 7:プルリクエスト作成&コードレビュー・マージ
Web画面(GitHub)からプルリクエストを作成し、チームメンバーにコードレビューを依頼します。
プルリクエストとは、変更内容をmainなどの共通ブランチにマージさせて良いか、チームのメンバーにレビューを求めることです。プルリクエストにより、差分に不足(retrieve漏れ)や不要なファイルがないか確認します。
レビューが承認され、テストが通ったらmainブランチへマージします。
①Web画面からプルリクエストを作成する
ブラウザでGitHubのリポジトリ画面を開き、「プルリクエストの作成(「Compare & pull request」または「Create Pull Request」)」 をクリックします。
プルリクエストとは、変更内容をmainなどの共通ブランチにマージさせて良いか、チームのメンバーにレビューを求めることです。プルリクエストにより、差分に不足(retrieve漏れ)や不要なファイルがないか確認します。
レビューが承認され、テストが通ったらmainブランチへマージします。
①Web画面からプルリクエストを作成する
ブラウザでGitHubのリポジトリ画面を開き、「プルリクエストの作成(「Compare & pull request」または「Create Pull Request」)」 をクリックします。
プルリクエストの作成
ブランチを指定します。
*マージ先(base):統合先の共通ブランチ
*マージ元(compare):作業ブランチ
*マージ先(base):統合先の共通ブランチ
*マージ元(compare):作業ブランチ
ブランチの指定
タイトル・説明文・レビュアーなどを設定します。
課題番号や「何のためにどんな修正を行ったか」を分かりやすく記載します。
右の各項目からレビュアーなどを指定します。
課題番号や「何のためにどんな修正を行ったか」を分かりやすく記載します。
右の各項目からレビュアーなどを指定します。
プルリクエストの設定
②レビューを実施する
レビュアーはWeb画面上の「差分(Files changed)」を確認してレビューをします。
レビュアーはWeb画面上の「差分(Files changed)」を確認してレビューをします。
レビューの実施
③指摘事項への対応
レビュアーから指摘があった場合、以下の手順で修正します。
手順1:VSCodeなどでソースコードやSalesforce設定を修正します。
手順2:再度「git commit」と「git push」を実行します。
手順3:再レビューを受けます。プルリクエストは自動更新されるため、新たにプルリクエストを作り直す必要はありません。
レビュアーから指摘があった場合、以下の手順で修正します。
手順1:VSCodeなどでソースコードやSalesforce設定を修正します。
手順2:再度「git commit」と「git push」を実行します。
手順3:再レビューを受けます。プルリクエストは自動更新されるため、新たにプルリクエストを作り直す必要はありません。
④マージを実行する
レビューが承認(Approve)され、テストが全て成功したら、マージを実行します。
プルリクエスト詳細画面の 「マージ(Merge Pull Request)」 ボタンをクリックします。
マージ後はマージ先ブランチに変更が正常に取り込まれたことを確認します。
レビューが承認(Approve)され、テストが全て成功したら、マージを実行します。
プルリクエスト詳細画面の 「マージ(Merge Pull Request)」 ボタンをクリックします。
マージ後はマージ先ブランチに変更が正常に取り込まれたことを確認します。
マージを実行
Step 8:スクラッチ組織と作業ブランチの削除
マージが完了したら、役目を終えたスクラッチ組織と作業ブランチを削除して1サイクルが完了となります。
# 役割を終えたスクラッチ組織を削除 sf org delete scratch --target-org 〈スクラッチ組織のエイリアス〉 # ローカルとリモートの作業ブランチを削除 git switch main git pull git branch -d 〈ブランチ名〉 git push origin --delete 〈ブランチ名〉
使用済みのスクラッチ組織と作業ブランチの削除
頻発するトラブルとその対策
実際の案件で複数人のチーム開発を行うようになると、新たな課題やハマりポイントに直面します。
頻発するトラブルとその対策を復習しておきましょう。
頻発するトラブルとその対策を復習しておきましょう。
| 現象 | 主な原因 | 解決策 |
|---|---|---|
| 画面で設定した変更がGitに含まれない | retrieve 忘れ | 『sf project retrieve start』を実行してから『git diff』を確認 |
| 画面が真っ白・コンポーネントが表示されない | 権限セットの割り当て忘れ | 『sf org assign permset』を実行して画面を再読み込み |
| コンフリクト(衝突)エラーでデプロイできない | ローカルと組織で同じ箇所が衝突している | 組織のメタデータを『sf project retrieve start』で取得して差分を確認。残したい変更を再デプロイ。 |
| 環境が壊れた・原因不明のエラー | 環境の汚染 | 『sf org delete scratch』で削除し、Step 2 から再生成する |
【発展編】開発から本番リリースまでのブランチ戦略
ここまでの手順では簡略化した運用例を紹介しましたが、実際のチーム開発ではより複雑なブランチ戦略を採用することがあります。以下では、『Git-flow』というブランチモデルを参考にした、Salesforceの開発からリリースまでの流れの一例を簡単に紹介します。
Git-flowにはGitプラグインもあり、コマンドで簡単にGit-flowのブランチモデルを導入することもできます。
Git-flowにはGitプラグインもあり、コマンドで簡単にGit-flowのブランチモデルを導入することもできます。
ブランチ戦略と環境マップ
▶ featureブランチ:機能開発
featureブランチは各作業タスクごとに作成し、スクラッチ組織で開発・テストを実施します。
開発完了後、developブランチにプルリクエストを送信します。
開発完了後、developブランチにプルリクエストを送信します。
▶ developブランチ:開発統合
メンバーの開発した機能を統合するブランチです。developブランチは1つのプロジェクト(Gitリポジトリ)につき一つだけ作成します。
▶ releaseブランチ:リリース準備
リリース前にdevelopから切り出し、リリース対象のバージョンを固定します。releaseブランチは各リリースごと(バージョンごと)に作成します。ブランチ名は「release_v1.0.0」のようにバージョンタグをつけることが推奨されます。
ここでUATを行い、不具合が見つかった場合はこのブランチから不具合修正用のブランチを作成して修正・プルリクエスト・マージします。修正資材のマージ後、developブランチにも修正を反映させるマージバックを行います。
ここでUATを行い、不具合が見つかった場合はこのブランチから不具合修正用のブランチを作成して修正・プルリクエスト・マージします。修正資材のマージ後、developブランチにも修正を反映させるマージバックを行います。
▶ main(またはmaster)ブランチ:本番リリース
UATが完了したらreleaseブランチの内容をmainブランチへマージして本番環境へデプロイします。
同時にdevelopブランチにもマージバックして最新状態を同期させます。
同時にdevelopブランチにもマージバックして最新状態を同期させます。
▶ hotfixブランチ:本番障害対応
mainブランチから緊急修正用のhotfixブランチを作成します。
スピードが求められる本番環境での不具合対応はhotfixブランチで行い、hotfixブランチの変更はmainとdevelopの両方にマージし、mainから本番環境へデプロイ(またはCI/CDで反映)します。
スピードが求められる本番環境での不具合対応はhotfixブランチで行い、hotfixブランチの変更はmainとdevelopの両方にマージし、mainから本番環境へデプロイ(またはCI/CDで反映)します。
ブランチの変更をSalesforce環境にデプロイする
変更が各ブランチへマージされた後、対応するSalesforce環境へメタデータをデプロイします。手作業によるミスを防ぐためにも、CI/CDツール(GitHub Actions、Jenkinsなど)やDevOps製品(Flosumなど)と連携し、差分パッケージを生成する設計や、プルリクエスト時の「自動テスト」と、マージをトリガーとした「自動デプロイ」を組み合わせた運用が推奨されます。
補足
今回の基本フローでは省略しましたが、用途に応じて以下のコマンドを「事前準備」の権限の割り当て後に実行します。
管理者がスクラッチ組織を作成して配布する場合などでは、テストデータの投入やパスワードの生成が必要になります。管理者は、スクラッチ組織を使用する開発者に「ユーザー名」「パスワード」「インスタンスURL」を伝えて組織を配布します。
管理者がスクラッチ組織を作成して配布する場合などでは、テストデータの投入やパスワードの生成が必要になります。管理者は、スクラッチ組織を使用する開発者に「ユーザー名」「パスワード」「インスタンスURL」を伝えて組織を配布します。
# テストデータの一括投入 sf data import tree --files <テストデータのファイルパス>
テストデータの一括投入
# パスワードの生成 # 他のメンバーがスクラッチ組織ログインするためのパスワードを生成 sf org generate password --target-org 〈スクラッチ組織のエイリアス〉
パスワードの生成
# 接続情報の確認 # 組織の「ログインURL」「パスワード」などの詳細情報を表示 sf org display --target-org 〈スクラッチ組織のエイリアス〉
接続情報の確認
まとめ
本記事では、Salesforceにおける「Git×スクラッチ組織」を活用したソース駆動開発の基本サイクルを解説してきました。
「Gitが正(Source of Truth)」へのマインドシフト
Salesforce組織の設定を正解とするのではなく、Gitリポジトリ上のソースコードこそが唯一の正解です
スクラッチ組織は「消耗品」
使い捨てのスクラッチ組織を活用することで、他人の作業と干渉せず、AIが生成した実験的コードもノーリスクで安全に検証できます。
黄金ルールは「1タスク=1ブランチ=1スクラッチ組織」
課題ごとに環境を立ち上げ、作業が終わったら組織もブランチも綺麗に削除して次のサイクルへ向かいます。
ソース駆動開発のスキルを身につけ、AI時代に強いSalesforceエンジニアを目指していきましょう!
「Gitが正(Source of Truth)」へのマインドシフト
Salesforce組織の設定を正解とするのではなく、Gitリポジトリ上のソースコードこそが唯一の正解です
スクラッチ組織は「消耗品」
使い捨てのスクラッチ組織を活用することで、他人の作業と干渉せず、AIが生成した実験的コードもノーリスクで安全に検証できます。
黄金ルールは「1タスク=1ブランチ=1スクラッチ組織」
課題ごとに環境を立ち上げ、作業が終わったら組織もブランチも綺麗に削除して次のサイクルへ向かいます。
ソース駆動開発のスキルを身につけ、AI時代に強いSalesforceエンジニアを目指していきましょう!