変更セットによる運用組織へのリリース時あるある

Salesforceでの開発において、最終段階に行われる大事な作業として運用組織へのリリース作業があります。 Sandboxで労力と時間を掛け開発した内容を、ユーザに公開し利用して頂く為に行う作業であり、最後の山場になります。

運用中の組織ですと、夜間や休日など限られた時間の中で行う、時間に追われた作業であることも多いかと思いますが、リリース作業が成功かどうか確認してみたらうまく反映できておらず、迫り来る制限時間の中、手間取って冷や汗をかくなんてことがあったりします。

そんな変更セットによるリリース作業で、一度は経験するだろう"あるある"を紹介したいと思います。 （経験豊富な方には当たり前のこともあるとは思いますがご容赦願います。）

1.オブジェクトに追加した項目の項目レベルセキュリティが設定されていない！

リリース後の確認で画面を見てみたら、そこにあるはずの項目が画面に無い！ってことがあります。 調べてみると、対象項目の項目レベルセキュリティが全てチェックされていないのが理由でした。 追加項目の項目レベルセキュリティはプロファイルも変更セットに含めないと項目レベルセキュリティが移行されませんので、プロファイルを変更セットに含める必要があります。 しかし、プロファイルを変更セットに含めると、基本的にはプロファイルに設定された他の設定内容も移行されますので、Sandbox作成後に運用組織でのみ変更した設定をSandboxの古い設定で上書いて戻してしまうなど、意図しない設定が反映されることが起こるので注意が必要です。 Sandboxのプロファイルの設定が正しいことを確認の上、変更セットに含める必要があります。 Sandboxと本番組織で同期が取れない場合などは、影響範囲を十分調査しプロファイルを含めずに移行後に手動設定することとなります。 ただし、本来は常にSanboxから本番へ移行可能な状態を維持するような、開発～テスト～デプロイの一連をどう運用するといったデプロイ戦略を定義することが望ましいでしょう。

2.選択リスト項目に値を追加したのに選択リストに出てこない！

レコードタイプを利用しているオブジェクトの選択リストに値を追加した場合などは、レコードタイプもいっしょに含めないと出力されません。 選択リストはレコードタイプごとに出力値を設定しますが、変更セット作成時にレコードタイプの追加を忘れてしまいがちですので注意が必要です。

3.ホーム画面に設定していたカスタムロゴが標準のSalesforceのロゴに変わってしまった！

カスタムアプリケーションを作成し、ホーム画面左上のロゴを会社のロゴ等にカスタマイズされている組織は多いと思いますが、変更セットにカスタムアプリケーションを含めてリリースすると、カスタムロゴが標準のSalesforceのロゴに変更されてしまう場合があります。 Sandboxを作成、又はリフレッシュするとドキュメントにあったロゴファイルなどはSandboxには無くなってしまい、カスタムアプリケーションのロゴ設定も標準ロゴに変更されてしまいます。 その為、その状態のまま、カスタムアプリケーションを変更セットに追加しリリースしてしまうと、その設定が反映されてしまいます。 もし、変更セットにカスタムアプリケーションを含めてリリースする必要がある場合は、事前にSandboxにロゴファイルを追加し、カスタムアプリケーションの設定を運用組織に合わせ設定し、運用組織と同じにしておくことでカスタムアプリケーションを変更セットへ含めた場合でも、運用組織のロゴが変わってしまうことは防げます。

4.トランスレーションワークベンチで変更したラベル名が移行されない！

運用組織に対しトランスレーションワークベンチで、項目のラベル名を変更したい場合があります。 Sandboxのトランスレーションワークで修正し、変更セットには言語翻訳を追加してリリースしたにも関わらず反映されない場合があります。 項目に対し言語翻訳を反映させる為には、変更セットに変更させたい項目自体も追加する必要があります。 このことは、逆に捉えると項目を変更セットに含めなければ、意図していない誤った設定が反映されることがないことにもなります。 リリース時にこのことを理解して変更セットを作成しましょう。

5.変更セットにコンポーネントを追加しすぎてViewStateエラーが発生してしまった！

規模が大きな組織になるとリリースも規模が大きくなり、変更セットに含めるコンポーネントも多くなります。 そのような場合に、ViewStateエラーが発生することがあります。 どうやら変更セットの参照画面はVisualforceで作成されている為に発生しうるのだそうです。 発生した場合は複数の変更セットに分割してリリースすることになりますが、依存関係などがあって面倒で対応に時間が掛かることが想定されます。 変更セットの規模が大きくなりそうな場合にはリリースまでのスケジュールに余裕をもって挑みましょう。 関連情報として、変更セットに含めるられるコンポーネントの数と容量に制限があることが上げられます。Spring'15時点でファイル数が10,000で総容量が400MBです。

6.運用組織の方がバージョンが低くて、変更セットのリリースが失敗した！

Salesforceのバージョンアッププレビューで、先行してSandboxがバージョンアップした場合に、そこで開発設定した内容がバージョンの相違でリリースできない場合があります。 これを意識せずに、例えばSandboxにて新APIバージョンで新機能を利用してApex開発をゴリゴリ行って、さぁリリースとなった段階でこのエラーに遭遇してしまうと最悪リリース延期が必要になってしまうなんてこともありえます。。。 幸いにも新APIバージョンの機能を利用していなくAPIバージョンを下げることが可能と判断できれば、それによってリリース可能になることもあるかと思いますが、そのようなことは簡単に判断できないことが多いと思います。 また、プロファイルに新機能に関する権限が追加されることもあり、プロファイルがそのまま移行できないなんてこともあります。 バージョンアッププレビュー期間でのリリースについてはくれぐれも気を付ける必要があります。 なお、弊社横山が「Salesforceのバージョンアップに備える」と題して、バージョンアップに関して解説しておりますので、バージョンアップの仕組みに関して理解し、リリースに備えたいですね。

7.運用組織へのリリース時の全テストコード実行でテストコードが失敗しリリース出来ない！

運用組織へのリリース時には変更セットにApex等コード関連のコンポーネントが含まれていなくてもテストコードが全て実行され、それが全て成功しないとリリースすることが出来ません。 Sandboxをリフレッシュして開発を進めている時に、運用組織に対し入力規則を追加変更していた場合など、そのオブジェクトに関わるテストコードがその影響を受けてテストがエラーになってしまうことがあります。 複数の管理者や開発者が存在する場合など、設定変更に関する情報の担当者間での共有が出来ずに発生することがあるので、注意が必要です。 Spring'15で「短時間でのコンポーネントのリリース：クイックリリース」機能がリリースパイロットになっています。 この機能は、事前検証済み（過去４日間）のApexはテストを動かさずにリリースできるようになります。大規模な組織では、検証に数時間も掛かるような場合もあり、事前に検証することができ、当日は短時間でリリースを行えるようになりました。待ち望まていた機能が利用できるようになりました。

最後に。

今回は7つのあるあるを紹介しましたが、これ以外にも冷や汗物のあるあるはまだあるかと思います。 リリース時に問題が発生してあたふたと対応することが無いように、可能であればリリース本番日の数日前までには運用組織でのリリースの検証を行って、もし問題が起こっても余裕を持って冷静に対応できるようにしておきましょう リリース本番日には準備万端整えてサクサクっとリリースを成功させ、開発の労をねぎらうべく皆で「ビールで乾杯！」と行きたいところです。