見出し画像
Photo by goodbye_cg

変更セットでのリリースについて

Yuka Satoh

ちょうどこの間、Salesforceの変更セットでのリリースを初めてやってみたメンバーがいたので、書いてみることにしました。
開発者向けではなく、プログラムでの開発経験がない（少ない）けどフローなどをリリースしたりするアドミン向けの内容です。

前提

  • 「変更セット」での「標準機能範囲」のリリースについてのみ記載します。また、Chat GPTには確認してますが、経験に拠るものなので書いていないことに関しては分かりません（もしくはあったけど忘れてます）。

  • Apexクラスのリリースについては触れません。
    たぶんApexやLWCなどのプログラムを含むリリースは、バージョン管理ができるDevOpsセンターを使うことを推奨だと思います。

  • その他Salesforce  CLIでのリリースも可能ですが触れません。コマンド使える方は CLI でリリースした方が楽かも？

全体の流れ

まず大まかに全体の流れについて。私が良いと思っている方法ですが、リリースの規模などに合わせて省略しても良い部分もあるかもしれません。

  1. リリースする先（例：本番環境）と、リリースする元（例：Sandbox）の差分を確認する

  2. リリース手順書を作る

  3. リリース手順書をレビューしてもらう（レビュワーがいれば）

  4. リリースリハをする
    ※ 大きなリリースの場合、初めてのリリースなどは別のSandboxへリリースして手順書に問題がないかを確認する
    ※ 別のSandboxへリリースしたら動作確認をする（顧客環境であればUATをしてもらう）

  5. リリース手順書を修正する

  6. 本番リリースをする

  7. 動作確認をする

1. 差分の確認（重要）

リリース先（ここでは便宜上「本番」とする）とリリース元（ここでは便宜上「Sandbox」とする）の環境に、変更した内容以外の差分がないかを確認します。これは結構重要なポイントです。

権限問題

Sandboxを作ってから（or 更新してから）本番に何も設定の変更が加えられていない場合、リリースするときに「プロファイル」を含めてリリースをすることができます。
プロファイルは（現時点では）権限を制御しているので、オブジェクトやカスタム項目をリリースしたときに、項目レベルセキュリティが設定された状態でリリースすることができます。

ただし、これは注意深く確認する必要があります。（なんかチャッピー風😆）
誰かが、自分が知らない間に本番環境に項目を追加していた場合、プロファイルをSandboxからリリースしてしまうと、本番に追加されていた項目への権限が全部なくなります（Sandboxにはない項目なので）。
そして自分の知らない項目なので、自分では気づけないです。こわい。

設定変更履歴を確認するなど、「絶対に」本番で権限に関する変更が行われていないことを十分に確認するか、プロファイルをリリースすることを諦めましょう。

プロファイルをリリースしない場合は、以下の２パターンで権限の設定が必要です。（項目の場合）

  1. 変更セットでのリリース後に、手動で権限を付与する
    ※ 項目の数が少なければ項目で必要なプロファイルの権限を付与する
    ※ 項目の数が多い場合は、プロファイルでオブジェクト単位で付与する

  2. カスタム権限セットを作成し、その権限セットを一緒にリリースする
    ※ 変更セットのリリース後にユーザーの割り当てが多分必要

権限の管理が今後権限セットに移行する、というような話もあるので、今後は「2」の方が良いかもしれないですね（やったことないけど）。

項目以外だとページレイアウトが複数ある場合の割り当てなども手動でやる必要があったと思います。

バージョン問題

リリースする時期によっては、Sandboxがプレビュー期間で先にバージョンアップされていて、本番がまだバージョンアップされていないタイミングもあります。
例えば、本番は「Summer’25」、Sandboxは「Winter'26」という感じ。

変更セットに含む内容によっては問題ないこともありますが、本番には適用されていないWinter'26の新機能を使ったり、フローのAPIバージョンがSandboxの方が新しく、本番では使えないバージョンだったりすると、変更セットの検証/リリース時にエラーが発生します。

大規模なリリースであればバージョンが一緒になってからの方が安心です。
※ 本番とSandboxのバージョンの違いはページ更新時のアイコンの違いでも     簡単に確認はできます。
※ 詳細の確認方法は 公式ヘルプ を参照してください。

2. リリース手順書を作る（重要）

これは、規模に関わらず作ったほうが良いです。
カスタム項目数個だから、、、と言って箇条書き・メモ書きレベルもないと、たいてい何か手順が漏れます（経験あり）。
手順書、みたいな大層なものじゃなくても形にこだわらずに作りましょう。

リリース手順書に書くこと

  • 変更セットに含めるコンポーネント（多い場合はチェックリストになる）

  • 変更セットでリリースできない（＝手動で設定しなければならない）こと

  • リリース後の確認内容（動作確認だけでなくレイアウト等のチェックも）

  • 動作確認後のテストデータ削除手順（チェックリストでの削除確認）

送信変更セット作成

作成手順は他のサイトでも紹介されているので詳細は割愛しますが、種別を選んでコンポーネントを追加していきます。
カスタム項目が多いとページングされてるので検索するのも大変。
なので、Chromeのアドオンを使うと便利です。
　例：Salesforce Change Set Helper Renewed
あと、レポートやダッシュボードは共有フォルダに入っていないとリリースできません。未公開フォルダに入っていないかを確認しましょう。

また、大規模なリリースとなる場合、変更セットを分けることを検討してください。変更セットを分ける時は、先にリリースしていないと後続のリリースができないものを考慮しましょう。（例えばフローをリリースしたい場合、フローに含まれているオブジェクトや項目は先にリリースされている必要があります）

変更セットでリリースできないもの

変更セット作成時に種別やコンポーネントが表示されないものは、変更セットでリリースできません。意外とあります。以下は例です

  • 標準項目（例：取引先の取引先名、商談のフェーズの値の変更など）

  • レポート/ダッシュボードの「フォルダ」

  • 組織レベルの設定（例：組織情報・セキュリティ設定・マルチ通貨の有効化など、組織単位で有効化が必要な設定）

  • 共有ルール

  • 権限セットのユーザーの割り当て、キューやグループのメンバー追加

  • サイト（Communityサイト）の設定全般

上記は本番で手動設定する必要があります。また、変更セットでリリースしても本番で利用するために設定が必要なものもあります。例えば以下。

  • （プロファイルをリリースしない場合）
    ・オブジェクト・項目レベルセキュリティの設定
    ・ページレイアウトの割り当て
    ・タブやレコードタイプの割り当て など。

  • カスタムレポートタイプへの項目追加（忘れがち）
    ※ 手動で項目追加したときは今は自動でカスタムレポートタイプに項目追加ができるが、変更セットでリリースした項目はカスタムレポートタイプに自動追加されないので、手動で追加する必要がある

  • フローの有効化（自動で有効化されない）

リリース後の動作確認

リリースしても反映されていなければ意味がないので「これが一番大事」、と言っても過言ではないです。
オブジェクトや項目をリリースしたら、そこにアクセス（参照・編集）できるか？を必ず確認する手順を追加してください。

📝 ポイント 📝

  • オブジェクト：タブからアクセスできるか？（タブのリリース忘れがち）

  • ページレイアウト；項目が表示されているか？（ページレイアウトのリリース忘れがち）

  • レポート：表示されるか？（カスタムレポートタイプのリリース、フォルダの設定忘れがち）

  • 特定のプロファイルのみの表示：代理ログインして確認

  • フローの動作：改修のリリース時に改修した内容が反映されているか？
    ※ 全ての動作確認（網羅確認）はSandboxでやっているはず。新しいフローが動いているかの確認だけでOK

  • リリース時間を想定：短時間で確認できる手順になっているか？
    ※ リリース時はSalesforceの利用を停止するのが安心。停止時間を極力短くできるような手順を作成する。（停止時間前に変更セットの検証まで終わらせておくと良い）

リリース手順書のレビュー

レビュワーがいる場合は、レビューしてもらいましょう。
いない場合はChatGPTに投げて確認してもらうのも手だと思います！

3. リリースリハをする

小規模なリリースや慣れている場合は飛ばしてもいいかもしれませんが、大規模なリリース、手動設定が多いリリース、リリースに慣れていない場合は、リハーサルをしてください。
特に本番リリース前にクライアントにユーザーテストを行ってもらう場合は必須の対応となります。

リリースリハは、別のSandboxへリリース手順書通りに行ってください。
手順書通りにやってもうまく反映できないことや、想定より時間がかかるケースも多々あります。リリース手順書を修正して、本番リリースに備えてください。（そのためのリハです）

リハーサルでのリリース先のSandboxは、Partial SandboxやFull Sandboxを作成（更新）しておくと良いです。本番との差異などもそこで確認できるケースもあります。

4. 本番リリース

ここまでやっておけば、あとは本番環境にリリースするだけです。
作業停止のアナウンスを事前にし、リリース・動作確認をしましょう。
本番リリース時に動作確認したテストデータは不要なデータになるので、削除を忘れずに！

まとめ

※ ↑までの内容をChatGPTにまとめてもらいました🙌

変更セットでのリリースは、アドミンでも扱いやすい方法ですが、いくつかの落とし穴があります。特に大事なのは次の4点です。

  • 差分確認を徹底する：Sandboxと本番でプロファイルやバージョンに差がないかを必ず確認する。

  • 権限や手動作業を忘れない：プロファイルを移さない場合は、項目権限やレイアウト割り当て、フローの有効化などを手動で実施する。

  • 手順書を残す：規模の大小にかかわらずリリース手順をメモ化。レビューやリハーサルができればさらに安心。

  • 本番作業はシンプル＆短時間で：検証は事前に終えて、動作確認と不要データ削除までを含めて完了とする。

小さな変更なら変更セットで十分ですが、リリース内容が大規模化・複雑化してきたら、DevOps Center や Salesforce CLI など、より高度な手法への移行も検討すると良いでしょう。

何事も準備が大事！ですね。参考になれば幸いです。


いいなと思ったら応援しよう！