チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

Salesforce Webinar 「Salesforce DX の始め方とパートナー様成功事例」(前編)

こんにちは、倉谷(id:a-kura)です。

今さらな感じですが、Salesforce Webinar にゲスト登壇しました。そこで、前編では発表内容、後編ではその後に取り組んだDevHub移行の課題について紹介します。

はじめに

2019年8月30日に開催されたセールスフォース・ドットコム社主催の Webinar にゲスト出演しました。この Webinar では、Salesforce DX の活用事例を2社、co-meeting 木村さんとチームスピリット倉谷から話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。

developer.salesforce.com

Salesforce DX の始め方とパートナー様成功事例

f:id:a-kura:20191125125018p:plain

私から Salesforce DX の活用事例として、CI環境構築における活用事例を話しました。 まず、背景として CI 環境が必要となる理由についてです。

チームスピリット社では、AppExchangeのOEMアプリケーションを開発・提供しています。 このB2Bサービスである TeamSpirit は1100社、17万IDに利用されています。

これだけのお客様に継続して利用していただくために開発に関わるメンバーも増えてきています。 そこで、サービスの品質を高いレベルで保ちつつ、チームで開発を進めるための基盤の一つが継続的インテグレーション (CI : Continuous Integration) です。

Salesforce World Tour Tokyo 2017 ふりかえり

f:id:a-kura:20191125125318p:plain

実は、Salesforce World Tour Tokyo 2017 で当時の CI 環境と Salesforce DX を使ってどういったことを実現したいか、について発表しました。 まずは、その当時のことをふりかえりをさせてもらいます。

2017年当時の開発環境

f:id:a-kura:20191125125704p:plain

2017年当時は、下記のような開発環境で開発していました。

開発者は各自で Developer Edition 組織を利用して開発しており、エディタは Eclipse / SublimeText など、デプロイは Migration Tools や gulp / jsforce などを利用していました。
CI としては Jenkins を使って Migration Tools で自動テストなどを実行していました。

2017年当時の継続的インテグレーション環境

f:id:a-kura:20191125125815p:plain

CI 環境について、もう少し詳しく説明します。

CI 環境は Jenkins を Amazon EC2 上で動かしており、Apex テスト、E2E (End to End) 自動テスト、静的解析、ドキュメント生成などを実行していました。
実は、2017年当時の段階でも CI に必要なものはほぼ揃っていました。

Salesforce DX Upgrade History

f:id:a-kura:20191125142045p:plain

Salseforce World Tour Tokyo 2017 で発表してからこれまで2年間ありましたので、Salesforce DX のアップグレードの2年間の歩みをまとめてみました。

Winter'18 が2017年秋頃で SalesforceDX CLI、スクラッチ組織、VS Code 向け開発ツールが正式リリースされています。 DevHub が Developer Edition 組織で利用できるようになったのが Winter'19 です。このあたりから徐々に開発者も試しやすくなってきました。 次に、管理パッケージ周りの機能が強化され始め、Spring'19 でロック解除済みパッケージ、Winter'20 で第2世代管理パッケージがリリースされていきます。

加えて、Summer'19 で任意組織に対する開発機能が強化されています。ここでは、任意の組織に対してソースコードを retrieve / deploy する機能が正式リリースされました。これによって、スクラッチ組織をベースとした新しい開発スタイルだけではなく、従来どおり組織のソースコードを retrieve / deploy する開発スタイルも問題なくできるようになりました。

このことは、単にSalesforce DX を利用して従来の開発スタイルで開発できるようになった以上の意味があります。これまでは一気にスクラッチ組織を使った開発に移行しなければいけないイメージがありましたが、この機能の登場で段階的に Salesforce DX の新しい開発スタイルに移行できるようになりました。

弊社はこれに先立って、2019年3月から Salesforce DX への移行開始しました。これは、一部の開発メンバーが利用していた Mavensmate のサポートが終了することを受けて、開発環境の見直しの中で移行することを決断しました。

チームスピリットにおける Salesforce DX 活用状況

f:id:a-kura:20191125130021p:plain

現在のチームスピリット社の Salesforce DX の活用状況です。

開発者はエディタとして VS Code を 利用し、Developer Edition 組織に SalesforceDX CLI でデプロイしています。
スクラッチ組織では、組織が有効期限切れでなくなってしまう、データを別のスクラッチ組織に移行する方法が確立しておらずテストデータを入力し直す手間がかかってしまう、ことからスクラッチ組織はまだ利用せず Developer Edition 組織を利用しています。

CI 環境はこれまで Jenkins を利用していましたが、現在 CircleCI に移行中です。
CircleCI に移行している動機は、開発チームが大きくなり開発基盤としての継続的インテグレーションの重要性が高まってきており、自分たちでマネージする必要がある Jenkins が重荷になってきているためです。
CircleCI はマネージドなサービスであり、インフラの保守などの手間がかからないため、自分たちで運用するよりも安定的で手間をかけずに利用できます。

チームスピリットにおける Salesforce DX 活用状況(継続的インテグレーション)

f:id:a-kura:20191125144044p:plain

続いて、CI 環境について説明します。

現時点では、JavaScript Unit Test、Flow による型チェック、Prettier による Code Formatter といった JavaScript に関する処理を主に移行しています。 Apex テストも master ブランチの自動テストは移行していますが、もう少し高度化していく必要があります。

Salesforce DX CLI の活用例

f:id:a-kura:20191125144509p:plain

ここで少し SalesforceDX CLI で利用しているコマンドについて紹介します。

JWT 認証、スクラッチ組織作成、ソースコードのプッシュ、ユーザー追加、パーミッション付与はワークブックなどにも出てきます。 その後、スクラッチ組織にデータをインポートしています。

弊社のプロダクトでは履歴管理を行うマスタがある、などデータ構造が複雑になっています。 そのため、インポートだけではデータを作りきれなかったり、繰り返し処理で作成したほうが保守性に優れていたりすることから、Apex コードによるデータ作成も行なっています。
force:apex:execute を利用すると Apex コードを直接実行することができるため、データ作成以外にもいろいろな活用ができます。

Salesforce DX 活用度

f:id:a-kura:20191125144939p:plain

Salesforce DX 活用度を独自に3段階に分けてまとめてみました。

評価項目としては、SalesforceDX CLI、Scratch Org、管理パッケージ、静的解析、コードフォーマットを用意しました。 自社の活用度としては、背景がオレンジのところまで進んでいます。

Salesforce DX CLI については活用度が高くなっていますが、Scratch Orgや管理パッケージについては活用度が低く今後の課題となっています。

Salesforce DX の所管

f:id:a-kura:20191125145147p:plain

SalesforceDX の所感として、私の感じたことをまとめておきます。

まず、良い点としては VS Code の Salesforce DX 拡張機能がとても出来が良いです。 弊社のプロダクトではソースコードのボリュームが増えてきたため、差分デプロイできるのは非常に助かります。

今後、開発する場合はSalesforceDXを使わない手はないと思います。

今後の課題

弊社の今後の課題としては、Scratch Org の活用拡大、第2世代管理パッケージの活用があります。

Scratch Org の活用拡大

先ほど master ブランチだけで CI を実行している、ことを話しました。

これは DevHub として Developer Edition 組織を利用しており作成できるスクラッチ組織の数が限られるため、 master ブランチ以外で CI を実行できていません。 今後はよりスクラッチ組織を作成できる PBO (Partner Business Org) などに移行していきたいと考えています。

第2世代管理パッケージ

第2世代管理パッケージについては、Winter'20 で GA となりました。

とはいえ、既存の管理パッケージについては移行が今後の開発予定となっています。 当面は、第2世代管理パッケージの研究を進めながら移行機能のリリースを待ちたいと思います。

おわりに

前編では、Salesforce Webinar の発表内容についてご紹介しました。2019年8月末に発表して3ヵ月程度経過したので、その後に解決できた課題について後編で紹介したいと思います。

エンジニア募集♪

チームスピリットでは、アジャイルなプロダクト開発を共に推進してくれるエンジニアを募集しています。どんな考えや想いで開発しているのか少しでも興味を持っていただいた方、ぜひご連絡ください!(直接メッセージでも、下記の応募フォームからでも構いません)

https://www.teamspirit.com/ja-jp/recruit/r_d.html

Enjoy DX!