変更をテストしてリリースする

• リリースされるコンポーネントをリストしたマニフェストファイル (package.xml) を作成する。
• 組織への変更のリリースに使用されるコマンドを説明する。
• クイックリリースを使用してリリースを高速化する方法について説明する。

変更をリポジトリから取得する

Juan は、一元的な情報源 (このリリースに対するすべての変更) が GitHub リポジトリに存在するようになったことを認識しています。

1. VS Code で、[Source Control (ソース制御)] アイコン (1) をクリックします。
2. [追加アクション] アイコン (2) をクリックし、[Pull from (取得元)] (3) を選択します。
3. オリジンを選択します。
4. リポジトリには、新しいカスタムオブジェクト、カスタム項目、トリガーが含まれています。Ella と Juan が行った変更はすべてここにあります。

Developer Pro Sandbox を承認する

同じ手順を実行する場合は、Developer Edition 組織または Trailhead Playground にサインアップして、Developer Pro Sandbox の代わりに使用してください。

1. VS Code で、Developer Pro Sandbox にログインします。[SFDX: Authorize an Org (SFDX: 組織を承認)] を選択します。
2. ログイン URL (test.salesforce.com) に、[Sandbox] を選択します。
3. Sandbox の別名 (dev_pro_sandbox など) を入力します。
4. Sandbox のユーザー名とパスワードを使用してログインします。

リリースアーティファクトを構築する

Juan の最初の作業は、変更を Developer Pro Sandbox にリリースできるように、リリースアーティファクトを構築することです。Juan はマニフェストファイルを作成することにします。このファイルは通常 package.xml という名前で、リリースするメタデータコンポーネントがリストされています。  

1. コマンドウィンドウから、Salesforce DX プロジェクトディレクトリが表示されていることを確認します。
2. コマンドラインで、project generate manifest コマンドのヘルプを表示します。

   sf project generate manifest --help

   --help で、コマンドの形式を確認できます。Juan は新しいメタデータコンポーネントのみをリリースしたいと考えているため、--metadata フラグが必要だと判断します。
3. project generate manifest コマンドを実行し、リリースするコンポーネントを指定します。たとえば、新しい Language Course Instructors (語学コースインストラクター) オブジェクトや変更リスト内のその他の変更などです。

   sf project generate manifest --metadata CustomObject:Language_Course_Instructor__c --metadata CustomField:Language_Course__c.Course_Instructor__c --metadata ApexTrigger:LanguageCourseTrigger --metadata ApexClass:TestLanguageCourseTrigger

   コマンドによって現在のディレクトリに package.xml というマニフェストファイルが生成されます。
4. Developer Pro Sandbox で package.xml ファイルをテストして、すべてのコンポーネントがリリースされることを確認します。
   

   sf project deploy start --manifest package.xml --target-org dev-pro-sandbox

ここで一度止まって、package.xml ファイルについてじっくり考えてみましょう。  生成したばかりのファイルをテキストエディターで開いてもかまいません。  このファイルには、リリースするメタデータコンポーネントがリストされているだけで、実際の Apex コードやカスタムオブジェクトの完全な構造は含まれていません。  このマニフェストファイルを使用してリリースする場合、deploy コマンドではその時点でローカルプロジェクト内に存在するソースファイルが使用されます。  異なる VCS ブランチからコマンドを実行したり、コンポーネントのローカルソースファイルを変更したりすると、そのファイルが代わりにリリースされます。つまり、マニフェストファイルを使用するときにはリリースする実際のソースファイルに注意してください。   

マニフェストファイルを使用してリリース中にコンポーネントを削除することもできます。削除するコンポーネントをリストする破壊的な変更のマニフェストファイルを生成するには、project generate manifest コマンドの --type フラグを使用します。その後、このファイルを project deploy start|validate の削除フラグのいずれか (--post-destructive-changes など) と併せて指定します。 

同じ手順を実行している場合は、ジャーニーはここで終わりです。次のステップでは、TestLanguageCourseTrigger というテストクラスが必要ですが、これについてはこのモジュールでは扱いません。

テスト (Partial) Sandbox でリリースアーティファクトをテストする

Juan は再びコマンドウィンドウまたはターミナルを使用して Salesforce CLI コマンドを実行し、変更をテスト Sandbox にリリースします。Juan は先ほどと同じ project deploy start コマンドを使用して変更をリリースします。

1. Partial Sandbox を承認します。
2. Salesforce DX プロジェクトディレクトリが表示されていることを確認します。
3. コマンドラインで、deploy コマンドのヘルプを表示します。

   sf project deploy start --help 

   --help を使用すると、コマンドの形式や含めるべきフラグを知ることができます。具体的には、package.xml マニフェストファイルを使用してリリースするには --manifest を使用します。
4. 次のように、本番組織にリリースする内容を模倣する deploy コマンドを実行します。

   sf project deploy start --manifest package.xml --target-org partial-sandbox --test-level RunSpecifiedTests --tests TestLanguageCourseTrigger

5. 必要に応じて、Selenium テストなどの UI テストを実行します。
6. 次のように Sandbox を開きます。

   sf org open --target-org partial-sandbox

7. ユーザー受け入れテストを実施します。

プロセスのこのフェーズで Juan が重視するのは、リリースされるアプリケーションや変更に関連するテストのみであるため、リリースアーティファクト内にあるコードのテストだけを実行します。

Juan のテストが合格すると、テストリリースフェーズに移行し、ステージング Sandbox で回帰テストを実施します。

ステージング (Full) Sandbox でリリースアーティファクトをテストする

インテグレーションテストに基づいて変更を行わなかった場合は、次に Full Sandbox で変更をステージングします。Juan は同様のプロセスに従って、変更を Full Sandbox にリリースします。このフェーズでは、回帰テストを実行し、Juan が変更を本番環境にリリースする方法を模倣します。

テストフェーズでエラーが検出されなかったため、同じ package.xml ファイルを使用して、テストしたときと同じブランチからリリースするようにします。テストフェーズでエラーがあった場合は、そのエラーを修正してもう一度やり直します。

まず、すべてのテストを実施する組織に対して検証リリースを行うことで、回帰分析を実行します。検証リリースでは、リリースで実行されるテストの結果を検証できますが、いかなる変更もコミットされません。検証によって、別のコンポーネントと連動しているメタデータコンポーネントを忘れていないことや、無効なメタデータがないことも確認できます。すべての回帰テストを実行した後、クイックリリースを実行して、本番環境へのリリースで行う手順を完全に模倣します。Juan はこれをすべて、Salesforce CLI を使用して行います。

ステージング環境でコンポーネントを適切に検証することで、Juan はカスタマイズが本番環境にリリースする際のシステムへのユーザーアクセスをブロックするメンテナンス実施期間を短くすることができます。

1. Full Sandbox を承認します。
2. ターゲット組織にコンポーネントを保存せずに、すべてのローカル (回帰) テストを実行してリリースを検証します。 

   sf project deploy validate --manifest package.xml --target-org full-sandbox --test-level RunLocalTests

   このコマンドでは、クイックリリースで参照する必要のあるジョブ ID が返されます。検証が成功したということは、すべての Apex テストが合格しており、リリースされるコードの 75％ 以上がテスト対象になっているということを意味します。
3. 次に、前の手順で返されたジョブ ID を使用して Full Sandbox でクイックリリースを実行します。このクイックリリースは、後で本番組織で行われることを模倣したものです。 

   sf project deploy quick --job-id <jobID> --target-org full-sandbox 

本番組織にリリースする

Juan とチームは、いよいよラストスパートに入ります。Full Sandbox ですべてのテストに合格したため、これで本番組織にリリースする準備が整いました。営業チームは自分たちのビジョンが実現されるのを非常に楽しみにしています。

Juan はリリース実行リストを参照して、リリース前に完了すべきタスクがないことを確認します。準備は整いました。別のリリースを実行したり組織への大きな変更を行ったりしなければ、検証リリースの実行後、10 日間かけて本番環境へのクイックリリースを実施できます。Juan は、ステージング Sandbox との違いによって決して問題が発生しないように本番組織の検証リリースを設定します。問題が発生した場合にトラブルシューティングを行えるように、Juan は検証リリースを営業時間中に実行します。検証が成功したら、お客様への影響を最小限に抑えるために、本番へのリリースはクイックリリースを使用してその日の夜に行います。

1. 本番組織に対する承認を行います。
2. まず、project deploy validate を実行することによって、クイックリリースの検証と設定を行います。

   sf project deploy validate --manifest package.xml --target-org production-org --test-level RunLocalTests

   このコマンドでは、クイックリリースで参照する必要のあるジョブ ID が返されます。
3. 次のようにクイックリリースを実行します。

   sf project deploy quick --job-id <jobID> --target-org production-org 

4. 本番組織を開いて、変更が表示されていることを確認します。

リリース実行リストに記載されているリリース後タスクを実施する

Juan は、リリース実行リストをもう一度参照して、本番組織で実行するリリース後タスクを確認します。

別のロールアウトにも成功!

Calvin は本番組織で簡単なサニティチェックを行います。インストラクターをいずれかのコースに追加し、通知メールが受信箱に送信されることを確認します。

すべての変更がソース制御システムに反映されているため、チームは Calvin にリリースノートに記載する変更の最終的なリストを提供することができます。

Calvin は、新しい通知機能の準備が整ったことを営業チームに通知します。また、Ella と Juan に、Zephyrus の営業チームが最新のコース情報を入手するのに役立つ重要な機能のリリースに成功したことについて感謝を伝えます。Calvin は、変更がリポジトリに保存されるようになったことに満足しており、チームがより多くの作業に取り組む際にリポジトリがもたらす利点を実感しています。