リリース管理の基本の学習

学習の目的

この単元を完了すると、次のことができるようになります。

  • 3 つのリリースカテゴリを挙げ、各カテゴリにどのような変更が分類されるのか示す。
  • 変更セットについて説明する。
  • 変更セットのリリースで変更や連動関係を追跡することが重要である理由を説明する。

この単元では、Calvin と同僚が ALM プロセスに取りかかります。読み進めながら、あなたのチームに役立つ選択肢を検討します。続いて、このモジュールの末尾に記載されているモジュールを受講してプロセスを理解すれば、自身に何が適しているのかを判断できます。

リリース管理プロセスの作成

Zephyrus のチームは、自分たちのカスタマイズの実務を、ベストプラクティスである ALM の手順に適合させます。このプロセスは慣れるまで多少時間がかかりますが、やってみる価値はあります。開発のベロシティの向上と、営業チームの中断の減少を実感します。これだけでもチームを説得し、管理職を喜ばせることができます。

Zephyrus では ALM サイクルを実装して、基本的なリリース管理プロセスを導入しました。けれども、チームが抱えているプロジェクトは大小さまざまで、ALM サイクルのフェーズも異なります。プロジェクトを整然と管理し、ユーザの期待に応えられるように、Calvin はリリーススケジュールを設定し、リリースの規模に応じた条件を定義して体制を整えます。

リリースは通常、次の 3 つのカテゴリのいずれかに該当します。

パッチ
バグ修正や簡単な変更。レポート、ダッシュボード、リストビュー、メールテンプレートなどの簡単な変更です。
マイナー
1 つのビジネスプロセスのみに影響する新しいワークフロールールやトリガなど、影響が限定的な変更。通常こうしたリリースはテストが必要ですが、トレーニングや変更管理は限られています。一般に、マイナーリリースの変更は数週間以内に実施されます。
メジャー
1 つ以上の連動関係を伴う変更など、多大な影響のある変更。これらのリリースは、ユーザエクスペリエンスやデータ品質に大きな影響を及ぼす可能性があるため、綿密なテストやトレーニング、慎重な変更管理を要します。メジャーリリースは通常、四半期に 1 回 (Salesforce は年に 3 回) 実施されます。

一定のスケジュールでリリースを実施します。一定間隔で特定の曜日にリリースすることを目標にします。たとえば、毎月第 1 火曜日の午後 8 時にマイナーリリースを行うようにします。定期リリースをスケジュールすることで、全社的な計画実行が可能になり、ビジネスユーザに期待を抱かせることができます。もう一点、大型休暇や重大なイベントの前後にはリリースを予定しないようにします。

変更セットを本番組織まで追跡

Zephyrus のチームは ALM の手順を進める中で、変更セット開発モデルを採用します。ALM の手順に従って、開発環境の設定 UI で変更を作成し、その変更を別の環境に移行します。

変更セット開発において、チームのリリースアーティファクトは、本番組織に存在するメタデータからの変更部分 (差分、デルタ) の集合体です。リリースされるのは、メタデータに追加または変更される部分のみで、変更がなければリリースもありません。

  • 各開発者がリリース用のカスタマイズで各自が行った変更を追跡します。追跡ツールはスプレッドシートや作業追跡システムなど何でも構いません。
  • 変更されたコンポーネントのうち、まだメタデータ API で使用できないものは、別の環境に手動で移行する必要があります。これらの変更を追跡するときに、移行し忘れないようにします。
  • 連動関係コンポーネントを見つけてリリースに含めることも、リリースマネージャである Calvin の仕事です。たとえば、新しいカスタム項目が属するカスタムオブジェクトが次の環境に存在しなければ、そのカスタム項目を対象組織に移行することはできません。変更セットツールを使用すれば、こうした連動関係を特定しやすくなります。

[コンポーネントの連動関係] ページ。連動関係が名前順にリストされ、その参照元が示されています。

メモ

メモ

プロファイルや権限セットの移行は面倒なことがあります。移行に進む前に、プロファイルや権限セットのリリースと取得に関する特別な考慮事項を確認します。

各リリースの変更追跡は手間がかかりますが、記録しておけば、本番組織にリリースする際スムーズにロールアウトできます。

いよいよ結集!

リリースが複数のプロジェクトで構成され、各プロジェクトが別々の環境で開発され、テストされることがあります。そのためビルドのステップに進む前に、各プロジェクトの変更をすべて同じ環境に移行して統合します。ここからは、リリースの変更やカスタマイズが 1 つの変更セットに統合され、本番組織に向かいます。リリースをビルドした後のテストのステップでは、すべての変更をまとめてテストします。

リリースマネージャである Calvin は、リリース担当者全員の変更を追跡します。本番組織で行われた変更で、まだ開発環境やテスト環境に反映されていない変更も追跡します。なぜでしょうか? 本番組織の変更をうっかり上書きしてしまうことなく、カスタマイズのリリースを成功させる唯一の術であるためです。