Salesforce

Salesforce DX PackagingとDCP (Developer Controlled Package)

Salesforce DX Packaging とは、Salesforceでソース駆動開発をする際に便利なアプリケーションのアーカイブ・配信機能のことです。(2018年4月現在現在βリリース)
今までのパッケージ機能はどちらかとういうとアプリを多数の顧客に配布するISV向けの機能でしたが、この新しいSalesforce DX PackagingではSIなどの単一組織向けのアプリ開発でも利用価値があり、今後期待の機能です。

そもそもSalesforce DX自体がSalesforceでソース駆動開発を実現するものなのですが、そこからあまり知らないという方はまずはこちらを御覧下さい。
dx.png

アプリケーション開発をモダンに変える Salesforce DX
Salesforce DXとHeroku Pipelineを組み合わせる

Salesforce DX Packagingの利点としては以下のようなものが挙げられています。

  • 開発ライフサイクルの改善 - API Freandlyな設計 & Salesforce CLI コマンドが提供されているので、スクラッチ組織などと合わせて効率の良い開発ライフサイクルを構築できる。
  • メタデータ制御 - エンタープライズ顧客向けオプションで、メタデータの本番組織へのデプロイをコントロールできる。
  • 同一名前空間に複数のパッケージ - 同一名前空間に複数のパッケージを作成でき、同一パッケージ間ではGlobalでなくてもPublicアクセス修飾子同士のApexクラスが呼び出せるため、より簡単にApexコードなどをパッケージをまたいで共有ができる。
  • テスタビリティ - 容易にブランチでの開発及びテストを行える。
  • ソース駆動 - パッケージはソースコードからダイレクトに作成することが可能

ということで、Salesforce開発においてのデプロイ・リリース作業が楽になるかもしれない、ということで触ってみます。

Salesforce DX Packageの仕組み

今までのSalesforceのパッケージは、名前空間の設定されたDeveloper Edition組織上にあるソースコードをパッケージ化していましたが、Salesforce DX Packagingでは、ローカルにあるソースコード及び設定ファイルを使ってDevHub組織にパッケージを生成します。
ここで一番基本となるのがSalesfore DXプロジェクトのトップディレクトリにあるsfdx-project.jsonファイルです。
このファイルの中に、"path"や"id"の属性がありますが、この値を元にパッケージが生成される様になっています。

sfdx-project.json
{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "id": "",
      "versionName": "v 2.3",
      "versionDescription": "ver 2.3",
      "versionNumber": "2.3.0.NEXT",
      "ancestorId": ""
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "42.0"

このサンプルではパッケージは一つですが、PackageDirectoriesの中には複数のパッケージを含むことが出来るので、例えばバックエンドのcommonライブラリのパッケージと、UI周りのパッケージと分けるといったことも可能です。
また、sfdx-project.jsonファイルにはdependenciesancestorIdといった項目を記述し、依存しているパッケージやバージョンアップする元のパッケージを指定できるようになっており、設定ファイルから構成のコントロールが可能です。

Salesforce DX Packageの種類

Salesforce DXでは大きく分けて3種類のパッケージを作成できるようになっています。今までの一つのアプリを複数組織に配るのに最適な管理パッケージに加え、単一のSalesforce組織を継続的に開発していくのに適したDCP(開発者制御パッケージ - Developer Controlled Package)が利用できるようになっています。

Managed

旧来からある管理パッケージに近い方式です。
Salesforceは本番環境でエンドユーザが設定を変更することがあるプラットフォームですが、Managedパッケージではエンドユーザが行った変更に影響の出ないように制御を行い下位互換を維持しつつも、アプリケーションのバージョンアップを可能にします。

DCP Unlocked

開発側が常に上書きを行うパッケージング方式です。
エンドユーザはDCP Unlockedでインストールされたアプリケーションをカスタマイズすることは出来ますが、パッケージをアップデートする際にそれらエンドユーザが行った変更を開発者が上書きすることができます。

DCP Locked (現在パイロット)

開発側側が提供したアプリケーションが全てロックされるパッケージング方式です。
DCP Lockedでインストールされたパッケージは本番環境でエンドユーザが設定を変更することができません。
ガバナンスを効かせて、開発チームが組織の状態を完全にコントロールしたい場合に有効です。

このように3種類のパッケージングが可能になったことで、開発方法に幅が生まれます。

Salesforce DX Packageの作成方法

では実際にSalesforce DX Packageを作ってみます。Salesforce DXパッケージはローカルにあるSalesforce DXプロジェクトのソースコードをDevHub組織を介して配信するので、まずはDevHub組織への接続を行います。

サンプルとして、以下のGithubのリポジトリなどにサンプルのSFDXプロジェクトがあるので、git cloneして利用すると良いでしょう。

shell
$ git clone https://github.com/dreamhouseapp-jp/dreamhousejp-sfdx.git
$ cd dreamhousejp-sfdx

次にDevHub組織へのログインを行い、接続を確立します。

shell
$ sfdx force:auth:web:login -d -a HubOrg
## ここでWebブラウザが立ち上がるので、DevHub組織のId/Passwordを入力してログイン

この際、特に既にDevHub組織でSalesforce DX Packagingを利用する設定になっていれば問題ありませんが、まだ有効化していない場合は、設定からDev Hubの項目へ行き、Packaging 2(ベータ)を有効にしましょう。

devhub.png

そしてPackage2コマンドを利用してパッケージの生成を行います。
この際-o(--containeroptions)オプションを指定することによって、パッケージの種類を選ぶことができます。
ここではDCP Unlockedを指定して、パッケージを生成します。

shell
$ sfdx force:package2:create -n new_package -d "New Package" -o Unlocked

これでSaelsforce DX Packageの作成が出来ました。
自分が作ったパッケージの情報を確認したい場合にも、sfdxコマンドを使って確認を行えます。

shell
$ sfdx force:package2:list

DCP Unlockedで Package versionを作成

ここまでの手順でパッケージを作成しましたが、パッケージの作成だけでは、実際に配信するアプリの 名前と配布場所の確保をしただけ のような状態であり、実際に配信やインストールは出来ません。
そのために配信可能な Package Version を生成する必要がります。

shell
$ sfdx force:package2:version:create -i 0Ho0K0000008OI5SAM

Package Versionの生成には、Packageのidを指定するか、sfdx-project.jsonで指定されたpathにidの項目が入っていれば、pathの指定(-d)でも生成することができます。
一旦Packageの作成が終わったらsfdx-project.jsonをアップデートしておくと良いでしょう

sfdx-project.json
{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "id": "<ここにPackageのID (0Hoから始まる)を入れる>",
      "versionName": "v 1.0",
      "versionDescription": "ver 1.0",
      "versionNumber": "1.0.0.NEXT",
      "ancestorId": ""
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "42.0"

上記のように設定をアップデートすれば、パッケージの生成はPathの指定でも行えます。

shell
$ sfdx force:package2:version:create -d force-app

Package versionの生成は非同期のため、コマンド打って即座には生成されません。
そのため、コマンドを入力してステータスを確認しろというメッセージが届きます。

shell
Package2 version creation request is InProgress. Run "sfdx force:package2:version:create:get -i 08c0K0000008OI5QAM" to query for status.

このメッセージの通りに確認をすれば、いずれパッケージが生成されて、インストールURLなどが発行されます。
誰かにインストールを促す場合には、このインストールURLを提供すれば、パッケージをテストすることが可能です。

shell
$ sfdx force:package2:version:create:get -i 08c0K0000008OI5QAM
=== Package2 Version Create Request
NAME                            VALUE
──────────────────────────────  ─────────────────────────────────────────────────────────────────────────────────
ID                              08c0K0000008OI5QAM
Status                          Success
Package2 Id                     0Ho0K0000008OI5SAM
Package2 Version Id             05i0K0000004C93QAE
Subscriber Package2 Version Id  04t0K0000016CvYQAU
Tag
Branch
Created Date                    2018-03-27 01:01
Installation URL                https://login.salesforce.com/packaging/installPackage.apexp?p0=04t0K0000016CvYQAU

Package VersionのCLIからの配布

せっかくCLIでプログラマブルにインストール可能なパッケージを作成したのに、インストールがURLをクリックしてブラウザでインストールではテンポが悪くなってしまいます。
そこでSalesforce DX Packagingでは、インストールも行うことができるコマンドが用意されています。

shell
$ sfdx force:package:install -i 04t0K0000016CvYQAU -u me@my.org

インストール側で指定するIDは、04tではじまるSubscriber Package2 Version Idというインストールする側のIDを指定します。
パッケージのインストールもPackage Versionの作成と同じく非同期で行われるので、ステータス確認用のコマンドが表示されます。

shell
PackageInstallRequest is currently InProgress. You can continue to query the status using sfdx force:package:install:get -i 0Hf0I000000TmDkSAK -u me@my.org

ということで、手順に従ってステータスを確認すれば、パッケージがインストールされている事が確認できます。

shell
$ sfdx force:package:install:get -i 0Hf0I000000TmDkSAK -u me@my.org
Successfully installed package [04t0K0000016CvdQAE]

もちろん、アンインストールもCLIから可能です。

shell
$ sfdx force:package:uninstall -i 04t0K0000016CvYQAU -u me@my.org

開発を進めていって、機能を追加した・不要な機能を削除した、といった場合は再度Package Versionを作成してインストールを行えば簡単に更新を行うことができます。

shell
$ sfdx force:package2:version:create -d force-app
## ステータスを確認しSubscriber Package2 Version Idを取得
$ sfdx force:package:install -i <新しいSubscriber Package2 Version Id> -u me@my.org

パッケージのリリース

ある程度の開発が完了して、パッケージにリリースフラグを立ててバージョニングを行いたい場合には-sオプションを利用します。

shell
$ sfdx force:package2:version:update -i 05i0K0000004C9DQAU -s
Are you sure you want to release package version 05i0K0000004C9DQAU? You can not undo this action. Release package (y/n)?: y
Successfully updated the package version. ID: 05i0K0000004C9DQAU.

リリースフラグを立ててもDCPの場合には新しいPackage Versionで上書きすることが可能なので、ある程度の塊の機能がリリースのされる際のタグとして利用すると良いと思います。

まとめ

packageimage.png
このようにSalesforce DX Packagingはインストール、アンインストール、アップグレードなどがCLIから可能にっていることによって、ステージング環境から本番環境までを一貫してCLIやCI/CD環境からコントロールできる可能性が広がりました。
今後の正式リリースが待ち遠しい機能ですね。

  • Sales force DX PackagingはSalesforceアプリの新しい配布方法
  • 3種類のパッケージタイプを、開発用途に合わせて選択
  • CLIからコントロールが可能なので、CI/CD環境との親和性も高い