複雑さを増すリリースでの変更の管理

学習の目的

この単元を完了すると、次のことができるようになります。
  • バージョン管理を使用することで変更セットのリリースにどのようなメリットがあるかを説明する。
  • 変更セット開発モデルと組織開発モデルの類似点を説明する。

この単元では、Calvin と同僚が、コードとバージョン管理システムを使用した開発に移行する理由を説明します。この単元を読み進めながら、あなたのチームに役立つ選択肢を検討します。このモジュールの末尾に記載されているモジュールを受講してプロセスのハンズオン練習を行えば、習得した知識を基に自身に何が適しているのかを判断できます。

複雑さが増してきたら組織開発モデルに移行

Zephyrus は四半期ごとに業績を伸ばしています。今では営業部門だけでなく、ビジネスの他分野でも Salesforce が使用されています。COO は、Calvin やカスタマーサービス部門のリーダーと協議のうえ、Enterprise Edition に移行して Service Cloud Lightning を購入することに同意しました。Service Cloud Lightning があれば、顧客にすぐパーソナライズされたサポートを実施できます。都合の良いことに、カスタマーサービス部門には、チームのニーズに応じて Salesforce アプリケーションを開発するコーディングスキルを備えたチームメンバーが何人かいます。

Calvin にしてみれば、組織の複雑さが増す中、変更セットの開発プロセスではチームの手に負えなくなることは明白でした。現在の同社には、数々の作業ストリームを管理するために、より厳格な変更管理プロセスと監査プロセス (バージョン管理システムなど) が必要です。

また、変更セットでチームにできることも限界に近づいています。たとえば、項目を追加できても、削除することはできません (破壊的な変更)。

Calvin は直属の部長と Zephyrus の CEO 向けのプレゼンテーションで、組織開発モデルへの移行を提案します。

組織開発モデルへの移行を提案する Calvin

変更セットプロセスの場合と同様、作成するリリースアーティファクトは、本番組織に存在するメタデータからの変更部分の集合体です。他方、組織開発モデルでは、チームが実施する変更を外部化するという方法で、メジャー変更の管理を向上させることができます。Salesforce CLI を使用して、開発環境からメタデータを抽出し、バージョン管理システム (VCS) に統合できます。

また、Salesforce CLI を使用して、定型タスクのスクリプトを作成し、リリース担当者全員の生産性を高めることもできます。まずはテストリリースを実行するスクリプトと Apex テストを実行するスクリプトを作成するという Calvin の提案は、部長や CEO にとっても納得のいくものでした。

ビジネスを主眼に置いた Calvin の提案を受けて、部長と CEO は組織開発への移行を承認します。会社の成功に対する貢献を評価された Calvin はビジネスアナリストに昇進しました。Calvin はこの昇進により、多部門へのリリースの管理も手掛けられるようになりました。

新たなメリットと使い慣れた手法

Calvin とカスタマーサービスチームの 2 人のメンバーは、それぞれ異なる開発環境で個別のプロジェクトに取り組んでいます。この 3 つのプロジェクトはすべて、同じリリースに組み込まれる予定です。組織開発プロセスに移行する中で、3 人は変更セットプロセスとのいくつかの類似点と相違点に気が付きます。

変更セット開発の場合と同様、チームメンバーの 3 人とも各自が行っている変更を追跡します。なぜでしょうか? どのコンポーネントが変更されるのか、そしてそのコンポーネントが変更セットに追加されるのか、Salesforce CLI で取得されるのかをチームが把握する必要があるためです。また、カスタマイズに含まれる変更済みのコンポーネントにメタデータ API に表されないものがある場合は、そのカスタマイズを別の組織にリリースすることができません。こうした変更は対象組織で手動で作成し直す必要があることからも、追跡することが重要です。

チームメンバーが各自の開発業務を完了した後に続くステップは、各自の変更をビルド環境に移行して統合することです。ただし今回は、宣言型ツールを使用して変更セットを作成するのではなく、Salesforce CLI を使用してそれぞれの開発環境から変更を取得します。メンバーが作業を VCS に統合するため、チームメンバーが取得した変更が VCS にコミットされ追跡されます。

取得した変更を VCS にコミットして追跡する場合、チームにとって大きなメリットがあります。変更セットプロセスを使用する場合は、チームメンバーが変更セットを前の変更セットの上にリリースし、他者の変更を上書きしてしまうおそれがあります (実際、度々上書きされていました)。変更を VCS にコミットするという新しいプロセスを使用すれば、変更が上書きされる前に、カスタマイズの競合を特定できます。

ビルドステップに進むと、チームが行ったカスタマイズがすでにソースコントロールのプロジェクトに統合されています。VCS の場合は、これらの変更がまとめてビルド環境にリリースされて統合され、テストできます。変更セットプロセスと同様、変更がビルド環境でまとめてテストされます。そして以前のように、変更が実質的に 1 つにまとめられたリリースアーティファクトになります。ここで Calvin は、Salesforce CLI を使用してビルド環境からアーティファクトを取得します。そして、組織開発プロセスに従って、このリリースアーティファクトを VCS から次の環境に移行します。

組織開発プロセスでは別のツールも使用しますが、ALM の基本的な手順、変更セットの概念、開発やテストの環境は同じです。この新しい開発モデルで初回リリースに取り組む誰もが、ある程度は以前のやり方を踏襲します。その一方で、Calvin は Trailhead や Salesforce 開発者 Web サイトのリソースを活用して、技術的なスキルや知識を高めることにも意欲的です。

Zephyrus は組織開発モデルに移行することで、Salesforce の使用を全社に拡大するために必要なコントロールと効率性を備えることができました。

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる