『gulp-jsforce-deploy』をつかって静的リソースへのデプロイを行う方法を覚えたので実際にそれを使った開発を試してみました。
環境構築方法はこんな感じです。
SFDC：Salesforce Development 2016 - Part 1 - tyoshikawa1106のブログ
プロジェクトのファイル構成はこんな感じになっています。
devstaticresourcesフォルダで『.resource』形式に変換する前のファイルを管理しています。(ここでJSやCSSを開発)
staticresourcesフォルダで『.resource』形式に変換後のファイルを管理します。この中にあるファイルをSalesforce組織の静的リソースにデプロイします。
静的リソースでデプロイ後はこんな感じ。
gulp-jsforce-deployを使えば次のコマンドでpkgフォルダ内のファイルをSalesforce組織にデプロイできます。
$ foreman run gulp deploy
静的リソースへのデプロイもこれで対応できたのですが、基本的にstaticresourceフォルダ内のファイルがすべてデプロイされます。デプロイ対象はpackage.xmlで対象を指定することで制御できますが、毎回変更するのは少し面倒だなと思いました。
また、package.xmlをデプロイ時に毎回変更する場合はコミット時に前回作業者が指定したファイル名で更新されてしまいます。.gitignoreで管理対象外に指定する方法も考えられますが、それも少し面倒かなと思いました。
ということでpackage.xmlで管理する以外の方法を考えてみました。
今回試してみたのは.resource形式に変換する箇所を制御する方法です。devstaticresourcesフォルダ内でJSファイルやCSSファイルを開発して、作業後に.resource形式に変換してstaticresourcesフォルダに格納していたので、.resource形式に変換する対象を制御することで、package.xmlを変更せずにデプロイ対象を制御できると思います。
.resource形式への変換はGulpをつかって行っています。gulpfile.jsの処理内で対象のファイル名を指定する方法を思いついたのですが、直接指定する方法だと、コミット時に前回作業者が指定したファイル名が残ってしまうのがイマイチでした。(.gitginoreで除外するもの少しイマイチ...)
そこで『foreman』をつかった方法を試してみました。『foreman』を利用すればgulpの処理内でも『.env』ファイルの値を参照できるようになります。gulp-jsforce-deployが使っている方法を参考にしました。
.envファイルはこんな感じ。カンマ区切りで複数のファイルを指定できます。
.envファイルはgitのリポジトリで管理する必要が無いので、前回作業者が指定したファイル名が残ることがありません。また、作業前に毎回自分で用意する必要があるので、うっかり他のファイル名を指定してデプロイしてしまうトラブルも回避できると思います。
staticresourcesフォルダ内のファイルはすべてデプロイ対象となるので、pkg/staticresources のファイルはGitリポジトリから除外するようにしました。これで作業対象外のファイルがデプロイされることを回避できると思います。
staticresourcesもGitのバージョン管理をした方がいいと思いますが、これはsrcフォルダ側で管理すればいいと思います。
foremanと.envファイルを利用することでこんな感じで静的リソースデプロイの仕組みを用意できました。