インテグレーション環境でのテストと変更のリリース

学習の目的

この単元を完了すると、次のことができるようになります。
  • 変更セットをコピーする。
  • 変更セットを検証する。
  • 変更セットをリリースする。

最終段階

開発が済んだら Calvin と Ella はいよいよそれぞれの変更が連動すること、そして Zephyrus に既存するカスタマイズを破損しないことを検証します。こうしたテストが終わった後、Calvin は最終的なリリースアーティファクトを構築します。これは 2 人の変更をまとめた新しい送信変更セットです。この新しいアーティファクトに最終的なサニティチェックを実行して、変更をすべて実施したことを確認します。最後に、本番組織へのリリースを計画して実行します。

インテグレーション環境への変更のリリース

この時点で、Developer Pro Sandbox には 2 人分の受信変更セットが届いています。Calvin はリリース追跡ログを確認して、リリースを計画します。手動のリリース手順が必要な場合は、変更セットのリリースの前後どちらに実行する必要があるかを判断します。

また、次の計画を立てます

  1. 自身の変更セットをリリースする。
  2. Ella の変更セットをリリースする。
  3. アプリケーションへのアクセス権を付与する権限セットをユーザに割り当てる。

Calvin は、自身のカスタマイズを含む変更セットを 1 回のトランザクションで Developer Pro Sandbox にリリースします。

  1. [設定] から、[クイック検索] ボックスに「受信変更セット」と入力し、[受信変更セット] を選択します。
  2. [リリース待ちの変更セット] リストで、リリースする変更セットの名前をクリックします。Calvin は [Language Training (語学研修)] を選択します。
  3. [リリース] をクリックします。

何らかの理由でリリースを完了できないときは、トランザクション全体がロールバックされます。リリースが正常に完了したら、すべての変更が組織にコミットされ、リリースをロールバックすることはできません。

Calvin は Ella の変更セットをリリースし、次に自身のカスタマイズに必要な手動の移行手順を実行して、リリースを完了します。

他の変更セットとのテスト

両者の変更が揃ったら、チ―ムで全体的なテストを実施し、2 人分の変更セットが連動し、既存の機能を破損しないことを確認します。

もちろん、テスト中に見つかった問題にも対処します。Calvin と Ella は Developer Pro Sandbox で直接変更を行うこともできます。けれども、チームのプロセスで、Developer Pro Sandbox を複数の変更セットのインテグレーションとテストのためだけに使用することが決められているため、Calvin と Ella はこのプロセスに従うことにします。

  1. 変更すべきコンポーネントが存在する Developer Sandbox で変更箇所を修正します。
  2. その Sandbox で新しい変更セットを作成します。元の変更セットをコピーするか、新しい変更セットを作成します。
  3. Developer Pro Sandbox を更新すると、すべての変更セットのカスタマイズが削除され、再び本番組織と同じ状態になります。
  4. Developer Sandbox と Developer Pro Sandbox 間の承認を設定します(前回の承認は Sandbox を更新した時点で削除されています)。
  5. 各 Developer Sandbox の変更を Developer Pro Sandbox にリリースする手順を実行します。
  6. 変更をテストします。

最終リリースの準備

変更を本番組織にリリースする前に、Calvin にはあと 2 ~ 3 つすべきことがあります。Developer Pro Sandbox 内で、Calvin と Ella がテストした統合変更セットに存在するすべてのコンポーネントを含む新しい変更セットを作成します。次に、ユーザ受け入れテスト組織である Full Sandbox にその変更セットをリリースして、手動の手順を実行します。

最後にもう一度チームでテストを実施し、変更が意図したとおりに機能し、何も破損していないことを確認します。Calvin はユーザを何人か選んで試してもらいます。

すべてうまくいったら、Calvin は新しいアプリケーションのロールアウトの準備をします。

  1. Zephyrus の本番組織で、Calvin は Developer Pro Sandbox のリリース接続を承認します。
  2. Full Sandbox 組織にリリースした変更セットをコピーします。
  3. その変更セットを本番組織にアップロードします。
  4. 本番組織で変更セットを検証します。
  5. 本番組織の使用量が少ない時間帯にリリースのスケジュールを設定します。
  6. Chatter でロールアウトを発表します。

送信変更セットのコピー

送信変更セットを別の組織にアップロードした後で、異なる組織にアップロードすることはできません。この時点で、Calvin が Full Sandbox で検証した送信変更セットが Developer Pro Sandbox にありますが、その変更セットを本番組織にリリースすることはできません。この変更を本番組織にリリースするために、検証済みの変更セットのコピーを作成します。

  1. [設定] から、[クイック検索] ボックスに「送信変更セット」と入力し、[送信変更セット] を選択します。
  2. コピーする変更セットの名前をクリックします。
  3. [コピー] をクリックします。

受信変更セットの検証

変更セットの検証はリリースの予行演習で、実際のリリースで生成される成功または失敗メッセージが表示されますが、実際の作業は実行されません。スケジュールした時間にリリースする予定で、その時間枠でリリースが成功するかどうかを確認したい場合は、変更セットを検証します。検証することで結果を予測しやすくなります。

また、検証に成功すれば、変更セットがクイックリリースの対象になる可能性があります。クイックリリースでは、リリース中に Apex テストが再実行されないため、所要時間が短縮されます。

クイックリリースは、変更セットとメタデータ API コンポーネントが次の要件を満たしている場合に実行できます。ただし、この処理は完了までに時間がかかり、その間組織がロックされるため、リリースのたびにテストリリースを実行する必要はありません。

警告

警告

検証中は、リリース対象のリソースがロックされます。その間も組織のデータの参照や更新は可能ですが、メタデータを変更する設定変更は行えません。ロックされているリソースや、そのリソースに関連付けられている項目を変更するとエラーが発生することがあります。ピーク時間外の忙しくない時間帯に検証を開始します。検証プロセスが完了するまで、組織への変更を制限します。

  • 過去 10 日以内に、対象環境でコンポーネントが正常に検証されている。
  • 検証の一部として、対象組織での Apex テストに合格している。
  • コードカバー率要件を満たしている。
    • 組織のすべてのテストまたはすべてのローカルテストが実行された場合、全体のコードカバー率が 75% 以上で、Apex トリガについてもある程度のコードカバー率である。
    • 特定のテストが [指定されたテストを実行] テストレベルで実行された場合、リリースされる各クラスやトリガの個々のカバー率が 75% 以上である。

Calvin が Zephyrus の本番組織にログインして検証を実施します。

  1. [設定] から、[クイック検索] ボックスに「受信変更セット」と入力し、[受信変更セット] を選択します。
  2. 変更セットの名前をクリックします。Calvin は [Language Training (語学研修)] をクリックします。
  3. [検証] をクリックします。
  4. 検証プロセスが完了したら、[結果を表示] をクリックします。Calvin の変更セットが検証に成功しました。

検証のエラーメッセージが表示された場合は、エラーを解決してから変更セットをリリースします。変更セットのリリースにおけるエラーの最も一般的な原因は、変更セットに連動コンポーネントが含まれていないことです。たとえば、Calvin の変更セットに、Language Course (語学コース) オブジェクトの主従関係で参照されている Language Course Designer (語学コース制作者) オブジェクトが含まれていないと、リリースに失敗します。

ロールアウトに成功!

スケジュールされたロールアウト時刻に、Calvin は変更セットをリリースして、手動の変更を実施します。リリースが終了したら、Calvin は組織で簡単なサニティチェックを実行します。そして、アプリケーションがライブになったことを Chatter で発表します。やりました!