Salesforce CLIとGitHub Actionsを活用したCI/CDパイプラインの高速化
はじめに
こんにちは！ユビレジのコーポレートエンジニアとして活動している川名です。
私は主にSalesforce（UfSや社内Salesforce）の要件定義〜開発・運用保守・その他社内で利用しているSaaSの運用を行っています。
Salesforce開発をメインにしている事もあり、今回はSalesforce開発における検証やデプロイを高速化した話に少し触れたいと思います。
この記事を読んでいただく事で、GitHub ActionsとSalesforce環境におけるCI/CD構築の一助になれればと思っております。
Salesforce CLI について
Salesforceデベロッパー以外の方向けに簡単に引用しておきますが、Salesforce開発には欠かせないツールになっています。
Salesforce CLI は、Salesforce 組織を使用しているときの開発およびビルド自動化を簡略化するコマンドラインインターフェースで、組織の作成や管理、ソースと組織間の双方向の同期、パッケージの作成やインストールなどに使用できます。
課題
早速ですが、今回の内容であるSalesforce開発におけるCI/CDパイプライン高速化の内容に入っていきたいと思います。
その前にユビレジのSalesforce開発における基本的な流れをご紹介しておきます。
ユビレジのSalesforce開発では、GitHubフローを使ったブランチ戦略を採用しており、機能ごとにブランチを切って各自の開発用Sandboxで開発を行います。
pull requestのレビューが通ったらマージしてIntegration環境、本番環境にデプロイしていく流れで開発しています。
基本的な動きとしては機能していたのですが、幾つかの課題を抱えていました。
事前の検証やデプロイ時間が長すぎる
上の図でpushする度に数十分かかっていたので、複数のブランチを同時並行で検証するのは現実的ではなかったです。修正の規模に関わらず毎回同じ時間がかかってしまうのが辛い点でした。
(optional) destructiveなデプロイを単体でデプロイする事ができなかった
A.clsを削除したいだけなのに、何か他のコンポーネントも同時デプロイしないと動かない
(optional) 差分デプロイで利用していたプラグインのリポジトリがメンテされていなかった
最重要項目としては、デプロイ時間が長すぎる点でした。Salesforce組織上では検証やデプロイが直列で実行されるので、GitHub Workflowのジョブをキューに入れても結局Salesforce側からいつまでも結果が返ってこない状況になります。こうなると複数ブランチ・複数人で開発を行っていると検証するだけで一苦労です。
下の2つに関してはオプション的に対応したいと思っていました。
解決策
高速化といっても最初はイメージがついておらず、何か良い情報がないかと見つけたのがこちらの記事でした。
Build Your Own CI/CD Pipeline in Salesforce (Using GitHub Actions) | Salesforce Ben
こちらの記事でインスパイアされたのが、pull request単位での実行テストを指定するという点でした。よく調べもせず、検証やデプロイでは毎回全てのテストを実行しなければならないと思い込んでいたのでこの情報はとても有益でした。
この情報を基に、高速化に向けてとったアプローチは以下になります。
実行するテストクラスを指定可能に（上記記事の内容）
従来は組織の全テストを実行するためにRunLocalTestsを指定してましたが、pull request毎に実行するテストクラスを指定可能にしました。
上記記事に加え、自動的にコミット内容からテストクラスを取り出す仕組みや、テストが不要なコンポーネントのデプロイにも対応しました。
但し、一見関係のないテストが落ちる可能性も0ではないため、別の仕組みでRunLocalTestsを定期的に動かす仕組みも構築しています。
デプロイの並列化
直列で動かしていた本番とインテグレーション環境のデプロイを並列に変更しました。
検証済みのということもあり、インテグレーション環境に関してはNoTestRunでのデプロイとして時間を短縮しました。
クイックリリースを活用
本番組織上で事前検証を行い、本番デプロイにおいてはクイックリリースを行う事で時間を短縮しました。
差分デプロイにはcolladon/sfdx-git-delta: Generate the sfdx content in source format from two git commitsを利用させて頂きました
これによって破壊的なデプロイも1コマンドでスムーズに出来るようになりました。
GitHubワークフロー実行時のキャッシュ
sfコマンド等可能なものは毎回インストールせずにキャッシュして、workflow自体の実行時間短縮を行いました。
解決策（クイックリリースについて）
解決作の中でも特に有効なクイックリリースについて少し掘り下げて記載したいと思います。
クイックリリースとは、実際のデプロイ前にデプロイが問題なく実行可能かを事前に検証(dry run)しておき、即時本番環境に反映させる事が出来るSalesforceの機能です。これを使うと一瞬でデプロイが完了します！
そもそもの機能を詳しく知りたい方はこちらのリンクからクイックリリースセクションなどをご参照ください。
今回の課題解決においても利用したいと考えましたが、Salesforce CLIとCI/CDにおいての有益な活用事例は見つけられませんでした。
ここでは簡単にSalesforce CLIとGitHub Actionsを使ってどうやって取り入れたかをご紹介したいと思います。
使うコマンドは以下となります。
sf project deploy --dry-run
dryrunモードでJobIdを得するために実行します。
sf data create record
JobIdを永続化するためにカスタムオブジェクトに保存します。
この時pull request番号などのコンテキスト情報を一緒に保存しておくと後で取り出す事ができます。
sf data query
マージされた時のワークフローでpull request情報から該当のJobIdを取り出します。
Tooling APIのDeployRequestオブジェクトから該当のJobIdで検索し、10日以内の有効なIdかを検証します（それ以外に有効チェック出来る項目があるかもしれないです）
検証後に別のリリースが実行されるとJobIdは無効になるという事なのですが、今のところそこまでの対応はしていません。
sf project deploy quick --job-id <YourJobId>
最終的にクイックデプロイを実行します
上記の様に活用することで、マージされたタイミングでJobIdを利用したクイックリリースが実現出来ます。
※何故かDpeloyRequestというオブジェクトはToolingAPIの公式ドキュメントには載っていません。
以下にドキュメントを貼っておきますので、他にも気になる情報などないか探してみてください。
結果
実際どの程度の効果があったのか、テスト実行時間のトレンドとデプロイ時間の推移を出してみました。
2023年5月より今回記載の内容を本格運用し始めましたが、結果としては圧倒的なベンチマークを得る事が出来ていました。
まずはテスト実行時間のトレンドについてです。
5月頃から10min以下のテストが多くなってきている事が分かります。
7月頃でも20minなど長めのテストが存在するのですが、あえて全て実行しているケースと、ワークフローのテスト指定コマンドに問題があり、全テストを実行しなければならないケースがあったためです。
※今は修正しているため、今後はこのトレンドがより強くなっていくと思っています。
続いてデプロイにかかった時間の推移を見ていきます。
クイックリリースが出来る場合、やはり圧倒的な速度になっている事がグラフから分かります。
4月頃までは直列実行でそれぞれRunLocalTestsでの実行だったので、当たり前といえば当たり前なのですが。
まとめ
いかがでしたでしょうか。
実はこの「ユビレジ テックブログ」を書きます、と社内で伝えてから、早数ヶ月経過してしまっていました。
日々の業務でなかなか振り返りに時間を割けない中、記事を書く事で改めて改善活動や可視化（アウトプット）の大切さを感じました。
そして小さな改善の積み重ねが、ユビレジのミッションである「サービス産業のためのデータインフラを整備する」に繋がっていくと信じています！
少しでも皆様の参考になれば幸いです。
ユビレジでは一緒に働く仲間を募集しています。
ユビレジやSalesforce開発に興味のある方、またそれ以外の職種でもお気軽にお声がけください！
この記事が気に入ったらサポートをしてみませんか？