VisasQ Dev Blog

ビザスク開発ブログ

Salesforceの開発フローを改善した話

ビザスク プラットフォーム開発部 SRE/SFチームの蓮尾 です。ビザスクで利用しているSalesforceの保守運用やエンハンス開発を担当しています。

去年、Salesforceの開発フローを改善しました。どのように改善したのか、なにが改善されたのかをご紹介したいと思います。

課題

改善したい点は大きく2点ありました。

リソース管理リリース手順です。

リソース管理

Githubでリソース管理していましたが、リリースはSalesforce既存の手順である変更セットで行っていたので、Github上のリソースとリリース作業自体の紐付けは特にありませんでした。ブランチは開発する単位で切っていました。しかしApexやVisualforce等の開発リソース以外のメタデータの管理等が曖昧になりがちでGithubで管理しているソース=組織の状態とは必ずしも言えない状態でした。

更に複数エンジニアでの開発を想定していないSandbox - 変更セットでのリリースフローは、今後開発規模を拡大する上で大きな課題となっていました。

リリース手順

いわゆる変更セットを使って本番リリースを実施していました。開発組織から画面でプチプチと開発リソースを選択して変更セットを作成し、リリースするという手順で、Salesforceではオーソドックスな手順です。

小規模な機能をリリースするには変更セットでも比較的問題無いのですが、大規模な機能開発や複数エンジニアで同じリソースに対して改修をする場合、この変更セットでのリリースは苦行以外の何者でもありませんでした。

スプレッドシート等で対象リソース一覧を作成して、Githubでpushしたリソースと変更セットのリソースを比較して漏れが無いか確認したり、同じリソースに対して改修している場合は改修箇所の確認・反映してからのリリースする等、リリース自体が苦行の元になっていました。

上記の通り、開発リソースの管理や複数エンジニアでの開発を想定していない既存のSalesforce開発フローは解決すべきトイルをあちこちで発生させていました。これではスムーズな機能改善・改修は望めません。

その他、後日 正しいフローを経てリリースされているかを内部統制等から確認されることがあるのですが、画面キャプチャでしかリリースの記録を残す事ができずこちらも課題の一つでもありました。

どう改善するか

ソース駆動型であるSFDXの開発フローを部分的に摘要することでリソース管理リリース手順が抱えている課題を解消することを目指しました。

リソース管理

まず管理対象のリソースを改めて整理し package.xmlへ定義し直しました。管理対象のリソースに関しては リポジトリのmaster = 本番組織、stagingブランチ= Staging組織という構成にしました。

リリース手順

変更セットは一切使わず本番組織、SandboxへのデプロイはSFDXコマンドで実施。またSFDXコマンドを Makefile から実行するようにし手順を簡潔にしました。加えてリリースにおいてはGitのtag付けをし、リリース差分がわかるようにしました。 ( このMakefile 作成は SREチームで社内開発環境改善を担当している 望月さんが担当してくれました。社内で横断的に知見を活用できるのはビザスク開発チームの強みの一つだと思います。)

Githubへpush・レビューの後、masterへ対象ブランチをマージした後はmakeコマンドでタグ付け、デプロイできるようになりました。 結果、ブランチとリリース粒度が一致することになり、リソース・リリース管理が劇的に楽になりました。

クラッチ組織とSandbox

SFDX開発ガイドではスクラッチ組織を使った開発が紹介されています。スクラッチ組織で開発を進められれば、対象ブランチ=対象スクラッチ組織となり開発がしやすくなるメリットがありました。

しかし本番組織で運用している沢山のプロファイルを再現できない等、社内運用している組織の開発をする上で、スクラッチ組織での開発には限界がありました。(開発フロー検討当時)

色々と検討した結果、コピーすればそのまま本番組織を再現できるメリットを生かし従来通りSandboxで開発することにし、SFDXコマンドでデプロイすることにしました。

開発対象の組織をスクラッチ組織で実施できないのは、部分的にしかSFDXの恩恵にあずかれないと思い、スクラッチ組織とSandboxのどちらで開発するかの検討はかなり苦慮しました。最終的にSFDCのエンジニアの方にアドバイスをいただき、従来通りSandboxでの開発に着地しました。

改善した結果

Githubでソースを管理しブランチをベースにリリースすることが可能になったことで、リリース作業自体の工数が激減しました。またリリース自体の変更セットとGithubの二重管理が無くなったのもメリットが大きかったです。

おわりに

弊社のSalesforceCRM/SFAとしてはもとより、MAを実現するためMarketoとの連携やバックエンドのペーパーレス化等へ寄与する為の機能も備えています。Salesforce自体やSFDXの改善されるであろう機能を上手く取込み、ビジネスのスケールに更に貢献できるよう取り組んで行きたいと考えています。