DevOpsセンター プロジェクトのベスト プラクティス
次のベスト プラクティスに従って、DevOpsセンター プロジェクトを計画します。プロジェクトは、関連する作業項目の個別のコレクションを管理およびリリースするための一元化されたワークスペースです。
必要なエディション
| 使用可能なエディション: Lightning Experience in Professional Edition (API アクセスが必要)、Enterprise Edition、Performance Edition、Unlimited Edition、および Developer Edition |
| 使用不可: Government Cloud Plus。詳細は、Salesforce アカウントエグゼクティブにお問い合わせください。 |
| 使用不可能なゾーン: EU オペレーティングゾーン。EU オペレーティングゾーンは、データレジデンシーコミットメントのレベルを強化する特別な有料製品です。DevOps Center は、EU の OZ に含まれない EU 内の組織でサポートされ、標準の製品利用規約が適用されます。 |
プロジェクト数の決定
次の場合、1 つのプロジェクトと 1 つのリポジトリを使用します。
- チームは、同じまたは連動するメタデータと設定データで作業します。
- すべての変更が同じ本番組織にリリースされます。
- すべての作業の統合表示が必要です。
- 開発には、相互接続されたオブジェクトと機能が含まれます。
次の場合に個別のプロジェクトを作成します。
- チームは、連動関係のない独立したメタデータとデータで作業します。
- 変更は異なる本番組織にリリースされます。
- プロジェクトは個別のリリーススケジュールとガバナンスに従います。
- 標準リリースケイデンスをスキップするには、分離されたホットフィックスパイプラインが必要です。
- チームは業務を分離する必要があるか、別のチームの有効な作業と変更の表示を制限したいと考えています。
プロジェクトライフサイクル戦略の選択
リリース管理プロセスとケイデンスに基づいてプロジェクトライフサイクルを決定します。
進行中のプロジェクト: 複数のスプリントおよびリリースで同じプロジェクトを使用します。これは、継続的な機能開発を行い、安定したメタデータとデータ範囲を使用するチームに推奨される方法です。これらのプロジェクトは管理が容易になっています。たとえば、存続期間が長いプロジェクトは、2 週間に 1 回リリースし、スプリントに関係なく 1 つのパイプラインを使用するチームに最適です。活動履歴の DORA 評価指標と履歴を使用して、プロジェクトのパフォーマンスを追跡できます。
リリースごとのプロジェクト: メジャーリリースごとにプロジェクトを作成します。この方法は、個別の時間枠のイニシアチブやメジャーバージョンリリースを使用するチームに適しています。これには、リリースごとに追加の設定作業が必要です。リリース後にプロジェクトをアーカイブすることをお勧めします。
ホットフィックスプロジェクト: 本番で重要な問題が発生した場合は、別のホットフィックスプロジェクトを使用して迅速な対応をサポートします。
- プロジェクトを作成し、少なくとも開発環境、テストフェーズ、本番組織を含むパイプラインに接続します。
- 問題を解決したら、すべての変更を標準プロジェクトパイプライン内に移動し、すべての環境の同期を維持します。
- ブランチの分岐を防ぐために、変更内容は常に主プロジェクトに同期します。
無効なプロジェクトの管理
DevOps センターでプロジェクトは削除できません。無効なプロジェクトに z_ プレフィックスを追加します。例: z_MyOldProject。これにより、プロジェクトがリストの一番下に移動します。
.forceignore ファイルの設定
.forceignoreファイルによって、確定およびリリース時にDevOpsセンターで除外される変更が決まります。パイプラインを作成する前に、メインブランチで .forceignore ファイルを設定して、すべての機能ブランチに反映します。.forceignore ファイルを変更するには、作業項目機能ブランチ内で編集を適用します。編集内容は、作業項目を昇格するときにパイプラインに反映されます。「.forceignore ファイルを使用したメタデータの除外」を参照してください。
DevOpsセンター プロジェクト戦略の推奨事項
| シナリオ | 推奨 | 例 |
|---|---|---|
| メタデータとデータが重複する同じ本番組織。 | 1 つのプロジェクト、1 つのリポジトリ構造 | プラットフォームチームは、相互接続されたオブジェクトをカスタマイズします。チームは Sales Cloud 機能を開発し、開発者が商談オブジェクトをカスタマイズし、他のユーザーがキャンペーンに取り組みます。どちらの機能も共有カスタムオブジェクトを使用します。メタデータが重複するため、1 つのプロジェクトを使用します。 |
| 独立したメタデータとデータを持つ同じ本番組織。 | 1 つのプロジェクト構造 (推奨) | ApexチームとMarketing Cloudコネクタ チームが共有環境にリリースする並列作業を追跡します。 |
| 地理的または運用的に独立した本番組織。 | 個別のプロジェクト | データレジデンシー要件により、ヨーロッパと米国の本番組織を分離するための独立したリリース。組織に同様のアプリケーションが含まれていますが、個別にリリースされています。本番組織ごとに 1 つずつ、2 つのプロジェクトを作成します。 |
| 緊急のホットフィックスパイプラインパスが必要です。 | 個別の修正プロジェクト | 標準リリースサイクルをバイパスする分離パスが必要な重要な修正。 |
