本番組織での変更プロセスの確立

Salesforce Web ユーザインターフェースを使用して本番組織でアプリケーションをすばやく開発およびカスタマイズできることは、Force.com プラットフォームの多くの強みの 1 つです。ただし、このように簡単に開発を行えることにより、エンタープライズアプリケーションの開発で、Sandbox でアプリケーションが開発されているときに本番組織で変更が行われる可能性があります。本番組織へのリリースを確実に成功させるには、本番組織で行われた変更を開発環境にも同様に反映する必要があります。本番組織から開発環境への変更の移動は逆の処理のように見えますが、開発環境から本番組織への移行では本番組織で行った変更が上書きされるため、これが必要になります。

本番組織で変更が行われた場合、Sandbox の更新を実行して最新の変更を取得できます。ただし、Sandbox の更新は常に実行可能ではなく (Full Sandbox では 29 日ごとに 1 回の更新に制限)、開発者に必要な権限を付与するためのユーザプロファイルや権限セットの変更など、設定の変更が必要な場合があります。

したがって、本番組織と開発環境間の変更を追跡し、本番組織と開発環境の差分をマージするプロセスが必要になります。このタスクを容易にするため、本番組織で変更プロセスを確立することをお勧めします。変更プロセスでは、本番組織で実行可能な変更の種類、変更可能な状況、および変更の責任者を決定します。導入する変更プロセスは、本番組織で必要な変更の種類によって異なります。変更プロセスのベストプラクティスを最も単純な方法から最も複雑な方法の順に並べたリストを次に示します。

• 本番組織での変更を許可しない — 最も単純かつ厳格な方法です。この方法では、リリースが容易になる代わりに、設定を簡単に変更できなくなります。このプロセスを選択する場合、すべての開発は Sandbox で行われます。
• メタデータ API でのコンポーネント変更のみ — 手動による変更の追跡とリリースは、メタデータ API を使用するよりもはる��に複雑です。本番組織への変更をメタデータ API からアクセスできるコンポーネントのみに制限できる場合、これにより、追跡、マージ、およびリリースが変更されます。
• 設定の変更を 1 人の管理者のみに許可する — 一部の組織では、本番組織でのすべての設定の変更を 1 人の管理者に割り当てると便利です。これにより、本番組織での変更の追跡、および Sandbox の更新間での開発環境への変更の反映が容易になります。これはより柔軟な方法で、本番組織での変更とプロジェクトベースの開発環境での変更を同時に行うことができます。ただし、この方法は 1 人の管理者がすべての設定の変更を実行できる規模の組織にのみ適用できます。
• 本番組織への変更をスケジュール — 本番組織への変更を頻繁に行う必要がある組織では、その変更を開発環境に移行する時間をスケジュールできます。所有する組織の数に応じて、簡単な移行を頻繁に (毎週など) 実行したり、複雑な移行をより低い頻度 (四半期ごとに 1 回) で実行したりできます。