はじめに
Salesforce にはいくつか開発モデルがあることをご存知でしょうか。
本番環境を直接操作してポチポチと設定を反映するものから、Git 管理されたメタデータを CI/CD パイプラインでデプロイするものまであります。
私はこれまでの業務で複数の開発モデルを経験してきました。本記事では各開発モデルの概要と特徴を解説しつつ、実際に使ってみての所感を添えてご紹介します。
Salesforce 開発モデル
「開発モデル」という表現を使っていますが、ここではいわゆる開発・デプロイ手法のことを指しています。Salesforce は独自のプラットフォームである分、開発モデルの選択がプロジェクトの運用コストや品質に影響します。
手作業で設定を反映する
最もシンプルな開発モデルです。Salesforce の設定画面から直接変更を加え、本番環境へ反映します。標準オブジェクトへのカスタムフィールド追加、Salesforce フローの作成・更新、プロファイルの権限変更といった宣言的な設定変更に向いています。
実際の運用では、あらかじめ Sandbox 環境でオペレーションをシミュレーションし、手順書を整備した上で本番環境へ適用していました。手作業であるため、手順書の抜け漏れや操作ミスといったヒューマンエラーのリスクは否めませんが、手順さえ整っていれば誰でも対応しやすく、習得コストが低いです。
Salesforce を初めて導入して開発を始める場合、最初に触れるのはこの手作業による設定反映になるでしょう。
ただし、この手作業での反映には限界があります。Apex クラスや Lightning Web Component など、コードを伴う開発成果物は管理画面から直接デプロイすることができません。私自身も Apex トリガーの実装で初めてその壁に当たりました。本番環境では Apex クラスの直接作成が制限されており、Sandbox 環境でテストカバレッジ 75% 以上を担保してからでないと本番へ反映できない仕組みになっています。
変更セット開発モデル
変更セット開発モデルは、Sandbox 環境で作成・更新したリソースを「送信変更セット」として本番環境へ送り、受信側で「受信変更セット」として取り込むデプロイ手法です。
GUI から変更したいコンポーネントを選択して送信するだけなので、操作は直感的です。私は主に Apex クラスや Apex トリガーの本番反映にこのモデルを利用していました。
手作業での反映が難しいリソースを含みつつも、変更対象が比較的少ない場合に適した開発モデルだと感じています。変更セットは Salesforce 環境間の接続設定が必要なため、環境構成によっては初期設定がやや煩雑になることもあります。
組織開発モデル
ここまで紹介した 2 つの開発モデルは、いずれも Salesforce の環境を直接操作して変更を加えるものでした。そのため、「誰が・いつ・どのような変更を加えたか」を追跡することが難しく、チーム規模が大きくなったり変更頻度が増えたりするにつれて管理コストが上がっていきます。
こうした課題に対応するのが組織開発モデルです。Salesforce DX プロジェクトを使い、カスタムオブジェクトのフィールド定義、ページレイアウト、プロファイル、フローなどの設定をメタデータとしてソースコード化し、Salesforce CLI を介してデプロイします。
メタデータを Git で管理できるため、通常のアプリケーション開発と同様に、Sandbox やスクラッチ環境で実装・検証し、メタデータを取得して Pull Request を作成し、レビューを経てからデプロイするというフローを組めます。変更履歴も Git 上に残るため、IaC（Infrastructure as Code）に近い感覚で Salesforce 環境を管理できることがメリットです。
運用上の注意点として、Salesforce のメジャーバージョンアップ時に、マニュアルファイルによっては、これまで管理対象外だったメタデータが新たに追加されることがあります。そのメタデータを取り込んで良いのか、既存の設定に影響はないかを都度判断する場面が出てくるため、バージョンアップのタイミングでは少し手間が増えることを覚えておくとよいでしょう。
パッケージ開発モデル
パッケージ開発モデルは、関連するリソースをパッケージとして1つにまとめ、そのパッケージをインストールすることで環境へ反映させる開発手法です。
イメージとしては、Salesforce 上で 1 つのアプリケーションを作るような感覚に近いです。私は顧客関係管理とは独立した別アプリケーションを構築する際に、ロック解除済みパッケージを運用しました。Lightning Web Component、承認プロセス、カスタムオブジェクトをパッケージに含め、本番環境へインストールして利用していました。
パッケージはライブラリに近い概念であり、リリースのたびにパッケージバージョンを上げる必要があります。そのため、「このリリースはメジャーバージョンか、マイナーバージョンか」「他の開発中のパッケージと依存関係はないか」といった、ソフトウェアパッケージ開発に近い思考が求められます。変更の影響範囲が明確になる反面、バージョン管理の運用ルールをチームで整えておく必要があります。
おわりに
プロジェクトの規模、チームの習熟度、変更頻度などによって適切な開発モデルは異なります。また、これらは排他的なものではなく、一部の変更は手作業で行いつつ、コード管理が必要なものは組織開発モデルで対応するといった組み合わせも考えられます。
Salesforce 開発を始める方がまず手作業での設定変更から入り、スケール・ユーザーの要望に応じてより高度な開発モデルへ移行していく流れは自然なことだと思います。そのときの参考になれば幸いです。