組織への変更の計画
学習の目的
- 変更セット開発モデルで作業する場合に、ALM の各ステップで使用する開発環境を特定する。
- Sandbox を新規作成する。
- リリースで実施された変更の追跡手段を確立する。
はじめに
「アプリケーションライフサイクルと開発モデル」モジュールを修了した方は (修了していない場合は、このモジュールを始める前に受講することをお勧めします)、Zephyrus Relocation Services の Calvin Green を覚えているでしょう。このモジュールでは、Zephyrus のチームが宣言型変更セット開発を使用して、Salesforce のカスタマイズの 1 つを配信します。
Zephyrus では海外に駐在するクライアントに語学研修サービスを提供したいと考えています。同社の教育チームに語学のスペシャリストが加わり、幅広いコースを考案しています。クライアントの中には、新しい言語を学び始める人もいれば、復習コースで十分という人もいます。また、仕事で必要になるであろう専門用語を学びたいという人もいます。クライアントに語学コースを勧めるときは、さまざまな要素を考慮する必要があります。
Calvin とそのチームは、変更セット開発を使用して、組織に語学コースの情報を追加することにします。
リリース計画の記述
Calvin はリリース計画を書き出して、関係者が業務を把握でき、この先混乱が生じないようにします。また、業務を書き出すことで、気付かなかった問題点が明らかになることもあります。割り当て、テスト計画、決定、マイルストンなどは、漠然と考えるよりも、具体的に書き出した方がまとまりやすくなります。そして、Calvin はこれが一案にすぎないことを認識しています。つまり、リリースの過程で新しい情報が明らかになれば、いつでも計画を修正していくつもりです。
リリース環境の準備
- 開発とテストのステップ: チームの各メンバーが独自の Developer Sandbox で、割り当てられたカスタマイズを作成します。Developer Sandbox には本番データが含まれません。
- リリースのビルド: チームの各メンバーが、各自のカスタマイズを自身の Developer Sandbox から共有の Developer Pro Sandbox に移行して統合します。Developer Pro Sandbox には本番データが含まれませんが、テストデータを取り込むことができます。
- リリースのテスト: ユーザ受け入れテストでは、Full Sandbox を使用して本番組織の完全レプリカを作成します。Full Sandbox には本番データが含まれます。
- リリース: 本番組織にリリースした後で、前のステップで作成した Full Sandbox を使用して、本番データには触れずに、ユーザにトレーニングを実施できます。
環境の作成
Calvin はまず、自分用と同僚の Ella 用の 2 つの Developer Sandbox を作成します。これらの Sandbox で、Calvin と Ella はそれぞれのカスタマイズを作成してテストします。開発者に Sandbox を 1 つずつ作成すれば、チームで統合する準備ができるまで、Calvin は変更を切り離しておくことができます。
Sandbox には、Professional Edition、Enterprise Edition、Unlimited Edition、Performance Edition があります。Calvin が Ella に Sandbox の作成方法を説明します。
- [設定] から、[クイック検索] ボックスに「Sandbox」と入力し、[Sandbox] を選択します。
- [新規 Sandbox] をクリックします
- Sandbox の名前と説明を入力します。
- Sandbox の種別に [Developer] を選択します。
- [コピー開始] をクリックします
本番組織に大量のデータやカスタマイズがある場合は特に、コピーの作成に時間がかかります。Sandbox のコピーが完了すると、Calvin にメール通知が届きます。
同じ要領で、インテグレーションに使用する Developer Pro Sandbox と、ユーザ受け入れテストやユーザトレーニングに使用する Full Sandbox を作成します。
変更を追跡する手段の確立
変更セット開発モデルを使用する場合は、各変更、特に手動で移行する必要のある変更を追跡することが重要です。変更を手動で移行するときは、ある環境から変更を取得して、別の環境にまったく同じものを作成し直します。変更済みのコンポーネントがまだメタデータ API でサポートされていない場合は、変更を手動で移行する必要があります。
Calvin が、メタデータ API でどのコンポーネントがサポートされているのかを知るにはどうすればよいでしょうか? メタデータカバー率レポートを使用します。このレポートには、メタデータ API やその他のメタデータチャネルでどのメタデータ型がサポートされているかが表示されます。この動的に生成されるレポートは、メタデータカバー率の最適な情報源です。メタデータカバー率レポートにアクセスするには、https://developer.salesforce.com/docs/metadata-coverage に移動します。
Calvin は営業チームから依頼された変更と機能強化をすべて追跡しています。そのために、開発者が行った変更がすべてログに記録されるようにカスタマイズされたツールを使用しています。Calvin は安全を期してこのツールに、リリースの各変更の次の重要な情報を記録する項目と、本番組織で直接実行された変更を記録する項目を設定しています。
- この変更は誰に割り当てられたか?
- この変更を手動で移行する必要があるか?
- この変更の影響を受けるコンポーネントはどれか?
- 現在この変更はどの組織にあるか?
- 各環境でいつ変更が行われたか?
本番組織で実行された変更は、開発組織のリリースとは関係ないのに、なぜ Calvin は追跡するのでしょうか? この追跡が、リリースされたカスタマイズによって、本番組織の動作が上書きされたり、予期せず変更されたりしないようにする唯一の術であるためです。
Calvin または Ella が Salesforce ユーザインターフェースを使用して行ったほぼすべての変更が、設定変更履歴に記録されます。Calvin はこの変更履歴をチームの変更追跡ツール内のレポートと照合して、変更が漏れていないことを確認します。
設定変更履歴の使用についての詳細は、Salesforce ヘルプの「設定の変更の監視」を参照してください。
リソース
- 「アプリケーションライフサイクルと開発モデル」モジュール
- Salesforce AppExchange
- Salesforce ヘルプの「Sandbox の作成」
- Salesforce ヘルプの「設定の変更の監視」