2016-12-12

Salesforce Package Manager "SPM"を作ってみた

Salesforceのパッケージ管理システム"SPM"をリリースしましたー

一応マルチプラットフォーム対応で、バイナリも配布しているので是非お試しください。マルチプラットフォーム対応を謳っておきながらwindowsでの動作は全くの未確認(!)なので、不具合があればissueやらPRやらお願い致しますー。

モチベーション

SalesforceにはApp Exchangeというパッケージアプリのマーケットプレイスがあったり、AppExchangeに公開していなくても独自にパッケージを作成してインストール用のリンクを公開することで、パッケージを配布することができます。しかしながら、Web開発におけるパッケージ管理とは異なったアプローチになることや、非管理パッケージの作成をGUIで行ったりする手間がイケていない感じがしており、コマンドラインでSalesforceのメタデータをデプロイしたいなーというのがモチベーション。jsforce等の便利ツールがありますが、マルチプラットフォームで簡単に動くものを作りたかったというのもあります。

また、こういった記事↓もあるので需要はありそうだなーと感じたのもモチベーションの一つ(というか、この記事を見て作ろうと思った)

コンセプト

現状実装されていない機能もありますが、以下が基本機能 npm、rubygem、pypiみたいにモジュールをリポジトリ用のサイトに登録する管理方法もありますが、リポジトリにアップロードするためのコマンドが必要だったり、サイト用意しないといけなったり、色々と面倒です。ということでSPMでは、goやbrewのようにgithub等のリモートリポジトリを利用する方式を取りました。ダウンロード数は取れないけど、まぁこんなツール誰も使わないし流行らないから良いよね

インストール方法

goがインストールされている場合は以下でインストール
$ go get github.com/tzmfreedom/spm

また、OS X、Windows向けのバイナリも配布しています。golangはマルチプラットフォーム対応のシングルバイナリの配布を簡単にできるのがメリットで、実装言語にgolangを採用した一番の理由になります。

使い方

パッケージのインストールは以下のコマンドで行います。
$ spm install {REMOTE_REPO_USERNAME}/{REPOSITORY_NAME} -u {USERNAME} -p {PASSWORD}
$ spm install {REMOTE_REPO_HOSTNAME}/{REMOTE_REPO_USERNAME}/{REPOSITORY_NAME} \
-u {USERNAME} -p {PASSWORD}

具体的にはこんな感じで指定すればOK(さりげなく作ったApexからTreasureDataのAPIをコールするクライアントをインストールする例)

$ spm install tzmfreedom/apex_tdclient -u {USERNAME} -p {PASSWORD}

ホスト名を省略した場合はgithubのリポジトリを見に行きます。

Sandboxの場合はこんな感じで

$ spm install {REMOTE_REPO_USERNAME}/{REPOSITORY_NAME} \
-u {USERNAME} -p {PASSWORD} -e test.salesforce.com

またYAML形式のパッケージファイルを作成して、一括でパッケージをインストールすることも出来ます。

packages:
- github.com/tzmfreedom/apex_tdclient
$ spm install -u {USERNAME} -p {PASSWORD} -P {PACKAGE_FILE_PATH}

リポジトリ

リポジトリのファイル構成ですが、なんてことはない普通のデプロイのファイル構成になっていればOK。
.
├── classes
│   ├── TDClient.cls
│   └── TDClient.cls-meta.xml
└── package.xml

現在はルート直下にpackage.xmlがあるようなファイル構成を想定していますが、ゆくゆくはサブディレクトリ内にpackage.xmlがあるような構造でも取ってこれるようにしたいなーと思ってます。

内部実装について

内部実装というほど仰々しい作りにはなっておらず、大枠でこれだけです↓
  1. リモートリポジトリからローカルにClone
  2. CloneしたメタデータをSalesforceにデプロイ
使ったgoのライブラリはこんな感じ あとは、forceのライブラリでメタデータを操作するものが無かったので、WSDLからクライアントを自動作成するgowsdlを使いました。ただし、生成したものをそのまま利用するのではなく修正が必要で、これらのTIPSは別の記事として書きたいと思います。誰も得しないと思うけど…

今後の拡張予定

ここまで作った&書いたけど需要あんの?

一般的なWebの開発だと、依存ライブラリのコード本体をリポジトリに置くことはなく、依存ライブラリとバージョンを指定したファイルを記述してそれをリポジトリに配置し、デプロイ時は依存ライブラリを各パッケージ管理ツールで展開することになります。Salesforceの開発ではたとえばパッケージ管理ツールがあったとしても、そのような使い方はせず、依存ライブラリのコード本体ごとデプロイするのが普通です。ということでデプロイ時の依存ライブラリ解消という意味合いではあまり使えないかもしれません。

ただしコマンドライン一行で任意のライブラリを開発環境に簡単に追加できるという利点はあります。今までのコピペやデプロイの手間は少しだけ軽減できるような気がします。エコシステム活性化の意味で、記述が面倒なpackage.xmlをYAMLで書けるようなツールもSPMコマンド内に含めて、開発者はYAML書いてコマンド叩くだけでretrieveできる仕組みも作りたいと思っています。まぁpackage.xmlをYAMLで書けるようにするだけなので誰得なツールって感じですが…

ということで、SPMを使ってもらえたら嬉しいなー。

※本記事はSalesforce App Cloud Advent Calendar 2016の12日目の記事です。

このエントリーをはてなブックマークに追加