[Salesforce] DevOps Centerを導入してみました

こんにちは、TERASSでSalesforceをやったりやらなかったりしているimslpです。
今回はDevOps Centerを使って開発からリリースまでのやり方を変えてみた話です。

はじめに

これまでTERASSでは、Partial CopyライセンスのSandboxが1つしかなく、全メンバーが同じ環境で直接開発・デプロイを行っていました。リリースも変更セットを使っていました。
開発者が私一人だった頃は問題になりませんでしたが、メンバー増加に伴いデグレや設定競合が発生するようになりました。そこで、Salesforce公式から提供されているDevOps Centerを導入し、開発からリリースまでのフローを見直してみました。

注意
この記事ではDevOps Centerの使い方については説明しません。
公式ドキュメントや別の方のブログをご確認ください。

課題

先述の通り、以前はほとんど私一人で開発していたため、あまり問題意識もありませんでした。
そして、この課題はDevOps Centerを利用せずとも解決できるものもありますが、ご容赦ください。

• Sandboxが１つしかない

  • 全員が同じSandboxで開発・デプロイしていたため、コンフリクトやデグレリスクがある
  • テストデータが不安定で、検証結果の再現性が確保しづらい

• バージョン管理できない

  • 変更履歴のトラッキングがなく、誰がいつどの変更を行ったか把握できない
  • 過去状態へのロールバックや差分比較が困難

• レビュー体制が整っていない

  • 手動の変更セットベースでのレビューに頼っており、レビュアーの負荷が高い
  • コード・設定の統一基準がなく、品質担保が難しい

• 変更セットが使いづらい

  • メタデータを手動で選択する手間が大きく、必要な項目を見落としやすい
  • 大量のコンポーネントをまとめて送信していたため、不必要な変更が本番環境に反映されるリスクを抱えていました。
  • 数千くらいのコンポーネントを含んだ変更セットを作ろうとすると、送信変更セットが作成できない事態が発生します。

なぜDevOps Centerか？

DevOps Centerを採用した主な理由は以下のとおりです

• 公式サポート
  Salesforceの機能として継続的なアップデートとサポートが保証されているであろう点
• ブラウザベースの操作
  CLIや外部ツールを導入せず、管理画面だけでリリース管理が完結できる手軽さ
• 差分自動検出
  変更セットの手動選択が不要になり、必要なメタデータの差分を自動で管理できる
• Git連携によるコード管理
  コード管理をGitHubで行うことにより、レビューのしやすさが向上します。
  また、問題発生時に以前の状態に復元することもできる。

これらにより、運用負荷の削減と品質担保の両立が実現できます。
すべてのSalesforceエンジニアがGitHubベースの開発に習熟しているわけではないため、ブラウザだけで完結できるDevOps Centerは、導入の第一歩としては適していると考えました。
今はまだ使いづらい部分もありますが、ロードマップもありますし将来的には使い勝手が更に向上してくれたら嬉しいですね。

使用事例

TERASSではこのようなパイプライン構成でDevOps Centerを利用しています。

• 開発者の個人Sandboxの作成

  • 各開発者ごとにDeveloper Sandboxを作成
  • 作成時に初期データ作成用Apexを指定し、ユーザなどの必要データを作成する

• Sandbox作成時の初期データ投入

  • 別でCLIでスクリプトを実行し、マスタデータを別環境から移行する
  • 環境間で値が異なるカスタム表示ラベルも更新
  • 移行スクリプトについては過去記事のものを流用して作成しました。初期化時だけでなく、マスタに変更があった時にもスクリプトは実行します。

• DevOps Centerを利用した開発ワークフロー

  • 開発者は自身のSandboxで機能実装後、PRを作成する

• GitHubを利用したコードレビュー

  • チームメンバーがレビューを行う
  • Flowはコードレビューが難しいため、必要に応じてSandbox上で動作確認
  • １つでもレビュー中のワークアイテムが存在すると後方同期が行えないので、なるべく早めにレビューしてプロモートする必要があります。

• 担当者によるプロモート・リリース実行

  • ステージング環境へのプロモートタイミングを管理し、リリース確定時に本番へ反映

• 開発環境の同期

  • 後方同期機能を利用して、ひとつ先の環境から変更を個人Sandboxに同期します

運用してみて

実際に2025年2月頃からゆるやかに運用してみた結果、以下の効果・気づきが得られました

• コンフリクト・上書きを気にしなくなる
  正確に言えば気にはするのですが、デプロイするときにいちいち差分をチェックしたり誰がどのクラスを変更しているか？などを頭に入れておかなくても良くなりました。競合の検出などはすべてDevOps CenterやGithubに任せます。

• 品質の向上
  レビューがきちんと行われることで、将来的な負債を防ぐことができたり、コード品質が向上した気がします。コードレビューは大切だなとしみじみと感じています。

• 導入ハードルの低さ
  Gitに不慣れなメンバーでも、ブラウザUIのみで操作できるため、メンバー全体への定着がわりとスムーズに進みました。ただ、移行期間中は各ブランチを最新に保っておく必要があったので少し大変でした。

• 微妙に感じること

  • （修正済み？）DevOps Centerを通さず、そのままコミットした場合に変更が反映されない
    こちらのIssueを見るとクローズされていますが、反映までに時間がかかるなど問題が残っているケースもあるようです。
  • ロールバックできない
    ワークアイテムをプロモートすると戻すことができないので、慎重にプロモートする必要があります
    こちらもIssueがありますが、修正はまだのようです。
  • 操作がちょっと重い
  • ブラウザ開いてコミットするのちょっとめんどくさい
    メリットではあることは間違いないですが、ある程度慣れている人からするとVSCodeから離れて重いブラウザ操作するのは微妙な面もあります。ワークアイテム自動作成->VSCodeでコミット->の流れが確立できれば開発体験が向上しそうです。

今後の展望

• GitHub Actionsや外部ツールとの連携でCI/CDを強化
  • GithubでのReleaseを感知してパイプラインのデプロイとかできたら嬉しい
  • ApexやLWCのテストも自動化したい
• Notionと連携したワークアイテム管理
  • Notionでタスクが作成された場合、ワークアイテムを自動作成する
• Sandbox作成時に自動でスクリプトを実行する
• DevOps Center CLIも提供されているみたいなので取り入れられそうであれば取り入れてみる
• プロファイルのデプロイが推奨されていないため、権限セットベースの権限管理に切り替える

おわりに

主に使い勝手の面でそこまで良い話を見なかった機能ですが、小規模チームとしてはそれなりに使えることが分かりました。
DevOps Centerは公式ソリューションとして導入のハードルが低く、変更セット運用からのスムーズな移行が行えました。この事例が同じ課題を抱えるチームの参考になれば幸いです。
ここまで見てくださりありがとうございました！