はじめに
はじめまして。Sansan CIO室で社内システムエンジニアをしている李です。
今年4月にSalesforce DXの導入を担当しまして、今回はこのSalesforce DXについて話してみたいと思っています。
Salesforce DX(以下、SFDX)って何？という方もいらっしゃるのかと思います。 SFDXとは、Salesforceの開発において開発環境構築からデプロイまでの開発ライフサイクル全般に関わる新しい管理方法のことです。
導入してから開発・デプロイにおける"pain point"がかなり解消されまして、ぜひこのポストを期にみなさんも導入していただければと思います。
さて、SansanのSFDX導入事例について２つのパートに分けてお話させて頂きます：
パート#1
- 既存Salesforce開発におけるpain pointsとSFDX導入で得た効果
- SFDX導入・運用における各段階の説明と考慮事項
パート#2
- SFDXの導入手順
- SFDX導入＆運用時のTipと注意事項
既存Salesforce開発におけるPain Point
Stack OverflowのDeveloper Surveyによりますと、Salesforceは最近数年間"Most Dreaded" (最も恐ろしい、最もうんざりな)プラットフォームとして認識されているようです（2015年に1位、2018年に3位など）
私も"これ、なんとかできないのか？"とイライラしたモーメントが何度かありました。そしてまさにその不満がSFDXを導入するきっかけになりました。Sansanでは具体的に以下のようなpain pointを感じていました：
1. 環境の間でメタデータが一致しない場合がある
従来の方式はメタデータが環境に従属されていました。例えば、環境AとBがあるとしたら、Aで開発した内容は変更セットでBにデプロイするまでは完全に分離されていました。しかも変更セットに関わる作業は全部手動で行っていた為、どうしても登録漏れなどのヒューマンエラーが発生していました。
Sansanでは dev - staging - prod 体制でSalesforce環境を構築していたのですが、以下のような問題がありました：
- 一部メタデータが変更セットから漏れてしまい、リリース段階では誰も気付けず、何ヶ月か後に発見された
- やむを得ない理由で
staging環境で直接メタデータを修正し、prod環境にはリリースしたが、dev環境に反映することを忘れた - 上記の理由で環境の間でメタデータの差分が発生していることに気付けず、古いメタデータを上書きしてしまった
ちゃんと変更履歴の管理をしたくても変更セットだけだと、メタデータがいつ、誰によって、どういった原因で変更されたかまではトラッキングが難しく、中々管理ができていない状態でした。
2. ソース管理ができない
なんで変更セットで履歴管理が難しいかについて以下の理由が挙げられます：
- 変更セットの中身を確認するUIがいまいちで確認作業に時間がかかる
- 変更セットでどのメタデータが更新されたかは分かっても、詳細にどの部分が変わったかは確認できない
- 変更セットをアップロードした人と時刻は分かっても、誰がいつメタデータを修正したかは確認できない
- 変更セット一覧画面では変更セット名くらいしかリリースした内容の意図が把握できない
SFDX導入前もローカル環境に落としたソースを制限的にGit運用を試してみたことがありますが、あくまでソースバックアップ用途で、日々の細かな変更内訳に対して記録を残すことはできていませんでした。
3. コードレビューができず、コードの品質が担保されない
ソース管理ツールがちゃんと導入されてなかったから当然のことですが、これといったチームコラボレーション体制が整っておらず、コードレビューもできず、以下の問題で困っていました：
- 担当者によってコード品質やテストの精度がバラバラだった
- 実装したカスタム機能の仕様やロジックについて情報共有が効率良くできず、属人化しがちだった
- 関係者が集まって行うコードレビュー会はあったものの、時間が限られて細かくコードを分析することができなかった
- すでに現場にいない担当者が過去に実装した機能に関しては引き継ぎ資料に頼るしかなく、資料のスコープ外の問題に対してはゼロから調査しなければならなかった
4. 独立された開発・テスト環境が用意できない
複数メンバーが同時並行で開発を進めると、時々お互いの作業領域を侵害してしまうケースがあります。Sansanでは開発メンバー全員がdev環境で開発を行っていたので、お互いの作業内容により注意が必要でした。
もちろん新しいサンドボックス環境を用意して別環境で開発・デプロイすることも可能でしたが、そこまで手間をかけてやるべきかどうか線を引くのが微妙なケースも多く、その度に独立したテスト環境を簡単に作れないのかともやもやした記憶があります。
SFDXの導入効果
いかがでしょうか。Salesforce開発に携わっている方々は大なり小なり同じ苦痛を感じていたかと思います。SansanではSFDXを導入することで上記の問題が解決・緩和できました。
組織間で一貫したメタデータを持つことが可能
上の図でChange Set-Based Development が従来の変更セットを利用したデプロイ方法です。その矢印が変更セットだと考えてください。ご覧の通り、環境と環境が変更セットで繋がっていて、メタデータを直接受け渡ししています。
一方、SFDXが採用している Packaged-Based Development方式は 環境と環境ではなく、Version Control System が各ステージの組織とやり取りをしていることが分かります。SFDXはMetadata APIを利用してメタデータをファイル化し、バージョン管理システムでそのファイルを管理します。各環境は他の環境ではなく、バージョン管理システムのレポジトリーとやり取りをします。結果、「正」になるデータは特定環境ではなく、レポジトリーで管理するようになります。
hogehogeというカスタム項目を作成し、デプロイするという簡単なリリースシナリオを考えてみましょう。
変更セット方式なら
dev環境にログインし、hogehoge項目を作成dev→staging環境へ送信する変更セットを作成hogehogeを変更セットに登録- 変更セットを送信
stagingにログインし、今度はprod環境に対して2~4を繰り返す
という流れになります。
一方、SFDXでは
- スクラッチ組織を作成
- スクラッチ組織にログインし、
hogehogeを作成 hogehogeをレポジトリーにpull- ファイル化された
hogehoge.field-meta.xmlに対してSalesforce CLI コマンドsource:deploy -u stagingを実行 - 特に問題なければ
source:deploy -u prodを実行
という流れになります。開発環境で作ったhogehogeは必ずファイル化され、レポジトリーを’経由’して他の環境にデプロイされます。各環境は他の環境との差分について気にする必要がなく、レポジトリーのデータとの同期が取れれば良いという確信が得られます。
バージョン管理システムの恩恵が全部受けられる
SFDXはバージョン管理システム（以下、VCS）を組み込むことを前提としていますし、特定VCSを強制するわけでもないのでGithubなど、ポピュラーなVCSが利用可能です。VCSを利用する理由としては以下が挙げられます：
- 以前の状態に戻る
- 変更履歴を調査する
- プロジェクトを管理する
- 変更者と変更理由を知る
まさにpain pointとして強く感じていた”誰(WHO) が、いつ(WHEN)、どこ/なにを(WHAT/WHERE) 、どういった理由(WHY)で、どう(HOW)変更したか"を確認できるようになります。更に誤った修正をした時でも以前の状態に簡単に戻せるので切り戻しに対する負担が軽減されました。
そして、バージョン管理システムを導入したので、自然にPull Requestを利用して体系化されたコードレビューができるようになりました。その影響で全体的にコードの品質が上昇し、ロジックミスなども事前にできるようになりました。
独立したテスト環境が簡単に用意できる
スクラッチ組織はDockerのコンテナーのような感じで短時間でサンドボックス環境を立ち上げることができます。作業が終わった後にもコマンド1個で関単に破棄できるので独立した開発・テスト環境を素早く用意することができます。
SFDX導入・運用の各段階の説明と考慮事項
ここまでずっと"WHY SFDX"の話をしていましたが、ここからは"HOW SFDX"について話していきたいと思います。実際にSFDX導入をしながら経験したこと、そして後悔したことをまとめました。
始まる前に1点だけ。個人的に一番辛かったことはどうしても移行段階でtrial & errorが起きてしまうということです。特に既存環境の"成熟度(maturity)"が高ければ高いほどすんなりいかないと思います。最初から広範囲な計画を立てて移行作業に入るよりは、以下のサイクルを繰り返しながら得たフィードバックを素早く反映して漸進的に進むことをお勧めします。
1. 分析（Analysis）
導入前に現状を分析し、実現可能性の検討や全体的な導入計画を立案する段階です。まずは今のSalesforce環境がSFDXに”向いているか”を判断するのが良いかと思います。SFDX移行が確定されましたら、最低以下のポイントは押さえておくようにしましょう。
環境について
現在Salesforce環境構造は？ スキーマの複雑度は？
開発からデプロイまでの流れは定期的なサイクルで行っているか？上部の承認を要するシステムなのか？
外部パッケージとの凝集度は？ 特に、標準オブジェクトに項目を追加する外部パッケージはあるのか？パスワードロックでサンドボックスに自由にインストールできない外部パッケージがあるのか？
メタデータが「Happy Soup」（色んな参照関係が混ざっている状態）になっているか？ sObject, コンポーネントなどの凝集度は？モジュール化に必要な工数はどのくらい？
開発チームについて
- 開発チームの規模は？Salesforce環境に変更を加える部門は開発チームのみなのか、他の部署もあるのか？ その他に環境を利用する部署と作業領域が被ることはあり得るか？
- 各メンバーはバージョン管理システムになれているか？
- SFDX導入を開始した場合、投入可能な人員及び予定期限は現実的か？
- Collaboration workflow ポリシーの選定
- コードレビューガイドラインの設定
その他
- Metadata APIが支援していない機能一覧で利用しているメタデータは存在するのか？ バージョン管理できなかった場合のworkaroundは存在するのか？
2. 設計（Design）
前段階の分析結果に基づいて導入に必要な具体的アクションを決めます。
module方式 vs monolith方式
設計において一番大きく影響する要素は非管理パッケージと呼ばれるコンポーネントコンテナを利用し、メタデータをモジュール化するかしないかの選択です。 機能レベルでメタデータを区分けして、非管理パッケージに集約する方式をモジュラー（modular）方式、既存環境のメタデータをひとまとめするモノリシック（monolithic）な方式と呼ばせていただきます。
各方式は以下のような利点・欠点があります：
| modular | monolithic | |
|---|---|---|
| Good | |
|
| Bad | |
|
コストを考えなければ理想的な選択肢はmodular方式ですが、成熟度・凝集度が高い程、モジュール化にかかる時間は爆増してしまいます。 （海外であったSFDXカンファレンスの登壇者は1年8カ月を掛けてもまだモジュール化が完璧に終わっていなかったという恐ろしい話もありました）
Sansanでは基本monolithic方式を採用しつつ、今後大規模プロジェクトがあればそのプロジェクトの中身のみ非管理パッケージで管理する方針です。
どちらかを選択しましたら、以下のポイントに注意しながら設計を進めましょう：
- 本番環境までSalesforce CLIを利用してデプロイすべきか？
- 開発チーム以外に本番環境のメタデータに修正を加えるユーザーはないか？
- 開発チームメンバー全員が本番環境へアクセスできるか？
- バージョン管理できないメタデータが存在するか？
- CI/CD運用を視野に入れているか？
3. 移行（Transition）
実際にメタデータのファイル化からスクラッチ組織にデプロイする段階です。
具体的に、以下の流れで移行を進めましょう：
- メタデータをファイル化
- バージョン管理システム設定
- （モジュラー方式のみ）既存ソースのリファクタリング
- スクラッチ組織を作成
- メタデータをスクラッチ組織へデプロイ
- 導入、運用に関するドキュメンテーションの整理
移行時に以下ポイントを押さえて始めると、多くのエラーは回避できると思います：
- 既存環境のメタデータを定義する
package.xmlファイルから標準機能や外部パッケージの内容は除外する - 特定言語（日本語、英語、etc)に依存するメタデータが存在すれば、スクラッチ組織生成オプションで組織言語を指定する
- コミュニティ機能を利用中で今後もスクラッチ組織で該当機能の開発・テストを行う場合は、スクラッチ組織作成後にUI操作、もしくはSeleniumなどで有効化する
- 商談分割機能もコミュニティ機能と同様、UI操作もしくはSeleniumなどで有効化する
移行作業を進めていくと、恐らく「5. メタデータをスクラッチ組織へデプロイ」のステップでTrial & Errorを何回も繰り返すようになると思います。慌てずエラーメッセージから1個1個エラーを倒して行きましょう。
4. 運用（Operation） & 改善（Improvement）
スクラッチ組織の作成及びメタデータの移行が成功したら、SFDX運用が開始できます。 しかし、いきなりSFDXの運用を始めてしまうと開発プロセスにおいて混乱を招くだけですので、事前にチームメンバーにSFDXの使い方や仕様について共有しておきましょう：
- 各種定義ファイルの構造及び編集方法
- よく使うSalesforce CLIコマンドと使用例
- トラブルシューティング
- バージョン管理システムの運用ポリシーや運用手順
SFDX運用を始めてから見える改善点も出てくると思います。例えば手動で行っていたスクラッチ組織作成作業のスクリプトを組んだり、CIツールを導入したり、プラグインを利用したり、より効率良い開発プロセスを作れることもSFDXの魅力も一つではないでしょうか。
自らの改善ではなくてもSalesforceのメジャーバージョンアップで新しいコマンドが使えるようになったり、既存コマンドがdeprecateされることもあります。チーム全体の開発・リリースプロセスの効率化のために持続的にアンテナを張って改善していくように頑張りましょう。
終わりに
パート１が大分長くなりましたが、どうかみなさんの導入計画に参考になれたら幸いです。次回のパート#２ではもっと詳細なレベルでSansanの導入実例について説明いたします。
