Salesforce Architect Group Meetup #24

Development Lifecycle and Deployment 運用・テスト・リリースのプラクティス

Transcript

1. The future is yours to build. Development Lifecycle and Deployment 運用・テスト・リリースのプラクティス 2026年5月12日 コパード株式会社　シニアセールスエンジニア　大川 博 Salesforce Architects Meetup Tokyo#24
2. Agenda 1 2 3 4 はじめに Salesforceプロジェクトのあるある その本質的な課題と対応策いくつか まとめとQ&A This presentation covers the following:
3. Copado, Inc. 職歴 新卒〜2011年1月まで、UNIX, Java, C#など各種プラットフォー ムでのシステム開発に従事 2011年2月からSalesforceにてBTC領域を中心にプリセール スSEとして活動、2018年8月からはアライアンス部門に移動し てパートナー企業を主に技術面で支援 2025年9月からコパード株式会社にて SE Copado認定資格 Fundamentals I SFP、Fundamentals II SFP、 Copado Robotic Testing、Copado AI Salesforce認定資格 Triple Start Ranger、Agentblazer Legend(2026)、 認定アプリケーションアーキテクト、 認定システムアーキテクト Trailblazer.me https://www.salesforce.com/trailblazer/hohkawa 大川 博 シニアセールスエンジニア コパード株式会社
4. Copado, Inc. 開発・運用の課題を仕組みで解決する “Copado” 開発〜保守運用の全てのプロセスを一気通貫で支援できる Inteligent DevOps プラットフォーム -4- コパードの開発支援プラットフォームが ビジネス変革を加速 市場投入までの時間を短縮 コパードCI/CD コパード ロボティック テスティング コパードAI Org IntelligenceTM • バージョン管理、品質確認、リリース、構成管 理、その他開発・運用における 定型作業の自動化プラットフォーム • 要件とメタデータを関連付けて管理 • 一箇所に集約された分かりやすいUI • クラウド/オンプレミス対応の自動テストプラッ トフォーム • ローコードのテストスクリプト、ライブ操作で作 成可能、セルフヒーリング提案 • テスト結果の自動記録 • メタデータアクセスし、Salesforceの 開発運用ナレッジを持つAIエージェント • 環境に合わせた要件、フロー・ Apex、テスト等 の成果物を自動生成 • CICD/CRT連携しアドミン/開発者を支援
5. Copado, Inc. 今日お話すること Salesforceを利用したシステムのライフサイクル Phase 3 軽微な仕様変更 軽微な仕様変更 軽微な仕様変更 障害対応 障害対応 軽微な仕様変更 軽微な仕様変更 Phase 2 障害対応 運用・テスト・リリースの中で注意する必要があるのは何か？ 障害対応 軽微な仕様変更 軽微な仕様変更
6. Copado, Inc. 運用について考えるのはいつからですか？
7. Copado, Inc. 要件はどこで管理されていますか？
8. Copado, Inc. Sandboxをいくつ使っていますか？
9. Copado, Inc. 組織の設定の SSoTはどこですか？
10. Copado, Inc. Salesforceプロジェクトあるある • アドミン同士、アドミンと開発者、開発者同士でコンフリクト • アドミンが本番環境で修正してしまって他の作業者に悪い影響が起きる • リリース時に必要な資材が入ってなくてリリース失敗 • プロファイルを上書きして利用者の権限が壊れる • 変更セットに含める資材を Excelで一覧化し、チェックしている • リリースの急なロールバックができない • リリースから資材を外したいときに作業が一からはじまる • テスト済み資材とリリース済み資材の紐づけがなくコンフリクトとデグレの繰り返しになる • データのデプロイだけ手順が別で失敗に気づくのが本番環境 • Salesforceのリリースと対抗システムのリリースをちゃんと管理するのは紙の手順書のみ • テストできていない資材をリリースして運用中にバグを見つける • 似たような仕様変更なのに別々の変更を行い不具合数が増える • 仕様のバグが後半のテストや本番で見つかる • 開発者のスキルレベルで品質にばらつき • DevOpsを人手で頑張っていてミスが減らない • 似たような失敗を繰り返す、減らせない • アドミンが異動すると誰も何もわからない • …
11. Copado, Inc. 環境(Org)の混乱 ➔ 本番環境を直接修正 ➔ チーム間での修正の競合 ➔ UAT環境で不具合修正 ➔ 他の環境の修正内容が開 発環境に戻らず先祖返り Salesforceプロジェクトあるある リリース手順の複雑さ ➔ 依存関係 ➔ 修正対象の抜け漏れ ➔ プロファイルの上書き ➔ データのデプロイ ➔ リリース対象をExcelシート で管理 ➔ 急なリリース対象変更 ➔ ロールバック 品質の作り込み ➔ 仕様の不具合の検出 ➔ テスト完了の認識の仕方 ➔ テスト済みメタデータ ➔ フェーズ別テストデータ ➔ テスト設計者のスキル ➔ メジャーバージョンアップ対 応の回帰テスト ガバナンス・自動化 ➔ 自動化の仕組みがなく手作 業で頑張っている ➔ 仕組みは作ったが、変化に ついていけない・手作業が 残る ➔ 属人化 ➔ オンボーディングの仕組み がない
12. Copado, Inc. Salesforce固有の難しさ 本質的な問題 • SalesforceのOrgは、実行環境でありバージョン管理機能のないリポジトリ である • 設定画面で簡単に設定変更 できてしまい、意図しない競合を起こしやすい • Salesforceのバージョンアップで画面・メタデータが変更される ことがある • 本番環境とSandboxに乖離が起きやすい メタデータとデプロイ手法 • メタデータだけ見ていても元の要件がわからない • プロファイル等注意が必要なメタデータ がある（競合しやすい、環境依存しやすい） • 変更セットのUIが使いにくく、実際の更新内容とデプロイ内容に不一致が起きやすい • 実行環境へのデプロイは、専用の方法（変更セット、Metadata API、Salesforce CLI等）が 必要 テスト • 単体テストがデプロイ作業中に実行 される • E2Eテストの合格を強制できない
13. Copado, Inc. Salesforce固有の難しさ 本質的な問題 • SalesforceのOrgは、実行環境でありバージョン管理機能のないリポジトリ である • 設定画面で簡単に設定変更 できてしまい、意図しない競合を起こしやすい • Salesforceのバージョンアップで画面・メタデータが変更される ことがある • 本番環境とSandboxに乖離が起きやすい メタデータとデプロイ手法 • メタデータだけ見ていても元の要件がわからない • プロファイル等注意が必要なメタデータ がある（競合しやすい、環境依存しやすい） • 変更セットのUIが使いにくく、実際の更新内容とデプロイ内容に不一致が起きやすい • 実行環境へのデプロイは、専用の方法（変更セット、Metadata API、Salesforce CLI等）が 必要 テスト • Apexとフローの単体テスト合格がデプロイの要件で、 単体テストとデプロイが混在 • E2Eテストの合格を強制できない これらを解消しないと Agentforce時代のSalesforce運用はしんどい
14. Copado, Inc. リポジトリ アーティファクト よくある開発・リリースを支えるツール全体像 CI/CDツール テスト自動化 ビルド環境 リポジトリ ソース、構成ファイル、 データ等 IDE AIエージェント 実行環境 ALMツール バージョン管理 開発環境 統合環境 UAT環境 ステージング環境 本番環境 開発環境 環境/構成管理 コード レビュー 開発環境
15. Copado, Inc. リポジトリ アーティファクト よくある開発・リリースを支えるツール全体像 CI/CDツール テスト自動化 ビルド環境 リポジトリ ソース、構成ファイル、 データ等 IDE AIエージェント 実行環境 ALMツール バージョン管理 開発環境 統合環境 UAT環境 ステージング環境 本番環境 開発環境 環境/構成管理 コード レビュー 開発環境 ソースコード →ビルド成果物 →デプロイ の順でワークフローが流れる 下流と上流で管理単位が揃うので、下流で整えたら上流も整う
16. Copado, Inc. どうやって対応するか ガバナンス・自動化 ALMによる要件管理 リリース手順の複雑さ リリースの自動化 CD 環境(Org)の混乱 目的別Sandbox バージョン管理 Sandbox同期 競合解決設計 品質の作り込み テスト自動化 CI 品質ゲート コラボレーション基盤 ナレッジ AIエージェント トレーサビリティ 回帰テスト メジャーリリース対応 AIエージェント
17. Copado, Inc. どうやって対応するか ガバナンス・自動化 ALMによる要件管理 リリース手順の複雑さ リリースの自動化 CD 環境(Org)の混乱 目的別Sandbox バージョン管理 Sandbox同期 競合解決設計 品質の作り込み テストの自動化 CI 品質ゲート コラボレーション基盤 ナレッジ AIエージェント トレーサビリティ 回帰テスト メジャーリリース対応 AIエージェント
18. Copado, Inc. Salesforceの場合の開発・リリースを支えるツール全体像 DevOpsセンター（リリースワークフロー、変更検知、認証管理、Git連携）、サードパーティ テスト自動化 リポジトリ ソース、構成ファイル、 データ等 VSCode拡張 Agentforce Vibes AIエージェント Salesforce DevOpsセンター（ワークアイテム管理）、サードパーティ バージョン管理 開発環境 統合環境 UAT環境 ステージング環境 本番環境 コード レビュー リポジト リ リポジト リ リポジト リ リポジト リ リポジト リ 開発環境 リポジト リ 開発環境 リポジト リ Metadata API / Salesforce CLI / Tooling API 変更セット データローダー等
19. Copado, Inc. ALMツールによる要件管理 • ユーザー要件 ‐ 設定内容＆メタデータ - テスト - リリース履歴 を一気通貫で管理できるのが理想 • 一気通貫は難しくても、できるだけ構造化して管理をし、相互にリンクできるようにする • ユーザー要件 ◦ Jira など ALM ツールでチケット（ワークアイテム、ユーザーストーリー）で管理 • 設定内容＆メタデータ ◦ 設計ドキュメントにまとめる。設定・デプロイ手順も記載（人間のため） ◦ 現代であればマークダウン化するのが再利用しやすい（AIエージェントのため） ◦ この時点で機能を論理的に分割しておき、要件・機能レベルでの競合を防ぐ ◦ メタデータとしてデプロイするものはGitにコミット（AIエージェント、後続のリリースツールのため） • テスト ◦ テスト仕様書およびテスト結果報告書にまとめる（人間のため） • リリース履歴 ◦ リリース手順書としてまとめる必要はあるが、元ネタはチケットにリンクされた設計書内の記述 ◦ リリース実行時に自動的に、どの環境にリリースされたのかも追記できるようにしておく リリース管理の入口はユーザー要件
20. Copado, Inc. リリースの自動化 実行環境の整備 • どのツールを使うか ◦ DevOpsセンター、GitHub Action + SFDXで作り込み、CopadoやFlosumのようなサードパーティ製品 ◦ 考慮点を考えると、サードパーティ製品がおすすめ • 実行場所に合わせた整備 ◦ 製品のUI、ローカルのコマンドライン、PRでトリガー、AIエージェントからの指示… • 実行履歴をどこに残すか。 ALMとの連携をどうするか 修正対象の取り出し • いつ実施するか • Gitから取り出すか、Salesforce Orgから取り出すか • 依存関係の確認はどうするか • マニフェストファイル (package.xml)や環境固有のメタデータはどう作成・処理するか • データはどうするか。インポートおよびマスク処理 どこまで自動化できるかが肝
21. Copado, Inc. リリースの自動化 - ツール比較（個人の意見です） 概要 費用 機能性 柔軟性 変更セット • 組織 to 組織 • 組織の中のメタデータを目で探す 無料 最低 なし 次世代DevOpsセンター （ベータ） • パイプラインを管理し組織間のデプロイ • 組織のメタデータの変更点を見て抽出 • ワークアイテムでデプロイ資源を管理 • Git連携 • Salesforceの変更への対応は自動的に行われる 無料 低 発展途上 なし Git＋CI/CDツール ＋Salesforce CLI • 設計・ツールの実装をすべて実施する必要あり • 自由な要件を取り込むことが可能 • デプロイ用に管理ユーザーを用いるのでセキュリティ考慮 必須 • Salesforceの変更への対応も実施が必要 Git＋CI/CD ツール 自前で 構築必要 あり サードパーティ製品 • パイプラインを管理し組織間のデプロイ • 組織のメタデータの変更点を見て抽出 • ワークアイテムでデプロイ資源を管理 • Git連携 • デプロイに向けたステップの拡張が可能なものもある • Salesforceの変更への対応は製品側で対応。ただしタイ ムラグあり 製品費用 高 あり
22. Copado, Inc. バージョン管理 • どのGitサービスを利用するか • ソースコードはシステムで 1つか、環境別か ◦ https://clickdeploy-team.medium.com/salesforce-source-control-5561ed917d0 • 環境固有の情報の書き換えはどう考えるか（ Gitリポジトリ上どう管理するか） • マスターデータや、環境別テストデータはどう管理するか • テストスクリプトはどう管理するか 何のバージョンを管理するのか
23. Copado, Inc. 目的別Sandbox/Sandbox同期 開発1 開発2 開発3 開発4 チーム 統合 統合 UAT ステー ジング パフォー マンス 本番 本番環境と同等のデータ 本番環境と同一の資材 UAT完了済み 対抗システム接続 統合テスト済み資材 テストカバレッジ 連携はモック 単体テスト済み テストカバレッジ 競合解決 連携はモック 開発者ごとに1つ リリース資材はここで確定させる 課題 • リリース作業負荷が高いとボトルネックになる • Sandbox別の目的の徹底の仕組みが必要 • Sandbox作成後の、環境固有設定、テストデータ投入、環境別有効化設定などは別途行う必要あり • 上位の環境に反映された内容を下位に戻すための仕組みや間違ってデプロイしたときのロールバックの仕組みも必 要
24. Copado, Inc. コード分析 /テスト自動化 単体テスト • いつ実行するか • 検証デプロイをどこで実施させるか 静的コード分析 (PMD) • どのツールを使うか • いつ実行するか • 結果をどう確認するか 自動化ソリューションの課題 E2Eテスト • どのツールを使うか ◦ 利用されるスクリプトの言語は ◦ 実行環境は ◦ テストスクリプトの作成方法は ◦ テスト結果の記録は ◦ テストスクリプトの保守 ◦ 並列でのテスト実行は • 回帰テストの実行方法は • テストカバレッジ • AIエージェントのテストはどうするか • 品質ゲートの置き方はどうするか （CI/CDツールとの連携）
25. Copado, Inc. 可視化 - DORAメトリクス スピードの指標 • デプロイ頻度 (Deployment Frequency): どれくらい頻繁に本番環境へコードをリリースしているか。 • 変更のリードタイム (Lead Time for Changes): コードがコミットされてから、本番環境で正常に稼働するまでの時間はどれくら いか。 安定性の指標 • 変更失敗率 (Change Failure Rate): デプロイの結果、障害が発生して修正やロールバックが必要になった割合はど のくらいか。 • サービス復旧時間 (Time to Restore Service): 本番環境で障害が発生した際、稼働を再開させるまでにどれくらいの時間がか かるか。 うまくやれていることを測る
26. Copado, Inc. 運用について考えるのはいつからですか？ 要件定義から 要件とそれに紐づく関連情報が運用時には必須です
27. Copado, Inc. 要件はどこで管理されていますか？ ALMツール AIエージェント Readyであることが必須です
28. Copado, Inc. Sandboxをいくつ使っていますか？ 目的にあわせた数 リリース負担低減およびガバナンスのために準備
29. Copado, Inc. 組織の設定の SSoTはどこですか？ バージョン管理システム ブランチ戦略はリリースツールといっしょに検討を
30. The future is yours to build. Thank You