Salesforceのサンドボックス＆DevOps Centerを活用した開発と対応チケットリリース
現代のシステム開発において、#DevOpsとアジャイル開発は欠かせない手法となっています。特に、Salesforceを利用する企業にとって、サンドボックス環境と#DevOps Centerを効果的に活用することは、開発プロセスの円滑化や継続的なリリースを実現するために非常に重要です。本ブログでは、SalesforceのサンドボックスおよびDevOps Centerを活用した開発、コラボレーション、そして継続的なリリースについて詳しく解説します。
DevOpsとは？
DevOps（デブオプス）は、「開発（Development）」と「運用（Operations）」を組み合わせた造語で、開発担当と運用担当が緊密に連携して柔軟かつスピーディーにシステム開発を行う手法です。DevOpsは、以下の7つのステップで構成されるライフサイクルを持っています。
プラン：プロジェクト全体のタスク管理や開発の要件を定義する。
コード：開発要件に沿ってコードを作成する。
ビルド：ソースコードから動作するアプリケーションを作成する。
テスト：アプリケーションにバグがないかをテストする。
デプロイ：アプリケーションを本番環境に配備する。
運用：サービスを継続的に提供するための保守管理を行う。
モニター：運用から得られた情報やユーザーの評価を確認する。
Salesforceのサンドボックスとは？
サンドボックスは、本番環境とは隔離された環境であり、開発やテストに使用されます。Salesforceでは、いくつかの種類のサンドボックスが提供されており、それぞれの目的に応じて使い分けます。
Developer Sandbox：設定（メタデータ）のコピーを含む小規模な環境での開発とテストに適しています。
Developer Pro Sandbox：より大きなデータセットをホストでき、インテグレーションテストやユーザートレーニングに使用されます。
Partial Copy Sandbox：本番環境のデータの一部を含むテスト環境で、ユーザー受け入れテストやインテグレーションテストに適しています。
Full Sandbox：本番環境の完全なコピーを含む環境で、パフォーマンステストや負荷テストに使用されます。
DevOps Centerとは？
SalesforceのDevOps Centerは、変更管理とリリース管理を改善するためのツールであり、開発チームにDevOpsのベストプラクティスを提供します。DevOps Centerを活用することで、次のようなメリットが得られます。
バージョン管理システムとの統合：変更の追跡と管理が容易になります。
ワークフローの自動化：手動作業の削減と効率化が図れます。
CIツールとMetadata APIの活用：継続的インテグレーションとデリバリーの実現が可能です。
変更セットのメリットとデメリットの振り返り
a. メリット
簡単に使用できる：変更セットは、特に小規模なプロジェクトや変更に適しており、手軽に利用できます。
追加ツールが不要：Salesforceのインターフェースに組み込まれているため、追加のツールやソフトウェアを導入する必要がありません。
b. デメリット
大規模な変更や同期には不向き：大規模な変更や複数の環境での同期には適しておらず、効率が低下する可能性があります。
手動操作が多い：多くの手動操作が必要となるため、ミスが発生しやすいです。
バージョン管理の不足：バージョン管理システムとの統合が不十分であり、変更の追跡が難しくなります。
DevOps Centerのパイプライン（例）
開発環境の構成と理想的な設定
a. 開発環境（Dev01, Dev02）
開発者向けの開発環境です。理想的には、各開発者に対して一つずつ専用の環境を提供することが望ましいです。これにより、各開発者が独立して作業できるため、効率的な開発が可能となります。
b. 内部モジュール結合環境（IT）
この環境は、開発されたモジュールの内部結合を行うためのものです。開発者が個別に作成したモジュールを統合し、システム全体の動作確認を行います。
c. リハーサル環境（Rehearsal）
リハーサル環境は、本番環境に近い設定でお客様のレビューを行うための環境です。本番リリース前の最終確認として使用され、内部結合環境を経た後に配置されます。
案件によっては、これらの環境構成がさらに複雑になる場合があります。特に大規模なプロジェクトや特定の要件を持つプロジェクトでは、追加のステージング環境やテスト環境が必要となることもあります。
これにより、各開発環境からリリースプロセスを経て本番環境に至るまでの流れを視覚的に理解することができます。
DevOps Centerの活用例
1. メタデータ（Apexクラス）を新規作成しリリース
Dev01環境でHelloWorldクラスを作成し、IT環境、リハーサル環境、本番環境へリリースします。
2. メタデータ（Apexクラス）を変更しリリース
Dev01環境でHelloWorldクラスを変更し、IT環境、リハーサル環境、本番環境へリリースします。
3. 各開発環境の差分を同期
Dev01とDev02環境の差分を確認し、同期を行います。この機能は、本当に開発者同士、お客様側、委託先のエンジニアと一緒に作業する際に便利です。これを活用すると、基本的にサンドボックスのリフレッシュ（更新）は不要となります。
差分はGUI上で確認できるため、新しいフィーチャー（ワークアイテム）を開発する前に、差分を自分の開発環境へ反映させることで、メタデータの衝突頻度を減らすことができます。
4. メタデータを削除しリリース
Dev01環境でHelloWorldクラスを削除し、IT環境、リハーサル環境、本番環境へリリースします。
DevOpsCenterのペインポイント
カスタム項目の追加による依存関係の問題
たまに、訳がわからなくて新しいワークアイテムを作成する際に、カスタム項目だけをワークアイテムに追加しても、依存関係のあるオブジェクト、リストビュー、入力規則が含まれてしまうことがあります。このような場合、Gitで差分を確認することができますが、本当にコードをレビューする際に怖がってしまうこともあります。
対策
マージ元ブランチ（ワークアイテムブランチ）に `.forceignore` ファイルを作成し、除外するファイルやフォルダを加えることで、不要な依存関係を除外することが可能です。
.forceignoreの追記方についてセールスフォースのオフィシャルサイトをご覧ください。
複数開発環境でのメタデータ衝突
複数の開発環境を利用したり、同じメタデータを改修する場合、次のステージへリリースするときに衝突が生じることがあります。
対策
これは避けられない問題ですが、Gitの知識を身につけることで、衝突を解決することができます。
最後に
SalesforceのサンドボックスとDevOps Centerを活用することで、開発とコラボレーションの効率が大幅に向上します。これらのツールを適切に使用し、継続的なリリースを円滑に進めるためのベストプラクティスを導入することが重要です。DevOpsの考え方を取り入れることで、開発チームと運用チームの連携が強化され、ビジネスの成長に貢献できるでしょう。
DevOpsCenterのセットアップについて下記の記事をご参考ください。
https://tyoshikawa1106.hatenablog.com/entry/2023/07/25/073953