アプリケーションライフサイクル管理の理解

学習の目的

この単元を完了すると、次のことができるようになります。
  • 本番組織で直接、安全に実行できるカスタマイズを特定する。
  • アプリケーションライフサイクル管理を定義する。
  • アプリケーションライフサイクル管理プロセスを使用すると、チームがアプリケーションを迅速に開発できることを説明する。

はじめに

Salesforce には、各人のニーズに対応するさまざまな開発ツールやプロセスが用意されています。このモジュールでは、アプリケーションライフサイクル管理 (ALM) プロセスと、次の 3 種類の開発モデルをご紹介します。
  • 変更セット開発モデル
  • 組織開発モデル
  • パッケージ開発モデル

大まかに言えば、この 3 種類の開発モデルはすべて同じ ALM プロセスに従います。モデル間の違いは、組織への変更を管理する方法です。ソフトウェアの開発では変更の管理が重要な部分を占めるため、どのようなオプションがあるのかを認識していれば、各自の状況に最適な開発モデルを選択できます。

では、時が経つにつれて開発上の課題が変化していく中で、Salesforce を導入している会社とそのシステム管理者がどのように対処していくのか見てみましょう。このストーリーの展開におけるさまざまな状況のニーズに、各開発モデルでどう対応するのかを学習します。開発モデルの使い方については、このトレイルに記載の他のモジュールで詳しく説明します。

メモ

メモ

同じ様な状況でも、あなたやそのチームが、このモジュールに登場する架空の会社とは異なる選択をするかもしれません。ここで重要な点は、どのような選択肢があるかを認識しておくことです。

Zephyrus Relocation Services, Inc で Salesforce システム管理者を務める Calvin のご紹介

バージニア州フェアファクスにある移住サービス企業の Zephyrus Relocation Services で、Calvin Green はさまざまな IT 業務を担当しています。その 1 つが、同社の小規模ながら拡大を続ける営業チームのために Salesforce をカスタマイズすることです。本番組織の設定インターフェイスを使用して、各種の素晴らしいダッシュボードやレポートを作成しています。

Calvin は、退役軍人や現役軍人、その配偶者らを対象とした職業訓練やキャリアアップのプログラムである Vetforce を通して、Salesforce システム管理者としてのスキルを磨きました。

Zephyrus のデスクの横で、Calvin が Vetforce のコーヒーカップを持って立っています。

本番組織で安全に変更できる機能

新しい機能の中には本番組織で安全に開発できるものもあります。新しいダッシュボード、レポート、メールテンプレートの開発など、データに影響のないカスタマイズは本番組織で安全に作成できます。けれども、特定のカスタマイズを本番組織で直接行うとデータの削除やそれ以上に深刻な不具合が生じ、本番組織に混乱を来すおそれがあります。

変更をテストしないまま本番組織にリリースすれば、次の状態に陥る可能性があります。

  • ワークフロールールの誤動作によって無限の処理ループが生じる。
  • 項目のデータ型を変更したためにデータが変更され、元に戻せなくなる。
  • 入力規則にロジックエラーが生じ、レコードを保存できなくなる。
  • ページレイアウトの変更により、操作性を向上させるはずが、ユーザを混乱させる。

組織をカスタマイズする一番安全な方法は、開発専用の環境を使用して変更を行い、テストすることです。実際、開発環境で行わなければならない変更もあります。たとえば、本番組織で直接 Apex コードを記述することはできません。

変更セットへの移行による安全なカスタマイズ

Zephyrus が成長を続ける中、Salesforce のカスタマイズの依頼が増大しています。そこで同社は担当者を 1 人増員しました。カスタマイズの依頼が増えているのは新しいワークフロールールやページレイアウトなどですが、Calvin はこれらの変更を敢えて本番組織で直接行わないことにしています。

Zephyrus では変化するビジネスニーズに対応するために、Professional Edition にアップグレードすることにしました。Professional Edition では、分離した開発環境で宣言型 (ポイント & クリック) 開発ツールを使用して、必要な機能を作成し、テストすることができます。

変更セット開発モデルでは、Calvin と同僚の Ella が宣言型ツールを使用してアプリケーションを管理できます。Calvin らは、後方支援する営業チームのカスタマイズのニーズの増加に対応するために、コマンドラインインターフェイスやバージョン管理システムを使用する必要がありません。

宣言型ツールで、営業チームの生産性を高める優れた機能をいろいろ作成できます。たとえば、Lightning アプリケーションビルダーを使用して、金額が 100 万ドル以上の場合は商談ページにリッチテキストコンポーネントを表示する検索条件を作成できます。

Lightning アプリケーションビルダーを使用して検索条件を作成

混乱から秩序へ

複数の環境で複数の人々によってカスタマイズが行われている状況で、たとえ些細な変更でもその下流への影響を管理するにはどうすればよいか Calvin は検討しています。

たとえば、取引先責任者の標準オブジェクトには取引先責任者種別の項目がありません。Calvin はこのカスタム項目を簡単に追加して、新しい [Contact Type (取引先責任者種別)] 項目をすべてのユーザにすぐリリースすることができます。けれども、その前に次の点を考慮する必要があります。

  • 新しい [Contact Type (取引先責任者種別)] 項目が、誰かが行ったカスタマイズと競合しないか?
  • 営業チームにこの新しい項目の使い方がわかるか? トレーニングが必要か?
  • この項目が必須の場合、インテグレーションやインポートプロセスを更新する必要はないか?
  • この項目をどこに表示するか? すべてのページレイアウトに表示するのか? どのリストビューにするか? すべてのレポートやダッシュボードに表示するのか?
  • リードオブジェクトにもこの項目が必要か? 必要ならば、リードの取引開始プロセスも変わるのか?
  • 他のシステムとのインテグレーションにこの項目は必要か? 必要な場合、ミドルウェア、項目の対応付け、エンドポイントなども変更しなければならないかもしれない。

Salesforce Trailblazer Community で Calvin は他のメンバーから、Salesforce が推奨する、アプリケーションの新規開発やカスタマイズでのアプリケーションライフサイクル管理 (ALM) の手順を確認してみることを勧められます。

Calvin は Salesforce 開発者 Web サイトで、ALM により、設計からリリースに至るアプリケーション開発の管理プロセスが明確になることを知ります。ALM を採用すれば、後々アプリケーションのバグ修正や機能強化を行う際のフレームワークも確立されます。

プロセスを追加すれば、開発に時間がかかるのでは?

IT 部門の部長である Ernesto Rondán とのミーティングで、Calvin はアプリケーションライフサイクル管理への移行を提案します。ALM にはアプリケーションのスムーズなビルドに役立つプロセスやポリシーが用意されているため、何かを破損することなく迅速な開発が可能になります。アプリケーションやツールはさまざまですが、ALM サイクルの手順は Salesforce のどのような開発プロジェクトにも適用できます。

ALM サイクル: リリースの計画、開発、テスト、リリースのビルド、リリースのテスト、リリース

ステップ 1: リリースを計画する
最初に、カスタマイズまたは開発プロジェクトの計画を立てます。要件を収集して分析します。製品マネージャ (または同等のロール) に、設計仕様を作成し、実装に向けて開発チームと共有するよう依頼します。ALM サイクルに沿ってプロジェクトを進める中で、チームに必要となる各種の開発環境やテスト環境を判断します。
ステップ 2: 開発する
設計仕様に従って開発作業に取り組みます。この作業は、本番データのコピーを取り込んだ環境で実施し、本番組織のメタデータは使用しません。Lightning プラットフォーム上で、宣言型ツール (プロセスビルダー、カスタムオブジェクトウィザード、UI などの機能) とプログラム型ツール (開発者コンソール、ソースコードエディタ、Visual Studio Code) を適宜組み合わせて開発します。
ステップ 3: テストする
他の人々の作業と統合する前に、各自の変更を実行し、意図したとおり動作することを確認します。各自のテストは、開発ステップと同種の環境で行いますが、各自の開発環境と統合テスト環境は隔離しておきます。この時点では、変更のテスト自体に集中し、変更によるリリースの他の部分やアプリケーション全体への影響についてはまだ考えません。
ステップ 4: リリースをビルドする
開発フェーズで作成または変更したすべてのアセットを 1 つのリリースアーティファクトにまとめます。これは、本番組織にリリースするカスタマイズの論理バンドルです。ここからは、各自の分担作業ではなく、リリース全体に目を向けます。
ステップ 5: リリースをテストする
実際にリリースする内容をテストしますが、本番組織に極力近づけたステージング環境で安全にテストします。典型的な本番データの現実的な量を使用します。本番システムのインテグレーションポイントを模倣するために必要なすべての外部システムに、テスト環境を接続します。このステップで、完全な回帰テストと最終的なパフォーマンステストを実施します。フィードバックを依頼する経験豊富な少人数のユーザを対象にリリースをテストします (この手法をユーザ受け入れテストといいます)。
ステップ 6: リリースする
テストが完了し、品質ベンチマークを満たしたら、カスタマイズを本番組織にリリースできます。従業員やパートナーに変更内容を説明するトレーニングを実施します。リリースによりユーザに多大な影響がある場合は、ユーザトレーニング用に現実的なデータを設定した環境を別途作成します。