Salesforce DX 導入への工夫 - 4事業部の600を超えるApexクラスへの対処

Visionalグループでは、めまぐるしい市場の変化に対応するべく各プロダクトが日々進化を続けており、それらを支えるSalesforceに関しても常日頃から活発にシステム改修が行われています。
今回、弊社のSalesforce担当の開発チームでは、従来の変更セットを利用した手作業中心の開発方式からSalesforce DX(以下、SFDX)およびVCS・CIを連携させることで自動化を導入した開発方式に移行しました。
本記事では、弊社のSalesforceの開発における従来までの課題とその解決への取り組みについてご紹介したいと思います。

Salesforce開発の従来の課題

2021年前半まで、弊社の開発スタイルは以下の通りでした。
※なお、SalesforceはClassicを利用しています。

• 開発者ごとにsandboxが割り当てられている
• 各自が開発したリソースを変更セットでステージ環境（sandbox）にデプロイし、テストを行う
• ステージ環境から本番環境へ変更セットを使ってリリースする
• リリース成果物は別途VCS（Github）にてバージョン管理を行う

これらは少数精鋭による開発で、かつチーム内のコミュニケーションが適切に行われていたためにうまく回っていたものの、次のような痛みを伴っていました。

変更セットへのリソースの追加作業が大変

GUIで手動でリリース対象を選択していくため、リリース規模が大きくなるほど作業が煩雑化する。

同じリソースの修正を同時に複数人で行うのが難しい

変更セットは既存リソースとのマージではなく上書きであり、競合も発見しづらい（仮に競合を発見できたとしても、マージが難しい）。
リリース後しばらくしてから上書きによるデグレードが見つかり、システム障害に発展することも。

リソースのバージョン管理ができない

リリースしたリソースをGithubにて管理はしていたものの、変更セットによるデプロイは独立した手作業であるために、Githubのリソース内容と実際のリリース物がイコールであることの担保が難しい。

以上のようなことから、品質を担保するために入念なダブルチェックが必要であったり、個人個人の熟練度に品質が委ねられたりと、効率や属人化が課題となっていました。

SFDXへの移行

今後の社内案件の規模拡大を見越した開発チームの分化および増員を機に、チームでは従来の開発手法を一新するべくSFDX導入に舵を切りました。
SFDXは強力なコマンドラインインターフェース（CLI）を持ち、変更セットを介さずにリリースができることから、煩雑な手作業をスクリプト化して自動化することで、劇的な効率向上が望めると判断したためです。

SFDXへの移行の難しさ

とはいえ、弊社のようにリソースが密結合でかつ膨大な量である場合は特に、Salesforceの既存システムをSFDX方式へ完全に移行するのはなかなかに困難です。
「ビズリーチ」「HRMOS」「キャリトレ」といった複数プロダクトのデータを保持し、600を超えるApexクラスに様々なオブジェクト参照やロジックが混在し、かつ外部パッケージもカスタマイズして利用しているので、最初の環境構築から壁にぶつかりました。

• リソースが膨大すぎて、スクラッチ組織¹へデプロイできる許容量を超えてしまう。
• ミニマムに分割しようにも、至るところでリソース同士の依存問題が生じる。分割するには既存のリソースの分析と再構成が必要。

事実、当チームでも過去、一度はSFDX化を目指したものの、最終的に断念した経緯がありました。

そのため今回は、いかにミニマムに効率化を実現していくかを念頭に、様々な工夫をしています。

SFDX移行における工夫

SFDXの基本的な構成や導入方法についてはSalesforceヘルプやTrailheadにお任せするとして、ここでは弊社で行っている実際の運用・構成についてご紹介したいと思います。

バージョン管理対象

最初にSalesforceから取得可能なすべてのリソースを取得した上で、バージョン管理対象外とするものを.gitignoreおよび、.forceignore（SFDXの処理対象外とする設定ファイル）に記載しています。

• 対象外としたもの
  • 過去にプロジェクト内でリリース実績がない種別のリソース
    • リリースの必要性に応じて段階的に検証し、徐々に管理対象を増やしていく方針
  • デプロイ無しで随時追加・更新できるもの（例：リストビュー・レポート）
  • シークレットキー、アクセストークンなどの機密情報が記載されているもの

利用したツール

• Salesforce Package.xml Generator Extension for VS Code
  • Salesforce上のリソース取得に利用。
• sfpowerkit
  • SFDXプラグイン。プロファイルのメタデータは標準機能では取得が難しいため、当プラグインにて取得・加工しています。

スクラッチ組織の代わりにsandboxを利用

今回の移行に際し、弊社ではスクラッチ組織を利用していません。
私たちの環境における、開発者ごとにsandboxが割り当てられている点を活かし、sandbox上での開発を継続しています。

差分検知

スクラッチ組織にはpull/pushという、ローカルと開発環境とのリソース差分を検知し、差分のみ同期してくれる機能が用意されていますが、sandboxへできるのは指定したファイルのデプロイのみです。
対策として、差分検知のSFDXプラグインを導入し、差分のpackage.xmlを生成してデプロイおよび削除を行っています。

• sfdx-git-delta
• 参考：デルタ生成ツールによるパッケージ化されていないリリースの最適化

CIツールの利用

当チームでは開発フローの自動化にCircleCIを利用しています。
事前にシェルスクリプトを手元で作成・実行し、何度かリリース実績ができたあとでCircleCIに転記する形を取りました。

なお、弊社のSalesforceはIPアドレスによるログイン制限を行っているため、CircleCIのIPアドレスを1つに固定できるよう、AWS上に立てたproxyを通してSalesforceにアクセスしています²。

• 参考：Salesforce アプリケーションの継続的インテグレーション
• 参考：セーフリスト/ホワイトリストに指定できる 静的IP アドレスの範囲はありますか？

実際に導入してみてどうだったか

メリット

冒頭で述べた課題は、すべて今回のSFDXによる自動化で解決しました。
参考までに、レビュー承認され、マージされたプルリクエストの数（≒リリースした社内案件数）を以下のグラフに示します。
リリース付帯作業が大幅に軽減されたので、製造作業への工数還元がされたと言えます。

また、バージョン管理のみならず、デプロイ結果やステータスなども、開発者が意識することなく、フローの中で確実に記録することができています。

デメリット

デメリットと言うよりは今後の課題ではありますが、CIツールやAWSを導入したり、SFDXツールもNode.jsであったりと、SFDXを進めていくと、Salesforce以外の知識もある程度必要になってきます。
Salesforceの開発・運用をメインで行うチームではありますが、さらに業務の効率化を求めるにあたって、ますます様々な技術に対しての知見を広げていくことが求められていくでしょう。

おわりに

弊社のSFDXへの取り組みについて、ご紹介いたしました。
SFDXはSalesforceに閉じていた従来の開発手法に比べると戸惑うことも多いかとは思いますが、SFDXのCLIだけでも慣れれば非常に強力なツールとなります。
今後はさらに単体テストの効率化や静的コード解析の自動化なども組み込み、既存のリソースの分析と再構成を進めて、システムをあるべき姿に近づけていきたいと考えています。

Visionalでは、プロダクトを支えるSalesforceの開発・運用を共に担ってくれる仲間を募集中です。
Salesforceだけでなく、様々な分野にチャレンジする機会も自分で切り拓いていけますし、それだけの環境が揃っています。

少しでも興味を持っていただけたら、是非あなたのお話を聞かせてください！

注釈

• Visional
• salesforce
• SFDX