Node.jsと仲良くなって Salesforceアプリケーション開発を楽しく行う / cariot-salesforce-summer2016tokyo

Salesforce Summer 2016 TokyoでLTした時の資料です。

Transcript

1. と
 Salesforce Summer 2016 Tokyo 2016-07-21 株式会社フレクト　遠藤 匠 Node.jsと仲良くなって Salesforceアプリケーション開発を楽しく行う 〜 〜
2. 自己紹介 •遠藤　匠 •株式会社フレクト Cariot事業部 •業務 • コネクテッド・カーサービス「Cariot」の開発・運用 •Salesforce歴：1年半
3. 2016/05/09 AppExchangeにて公開
4. 開発環境 パッケージ リリース環境 （DE） インポート (retrieve) デプロイ 個人開発環境 （DE） デプロイ・テスト CIサーバ（Jenkins） push ソースコード取得 CI環境 （DE） テスト
5. ツール コード管理 チケット管理 ビルド 依存関係解決 Salesforceへのデプロイ・エクスポート・テスト JSforce Metadata Tools POINT
6. Force.com移行ツールを使ってない理由 • JavaよりもXMLデータの加工が簡単（ライブラリが揃っている） • メタデータのデプロイ、エクスポートの際に、メタデータやpackage.xmlな ど、XML形式ファイルの加工を行う必要があった •ローカルでのSPA開発のためのエコシステムとの統一性 • 全部Node.jsで統一できる • 逆に、Force.com移行ツールと比較しての短所は？ • Jenkins連携（ant-salesforce-ciによるApexテスト、カバレッジレポート） • くらい？
7. JSforceでもレポート出力できる
8. JSforce版 ant-salesforce-ci （一部） JSforce Metadata Toolsの テスト実行結果を元に、 JUnit形式のレポートを出力 （カバレッジレポートも仕 組みは同じ）
9. デプロイ HTML CSS JS その他 メタデータ JS
 静的リソース （zip） Visualforce コンポーネント zip化 package.xml gulp-webpack gulp-zip gulp-html-replace Webフォント 一部、自作gulpプラグイン （日英切り替え） ファイルパスをNFCに変換 UTF-8-MAC(NFD)対応
10. HTMLをVFコンポーネント(ページ)に変換 <!-- build:hoge --> <!-- endbuild --> で囲んだVisualforce用の <apex:component> タグに置換 （置換箇所は複数定義可） xxx-meta.xmlファイルも 変換と一緒に作成 （xmlbuilderという ライブラリを利用）
11. エクスポート ①package.xmlの書き換え ・ワイルドカードが使えないメタデータについて、 　listMetadataで取得して書き換える 　　・Report 　　・Dashboard 　　・Document 　　・CustomObject 　　・Layout ・Report/Dashboard/Documentはいきなり 　リストで取得できないので、まずフォルダ名を 　取得する　 ②package.xmlを元に メタデータを取得
12. ローカル開発の勘所 • Salesforceへの依存をApex(JavaScript Remoting)だけに最小 化する • ローカルではモックを利用 • 同一コードで環境（ローカル or Visualforce）を判断させる必要があ るので、やむなくtypeofで判断 • Remotingではなく、RemoteObjectという手もあるが、マークアップ が面倒だし、DML、クエリはApex側にすべて寄せた方がよい気がする • Visualforceタグの利用は最小限に留める • <apex:page><apex:component><apex:attribute>くらい • {! } の利用も最小限に留める • 静的リソース中のJSにこれがあると解釈できない
13. まとめ •JSforceを使ってメタデータとうまく付き合おう •ローカルでSalesforceアプリケーションをさくさ く開発できる •GitHub FlowやCIなどのプラクティスを Salesforce開発でも同じように •一般的なフロントエンド技術の導入