ソース駆動型開発の理解

• Salesforce DX プロジェクトの目的を説明する。
• パッケージ開発モデルが変更追跡の管理にどう役立つかを説明する。
• 開発プロセスでのスクラッチ組織の役割を説明する。

前の単元で学習したように、使用するツールはユーザーが決定します。お好みのテキストエディターを Salesforce CLI やコードビルダーと併用できます。どの VCS を使用するかを選択するのもユーザーです。コードビルダーを使用している場合は、開発とテストを促進するための複数の拡張機能が提供されています。

会社が成長するにつれて、複数のプロジェクト間で変更を調整しテストすることが困難になる場合があります。パッケージ開発は、これらの問題に直接対応しています。ソースは、一緒に配信したい機能やカスタマイズのグループに基づいてパッケージに整理されます。Salesforce DX プロジェクトでは、このパッケージベースのアプローチがソースの整理に反映されます。

Salesforce DX プロジェクトは、ソース形式のメタデータのローカルディレクトリ構造です。Salesforce DX ツールを使用して開発およびテストできます。

Salesforce DX プロジェクトには、スクラッチ組織を作成するための設定ファイルが含まれています。開発やテストのために組織に読み込むデータを含めることもできます。また、パッケージを検証するためのテストも含まれています。

CLI を使用して新しい Salesforce DX プロジェクトを作成すると、プロジェクトディレクトリ構造が作成されます。ゼロからプロジェクトを作成する場合は、多くのものが自動的に作成されます。基本プロジェクト設定ファイルが作成されます。テストのためのサンプルスクラッチ定義ファイルおよびディレクトリとサンプルデータセットが作成されます。パッケージソースのデフォルトの「package」ディレクトリも作成されます。

パッケージは、関連するコードやカスタマイズのグループです。パッケージは、組織の他のコンポーネントから独立してテストできます。また、リリースも独立して行うことができます。パッケージ内のメタデータコンポーネントは、インストールされた組織内では、同時に複数のパッケージ内に存在できません。

最小構成では、プロジェクトで 1 つのパッケージのソースを管理します。とは言え、複数のパッケージが一緒に作成されてリリースされる場合は、これらのパッケージを 1 つの DX プロジェクトに整理できます。各パッケージは、プロジェクト設定ファイルで定義される package ディレクトリに関連付けられています。

ソースとメタデータから作成されるスクラッチ組織を使用すると、アプリケーションを簡単に一貫して何度も作成できます。操作するのは特定のプロジェクトのソースとメタデータのみです。不要なものをコピーする必要はありません (率直に言うと、お勧めしません)。スクラッチ組織は一時的な Salesforce 環境であるため、パッケージや開発プロジェクトごとに新しいスクラッチ組織をすばやく作成できます。

VCS が設定され、ソースがプロジェクトに整理されたら、新しい開発プロジェクトを開始する準備は整っています。お好みの IDE またはテキストエディターを開き、ソースコードを追加または変更します。変更内容を組織で確認する準備ができたら、スクラッチ組織を作成できます。

スクラッチ組織を作成しても、実行する設定作業がいくつかあります。すべてのソースをプロジェクトからスクラッチ組織にリリースし、権限を設定し、パッケージに必要なテストデータを作成するか読み込みます。

プログラム型 (コードベース) 開発には IDE やテキストエディターを使用できますが、スクラッチ組織は宣言型 (ポイント & クリック) 開発に使用できます。このプロセスは、Sandbox または本番組織で行う内容に似ています。ソース駆動型モデルの違いは、スクラッチ組織で行った開発をローカルプロジェクトに同期することです。この同期により、[設定] ページで行った変更をローカル IDE で行った変更と共にコミットできます。

バージョン管理システムにコミットする前に、かならずテストを実行してください。同じスクラッチ組織を使用してテストを実行することも、テスト専用の別のスクラッチ組織を作成してソースをコミットすることもできます。テスト用のスクラッチ組織を作成するというこのパターンは、自動化された継続的インテグレーションシステムの重要な部分です。

Salesforce DX の重要な機能に、プロジェクトとスクラッチ組織の同期を簡単に維持できることがあります。もう付箋は必要ありません。ローカルファイルシステム、IDE、エディターで何を変更したか、または組織で何を変更したかを書き留めておく必要はなくなったのです。

Salesforce DX では、プロジェクトでローカルに行った変更とスクラッチ組織で行った変更がすべて追跡されます。

ソースの変更をスクラッチ組織にリリースする前や、ローカルプロジェクトに変更を取得する前に、行った変更をプレビューできます。Salesforce CLI が威力を発揮するのはこうした場面です。

$ sf project deploy preview --target-org my-scratch
No conflicts found.
No files will be deleted.
Will Deploy [2] files.
Type         Fullname        Path
──────────── ─────────────── ──────────────────────────────────────────────────────────────────────────────
ApexClass    WidgetClass     force-app/main/default/classes/WidgetClass.cls-meta.xml
CustomObject WidgetObject__c force-app/main/default/objects/WidgetObject__c/WidgetObject__c.object-meta.xml
No files were ignored. Update your .forceignore file if you want to ignore certain files.

本番組織内で、ソースファイルは非常に大きくなる場合があります。フットプリント (足跡) は雪男並みのサイズです。組織を構成する多くのカスタムオブジェクト、カスタムラベル、静的リソースなどを考えてみてください。

DX プロジェクト形式では、大きなソースファイルを分割して、より処理しやすく、バージョン管理システムで管理しやすくしています。たとえば、Salesforce DX では、カスタムオブジェクトとカスタムオブジェクトの翻訳は複数のファイルとディレクトリに変換されます。このソース構造により、変更または更新する内容がはるかに見つけやすくなります。ソース制御のファイルが小さいほど、チーム開発中に発生するマージの競合が少なくなります。ややこしいマージはもう必要ありません。

開発が完了したら、必ず変更を元の VCS リポジトリにコミットしてください。これで、Salesforce DX でテスト、ビルド、リリースを行う準備が整いました。