テスト、ビルド、リリースの方法
学習の目的
- スクラッチ組織が、さまざまな種類のテストにどのように役立つかを説明する。
- リリースでの Sandbox の役割を説明する。
スクラッチ組織を使用したテストと継続的インテグレーション
パッケージ開発でのテスト、ビルド、リリースの方法は、現在のアプリケーションライフサイクルから変更されています。
現在、変更セット開発モデルを使用している場合、組織の変更 (デルタ) が本番組織にリリースされるまで、それらの変更を開発環境とテスト環境の間で移動します。最終的に、「信頼できる情報源」は本番組織になります。バージョン管理システムで外部的に変更を追跡していても、すべてが組織にあることは確実にわかっています。
ただし、これからは選択肢があります! パッケージ開発モデルでは、新しい改善された信頼できる情報源はバージョン管理システムです。Salesforce DX プロジェクトを使用して、ソースをパッケージディレクトリに整理できます。最終的な目標は、それらのディレクトリを使用して、バージョン管理が可能でメンテナンス、更新、インストール、アップグレードが容易なパッケージを作成することです。
パッケージ開発ライフサイクル全体で、Salesforce CLI を使用できます。
開発作業の手動/探索的テストを実行する準備ができたら、メタデータをその目的専用の別のスクラッチ組織にリリースします (1)。その組織から何かを取得することはなく、その組織はテストまたは検証のためにのみ使用されます。
継続的インテグレーション (CI) は、アプリケーションにマージされるすべての変更セットに対して一貫したテスト実行を自動化することを目的としています (2)。このインポートプロセスにより、破損している変更がソースリポジトリに入り込む前に、アプリケーションの品質を保証できます。
スクラッチ組織は、簡単に CI プロセスに統合できます。CLI でスクラッチ組織を作成できるため、スクリプトによってスクラッチ組織を CI フローに組み込むのは簡単です。適切なバージョンのソースリポジトリを使用して組織に入力し、特定の変更についてテストを実行します。
Developer Sandbox が 1 日に 1 回しか更新できないのに対して、スクラッチ組織は 1 日中作成できます。必要に応じて、スクラッチ組織を削除して、すぐに新しいものを作成できます。さまざまな目的のために複数のスクラッチ組織を持つことができます。スクラッチ組織を使用することで柔軟性が大きく高まり、オーバーヘッドは抑えられます。
リリーステストまたは継続的配信の自動化の準備ができたら、パッケージバージョンを作成します。変更セットを使用して環境間で変更を移動する代わりに、パッケージを作成して各テスト環境にインストールします (3)。テストが完了したら、パッケージバージョンを本番組織にインストールします。
Sandbox を使用した継続的配信
継続的配信のためには、本番組織にリリースするときに使用するのと同じプロセスのテストを開始する必要があります。このユースケースでは、ビルドフェーズで作成したパッケージを使用してテストを行い、本番組織の代わりに、それに最も近い Sandbox にインストールします。Sandbox では、本番組織にリリースするときに使用するステップを再現し、テストできます。
変更のセットのみをリリースすることも可能
パッケージ開発は適切なメタデータのスープの変更を管理する優れた方法ですが、パッケージ外にリリースするデータを選択する機能も引き続きサポートされています。ビルドとリリースのユースケースを処理するには、Salesforce CLI の project deploy start コマンドを使用します。
アプリケーションまたはカスタマイズを作成してテストしたら、リリースアーティファクトを作成できます。すべてのソースをリリースでき、変更されたファイルはリリース操作によって更新されます。DX プロジェクトを反復する中で、すべてのリリーステストと継続的配信の用途について、継続して alesforce CLI を使用して変更を組織にリリースできます。「Salesforce DX を使用したアプリケーション開発」モジュールでは、CLI を使用してリリースプロセスを試すことができます。
