【Salesforce次世代開発モデル】ロック解除済みパッケージを使用した開発モデル

今回はSalesforceの次世代の開発モデルである「ロック解除済パッケージ」を使用した開発モデルをご紹介します。 　　

「Salesforceのパッケージ」というワードからISV向けの機能を連想される方も多いのではないでしょうか。 旧式のいわゆる第一世代パッケージを社内アプリケーション向けに展開するには多くの課題がありました。
　　

今回紹介する「ロック解除済パッケージ」は、社内アプリケーション向けに最適化された第二世代のパッケージです。

従来の開発モデルでは「変更セット」「Metadata API」「手動設定」を駆使してリリースを行っていました。しかしながら、肥大するカスタマイズ量に比例しリリース管理のコストも増加し、場合によりリリース時の手動設定が増えるなど、いくつかの課題が発生していました。 　　

これらの問題を緩和するソリューションとして「ロック解除済みパッケージ」は機能し、 以下のような特徴を持っています。 　　

• メタデータがパッケージバージョン毎に管理され、アップデートやメンテナンスが容易になる
• 変更に対する柔軟性(メタデータは本番組織で直接変更可能)
• 開発リソースがパッケージ単位で整理される事で開発効率が向上
• 不具合のスコープを限定しやすくする

• 名前空間が不要であり、既存のインテグレーションに影響を与えない 　　 　　

  　

Salesforce DXと統合された「ロック解除済みパッケージ」の開発からリリースまでのおおまかな一連のフローについてご紹介します。

事前準備

以下の設定を行ないます。

ローカル環境

• Salesforce CLI(v44.0以上)のインストール

Salesforce環境

• 私のドメインの有効化

設定 > クイック検索から「Dev Hub」を検索し以下の設定の有効化を行います。

• Dev Hub を有効化
• ロック解除済みパッケージ (正式リリース) と第二世代管理パッケージ (ベータ) を有効化 　　

注意事項

• 「私のドメイン」を本番環境で設定する場合は、既存のインテグレーションに影響を与える可能性があります。
• Dev Hubや第二世代パッケージは有効化すると無効化出来ないのでご注意ください。
• 第二世代「管理」パッケージはSpring’19時点でベータ版です。

スクラッチ組織の作成

まずはスクラッチ組織を作成します。

sfdx force:org:create -s {スクラッチ組織の別名}

　　※管理を容易にする為、スクラッチ組織の別名の設定を推奨 　　

ローカルからスクラッチ組織へのソースのPush

sfdx force:source:push -u {ユーザ名 or エイリアス}

スクラッチ組織からローカルへのソースのPull

sfdx force:source:pull 　　

パッケージの作成

sfdx force:package:create -n {パッケージ名} -t Unlocked -r {パッケージのリソースのPATH}

CIツールを使用して構文チェックや自動テストによる不具合の早期検知を行います。

コード解析

sfdx force:lightning:lint {チェック対象ソースpath}

自動テストの実行

Apex単体テスト

sfdx force:apex:test:run   　　

Lightning Testing Servies

sfdx force:org:open -p {テストアプリのpath} 

　　※Lightnng Testing Serviesについてはこちらを参照ください。

パッケージのインストール

sfdx force:package:install -u {ユーザ名 or エイリアス} -p {パッケージ名}

パッケージのインストール

sfdx force:package:install -u {ユーザ名 or エイリアス} -p {パッケージ名}

仮想ケースとして、巨大な見積アプリケーションをパッケージ化するケースについて考えてみましょう。

見積アプリケーションを１つのパッケージに纏める方法も考えられますが、複数チームで改修を行う場合、下図のように「ベースパッケージ」 + 「拡張パッケージ」という構成で、パッケージ単位でチーム開発を行う事で、責任を分割しチーム開発をスケールさせる方法が考えられます。

次にロック解除済みパッケージの実践投入について考察を記載しました。

<Salesforce新規導入時>

多くのケースでは障壁が少なくスムーズに適用可能と考えられます。

<既存組織>
既存の組織型の開発を行っている場合はどのように適用すればよいのでしょうか。

• ビックバン方式で一括でパッケージ化に舵を切りリリースする方法
• 一部の機能を切り出してパッケージ化していく方法

が考えられます。

多くの既存アプリケーションが存在する場合は、ロック解除済みパッケージを既存の一部の機能から徐々に移行を行うか、依存関係のない新機能に適用する事で、リスクを抑えて試験的に導入する方法が現実的な線ではないでしょうか。

今回は、詳細は割愛していますが、バージョン管理システムのブランチモデル( Git Flowなど)や、高速に開発・テスト・リリースサイクルを回すためのCIツールの導入について事前に検討すべきかと思います。

CIツールの導入についてはSalesforce開発者ガイドに紹介されていますのでご覧ください。