Sie befinden sich hier:
Bewährte Vorgehensweisen für DevOps Center-Projekte
Befolgen Sie diese bewährten Vorgehensweisen, um Ihr DevOps Center-Projekt zu planen. Project ist eine zentralisierte Arbeitsumgebung zum Verwalten und Bereitstellen einer unterschiedlichen Sammlung zugehöriger Arbeitselemente.
Erforderliche Editionen
| Verfügbarkeit: Lightning Experience in der Professional (API-Zugriff erforderlich), Enterprise, Performance, Unlimited und Developer Edition |
| Nicht verfügbar in: Government Cloud Plus. Wenden Sie sich für weitere Details an Ihren Salesforce-Kundenbeauftragten. |
| Nicht verfügbar in: Einsatzbereich EU "Einsatzbereich EU" ist ein spezielles zahlungspflichtiges Angebot, das eine stärkere Verpflichtung zur Datenresidenz bereitstellt. Das DevOps-Center wird gemäß den standardmäßigen Produktbedingungen in Organisationen in der EU unterstützt, die nicht Teil des Einsatzbereichs EU sind. |
Bestimmen der Anzahl der Projekte
Verwenden Sie ein einzelnes Projekt und ein einzelnes Repository in folgenden Fällen:
- Teams arbeiten mit denselben oder abhängigen Metadaten und Konfigurationsdaten.
- Alle Änderungen werden in derselben Produktionsorganisation bereitgestellt.
- Sie benötigen eine einheitliche Sichtbarkeit für alle Arbeiten.
- Die Entwicklung umfasst miteinander verbundene Objekte und Funktionen.
Erstellen Sie separate Projekte in folgenden Fällen:
- Teams arbeiten an unabhängigen Metadaten und Daten ohne Abhängigkeiten.
- Änderungen werden in verschiedenen Produktionsorganisationen bereitgestellt.
- Projekte folgen separaten Versionsplänen und der Governance.
- Sie benötigen isolierte Hotfix-Pipelines, um Standardversionsrhythmen zu umgehen.
- Teams benötigen eine betriebliche Isolation oder möchten die Sichtbarkeit der aktiven Arbeit und Änderungen eines anderen Teams einschränken.
Auswählen Ihrer Projektlebenszyklus-Strategie
Legen Sie einen Projektlebenszyklus anhand Ihrer Versionsverwaltungsprozesse und Ihres Rhythmus fest.
Laufende Projekte: Verwenden Sie dasselbe Projekt in mehreren Sprints und Versionen. Dies ist der empfohlene Ansatz für Teams mit fortlaufender Funktionsentwicklung und stabilem Metadaten- und Datenumfang. Diese Projekte sind einfacher zu verwalten. Langlebige Projekte sind beispielsweise ideal für ein Team, das alle zwei Wochen veröffentlicht und eine Pipeline verwendet, unabhängig vom Sprint. Sie können die Projektleistung mithilfe von DORA-Kennzahlen und dem Verlauf im Aktivitätsverlauf verfolgen.
Projekte pro Version: Erstellen Sie ein Projekt für jede Hauptversion. Dieser Ansatz funktioniert besser für Teams mit diskreten Initiativen oder Hauptversionsversionen. Dies erfordert für jede Version mehr Setup-Arbeit. Es wird empfohlen, die Projekte nach der Veröffentlichung zu archivieren.
Hotfix-Projekte: Verwenden Sie bei kritischen Produktionsproblemen ein separates Hotfix-Projekt, um eine schnellere Bearbeitung zu unterstützen.
- Erstellen Sie ein Projekt und stellen Sie eine Verbindung zu einer Pipeline her, die mindestens eine Entwicklungsumgebung, eine Testphase und eine Produktionsorganisation enthält.
- Nachdem Sie das Problem behoben haben, verschieben Sie alle Änderungen durch Ihre Standardprojekt-Pipeline und halten Sie alle Umgebungen synchron.
- Synchronisieren Sie Änderungen an Ihrem Hauptprojekt immer zurück, um Divergenzen bei Zweigstellen zu vermeiden.
Verwalten inaktiver Projekte
Sie können ein Projekt im DevOps Center nicht löschen. Fügen Sie Ihrem inaktiven Projekt ein z_-Präfix hinzu. Beispiel: z_MyOldProject. Dadurch wird das Projekt an den unteren Rand der Liste verschoben.
Konfigurieren der .forceignore-Datei
Die .forceignore-Datei bestimmt, welche Änderungen DevOps Center während des Commits und der Bereitstellung ausschließt. Konfigurieren Sie die .forceignore-Datei im Hauptzweig, bevor Sie Ihre Pipeline erstellen, damit sie in alle Funktionszweige übernommen wird. Wenden Sie zum Ändern einer .forceignore-Datei die Bearbeitungen in der Funktionsverzweigung der Arbeitselemente an. Die Bearbeitungen werden während der Höherstufung des Arbeitselements durch Ihre Pipeline übernommen. Entsprechende Informationen finden Sie unter Ausschließen von Metadaten mit .forceignore File.
DevOps Center-Projektstrategieempfehlungen
| SZENARIO | Empfehlung | Beispiel |
|---|---|---|
| Dieselbe Produktionsorganisation mit sich überschneidenden Metadaten und Daten. | Ein Projekt, eine Repository-Struktur | Ein Plattformteam passt verbundene Objekte an. Ihr Team entwickelt Sales Cloud-Funktionen, bei denen Entwickler das Opportunity-Objekt anpassen, während andere an Kampagnen arbeiten. Beide Funktionen verwenden freigegebene benutzerdefinierte Objekte. Verwenden Sie ein Projekt, da sich die Metadaten überschneiden. |
| Dieselbe Produktionsorganisation mit unabhängigen Metadaten und Daten. | Eine Projektstruktur (bevorzugt) | Parallele Arbeit verfolgt, wo ein Apex Team und ein Marketing Cloud-Konnektorteam in einer freigegebenen Umgebung bereitgestellt werden. |
| Geographisch oder betrieblich getrennte Produktionsorganisationen. | Getrennte Projekte | Unabhängige Bereitstellungen zur Trennung von europäischen und US-amerikanischen Produktionsorganisationen aufgrund von Anforderungen an die Datenresidenz. Die Organisationen enthalten ähnliche Anwendungen, werden jedoch unabhängig bereitgestellt. Erstellen Sie zwei Projekte, eines für jede Produktionsorganisation. |
| Dringend erforderlicher Hotfix-Pipeline-Pfad. | Separates Hotfix-Projekt | Wichtige Korrekturen, die einen isolierten Pfad erfordern, um den Standardversionszyklus zu umgehen. |
