こんにちは。にいるです。
今までSalesforceで様々な機能や使い方をブログで紹介していますが、その大事なリリースについて一度も書いた事がありませんでした！
なので、今回はリリースや変更管理について、見ていきたいと思います。
1.アプリケーションライフサイクルマネージメントとは
Salesforceには様々なツールが用意されています。
項目値を変更するにしても、ワークフローで項目自動更新したり、数式項目で自動にする、選択リストで連動させる、Apexトリガで変更するなど様々な方法があります。
ただ、どれを使用するにも正常に変更管理をしないといけないことに変わりはありません。
そこで考えておきたいのが、アプリケーションライフサイクルマネージメントと呼ばれる開発プロセスです。
アプリケーションライフサイクルマネージメントは下記の6つのプロセスから構成されています。
| プロセス名 | 説明 |
| リリース計画 | 設計仕様や用件の確定です |
| 開発 | 実際に宣言型、プログラム型ツールを使用して開発します |
| テスト | 変更箇所だけの単一テストをします |
| リリースのビルド | ここで3の変更点全てを1つにまとめます |
| リリースのテスト | 本番環境に近い環境で総合的なテストをします この段階でユーザにもテストをしてもらいます |
| リリース | ベンチマークを満たしたカスタマイズを本番環境へリリースします |
2.リリースのカテゴリー
リリースカテゴリーは3つに分類できます。
| カテゴリー | 内容 | 具体例 |
| パッチ | バグ修正や軽微な変更 | レポート、ダッシュボードの変更 |
| マイナー | 影響が限定的な変更 | ワークフロールールの導入 |
| メジャー | 大きな影響のある変更 | Salesforceのバージョンアップ |
パッチレベルであれば定期的に週一に行う、
マイナーレベルは、何かしらのプロセスを変更するといった部署や組織単位で依頼を元に変更を行うといったイメージになると思います。
メジャーはSalesforceマターになるので、年3回と覚えておきましょう。
3.各開発について
変更セット開発とは、複数の変更を1つのリリースアーティファクトにまとめることです。
Sandboxで各人がDev環境で開発したものを変更セットにまとめて、Dev pro環境でそれらを統合して本番リリースする考え方です。
DevからDev proへアップロードするにはリリース接続の承認をしておく必要があります。
その後に、何らかの不具合でDev proをリフレッシュすると（本番組織と同じ状態）もう一度リリース接続の承認が必要になります。
パッケージ開発とは、変更セット開発では管理できない複雑な場合のものをパッケージ開発で変更管理を行います。
コードセットをまとめて変更管理するものをパッケージ開発と呼ばれています。
4.まとめ
いかがでしたでしょうか。
Salesforceでは変更セットという機能があるので、主にそれを使用してApexクラスをリリースしています。
標準機能であれば簡単なものであれば、直で本番環境を触っておしまいですが、考え方としてパッケージや組織開発を知っておくのも必要ですね。
他にもそれら用のモジュールがあるので、また学習してみようと思います。
他にも色々と標準機能やSalesforce機能について紹介しています。
そのまとめ一覧ページはこちらになりますので、よければ見てみてください。
ではでは！
コメント