Der Salesforce-Release-Train: Ein praktischer Ansatz für das Release-Management

Release Management ist, wie der Name schon sagt, der Prozess der Verwaltung, Planung, Terminierung und Kontrolle eines Software-Builds in verschiedenen Phasen und Umgebungen; einschließlich Testen und Bereitstellen von Softwareversionen (Humble & Farley, 2011).

Es ist ein ziemlich großes Thema für sich und kann nur im Laufe der Zeit perfektioniert werden, indem verschiedene Iterationen mit den Entwicklungsteams ausprobiert und Geschäftsanforderungen oder Feature-Releases angepasst werden. Wir werden versuchen, die Branchenpraktiken der Metadatenverwaltung, CI-Erstellung und Sandbox-Verwaltung für die Verwaltung des Release-Trains einer Organisation abzudecken.

Aber was ist ein Release-Train?

Ein Release Train ist eine inkrementelle und vorhersagbare Technik zur Bereitstellung von Features. Der Entwickler muss einen formalen Prozess einrichten, um alle in der Entwicklungsumgebung vorgenommenen Änderungen zu übernehmen und in der Produktion bereitzustellen.

Ein Freigabezug kann grob in drei Segmente unterteilt werden:

• Metadatenverwaltung
• Continuous-Integration-Build
• Sandbox-Verwaltung

Metadatenverwaltung

Metadaten sind Daten, die Informationen über andere Daten liefern. Salesforce bietet über seine Metadaten-API ein umfassendes und leistungsstarkes Metadatenmodell. Ihre Anwendungsmetadaten beschreiben und umfassen eine Reihe von Methoden, die programmgesteuerten Zugriff auf den Quellcode und die Konfiguration Ihrer Organisation bieten.

Die Metadaten-API ist die beste Möglichkeit, die Anpassungen in Salesforce zu verwalten. Es unterstützt die Methoden create , read , update und delete . Sie können Änderungssätze, die Force.com-IDE und das Ant-Migrationstool verwenden, um Metadaten von einer Organisation zu einer anderen zu migrieren, da sie alle Migrationen über die API bereitstellen.

Jedes Tool hat seine eigenen Vorteile, und bei der Auswahl sind mehrere Dinge zu beachten:

Tabelle 1: Toolvergleich für die Metadatenmigration

Die Metadaten-API erfüllt ihren Zweck hervorragend, wenn Änderungen auf der Force.com-Plattform entwickelt und migriert werden. Aber es gibt einen kleinen Haken: Nicht alle Salesforce-Metadaten werden von der Metadaten-API unterstützt. Die offizielle Dokumentation enthält eine Liste nicht unterstützter Komponenten.

Wenn Ihre Organisation Änderungen vornimmt, die nicht von der Metadaten-API unterstützt werden, müssen Sie sicherstellen, dass diese Änderungen manuell in der Zielorganisation repliziert werden. Der beste Weg, diese Änderungen zu verfolgen, ist eine Tabelle. Wenn Sie auf diesen Ansatz zurückgreifen müssen, ist es immer ratsam, dass eine einzelne Person diese Änderungen vornimmt und nachverfolgt.

Dies wäre eine gute allgemeine Liste von Spalten, die man zum Nachverfolgen dieser Änderungen in einer Tabelle verwenden könnte:

• Name der Komponente
• Art der Komponente
• Besitzer wechseln
• Beschreibung der Funktionalität
• Fähigkeitszuordnung
• Abhängigkeit mit anderen Komponenten
• Name des Bewerteten/Rezensenten
• URL
• Name/ID der Organisation
• Andere Kommentare

Versionskontrolle und kontinuierliche Integration

Das Migrieren von Änderungen in die Produktion sollte ein reibungsloser Prozess sein, da es sich lediglich um eine Wiederholung der Anwendung von Änderungen in der Test- und Staging-Umgebung handelt. Trotzdem besteht immer die Möglichkeit, dass die Dinge schief gehen, und dann brauchen Sie einen Rückfallplan. Es ist sehr wichtig, eine Sicherungskopie der Metadaten Ihrer Organisation zu führen, und dafür sind die Versionskontrolle und der CI-Build da.

Versionskontrolle ist ein absolutes Muss für jedes Unternehmen. Es ermöglicht Entwicklern, kollaborativ, effizient und sicher zu arbeiten. Die Verwaltung der Codeentwicklung und -migration für mehrere Entwickler und mehrere Sandboxen ist eine Herausforderung in Salesforce. Salesforce hat auch einen eigenen Zeitplan für Releases und Wartungsarbeiten. Diese Updates bieten neue Funktionen, könnten jedoch eine Änderung in der Metadaten-API einführen, die Ihren CI-Build beschädigen kann. Abgesehen von Situationen, in denen Entwickler die Änderungen des anderen überschreiben, hilft Ihnen die Versionskontrolle beim Aufbau einer Rollback-Strategie. Eine Rollback-Strategie ist ein Muss, wenn Ihre Anwendung auf Force.com ausgeführt wird.

Das folgende Flussdiagramm zeigt eine praktische Struktur für Versionskontrolle und CI. Wir werden versuchen, Ihnen eine kurze Beschreibung dessen zu geben, was das Diagramm darstellt.

1. Ein Entwickler würde seine Änderung im Versionskontrollsystem einchecken.
2. Der CI-Server/Jenkins würde den neuesten Build in der CI-Sandbox bereitstellen und Testklassen ausführen.
3. Wenn die Bereitstellung in Schritt 2 erfolgreich ist, werden die Änderungen im QA-Branch zusammengeführt.
4. CI würde dann den neuesten Commit aus dem QA-Zweig in der QA-Sandbox bereitstellen.
5. Wenn die QA die Änderungen aufgrund von Testfehlern ablehnt, sollten die Schritte 1 bis 3 erneut ausgeführt werden, bis die QA die Änderungen löscht.
6. Nachdem die Änderungen den QA-Test bestanden haben, werden die Änderungen in den Master-Zweig gemergt.
7. Die neuesten Änderungen aus dem Master-Zweig werden in der Master-Sandbox bereitgestellt.

Je nach Bedarf der Organisation können weitere Zweige hinzugefügt werden. Aber die obige Struktur funktioniert gut für Entwicklungsstrukturen auf mittlerer bis Unternehmensebene.

Sandbox-Verwaltung

Um das Beste aus dem DevOps-Prozess Ihrer Organisation herauszuholen, ist es sehr wichtig, die Sandbox-Struktur einzurichten. Bevor wir tiefer in die Materie eintauchen, lassen Sie uns die verschiedenen Arten von Sandboxes besprechen, die Salesforce uns bietet.

Eine Sandbox ist eine nahezu exakte Kopie der eigenen Produktionsmetadaten. Sandboxes werden in der Regel für Entwicklungs-, Test-, Bereitstellungs- und Schulungszwecke verwendet. Es gibt vier Arten von Sandboxen, und man sollte bei der Auswahl einer Sandbox gebührend überlegen. Vollständige Kopien von Sandboxes können viel Geld kosten!

Nachfolgend finden Sie die Tabelle mit den von Salesforce für verschiedene Sandboxes erzwungenen Limits.

Tabelle 2: Grenzwertvergleich

Wir können sehen, dass der Preis nicht der einzige Unterschied zwischen Sandboxes ist.

Die Entwickler-Sandbox hat einen eintägigen Aktualisierungszeitraum, wodurch sie für die Entwicklung geeignet ist, aber nur 200 MB Daten und keine Produktionsdaten aufnehmen kann. Im Gegensatz dazu verfügen Vollkopie-Sandboxes über eine exakte Kopie der Produktionsdaten; sogar die Datensatz-IDs sind gleich. Das könnte sich hervorragend zum Testen und Staging eignen, aber der Aktualisierungszeitraum von 29 Tagen macht es schwierig, die neuesten Produktionsmetadaten und -daten in der Sandbox für vollständige Kopien zu erhalten.

Die folgende Tabelle dient als Faustregel für die Auswahl von Sandboxes:

Tabelle 3: Anwendungsfälle für die Sandbox-Auswahl

Nachfolgend finden Sie die typische Organisationsstruktur, die für mittelgroße Projekte verwendet wird. Für Kunden auf Unternehmensebene wird die Organisationsstruktur komplexer, folgt jedoch im Großen und Ganzen dem unten stehenden Modell.

Die Salesforce-Entwicklung erfolgt normalerweise in der Entwickler-Sandbox (rot) und die Änderungen werden in die Integrations-Sandbox (grün) verschoben, bei der es sich normalerweise um eine Developer Pro- oder Teilkopie-Sandbox handelt. Dann werden die Änderungen aus mehreren Integrations-Sandboxen nach oben in die Rollup-Sandbox (gelb) verschoben, die eine Teilkopie-Sandbox sein sollte.

Wenn Ihre Organisation über Integrationen mit dem Drittanbietersystem verfügt, für die Integrationstests und Lasttests durchgeführt werden müssen, muss man über einen stabilen Datensatz verfügen, der sich von Release zu Release nicht ändert. Daher ist es besser, eine Sandbox für vollständige oder teilweise Kopien zu haben.

Diese Änderungen werden dann in die Integrationstest-Sandbox verschoben, wo Tests durchgeführt werden. Dann werden die Änderungen in die Staging-Sandbox verschoben, die eine Sandbox mit vollständiger Kopie sein sollte. Alle Testklassen werden vor der Bereitstellung ausgeführt. Es sollte eine Bereitstellungsvalidierung durchgeführt werden, um sicherzustellen, dass die Bereitstellung ohne Probleme erfolgt.

Dieser Prozess hilft uns sicherzustellen, dass die Änderungen mehrere Testrunden und Augenpaare durchlaufen. Es hat den großen Nachteil, dass das Entwickeln, Testen und Bereitstellen von Änderungen viel Zeit in Anspruch nimmt.

Sehr oft besteht dringender Bedarf, Bugfixes oder Patches durchzuführen. Um diese schnell zu bewältigen, sollte man eine Entwickler-Sandbox unterhalten, die kleine Patches direkt in die Rollup-Sandbox schiebt.

Wie bereits erwähnt, ist eine Sandbox eine fast exakte Kopie der Produktionsmetadaten, aber nicht vollständig. Es gibt eine offizielle Liste von Komponenten/Features, die in einer Sandbox deaktiviert sind.

Eine weitere zu berücksichtigende Sache beim Aktualisieren einer Sandbox ist, dass sie nur die Produktionsmetadaten und -daten kopiert. Es gibt keine Möglichkeit, die Metadaten von einer Sandbox in eine andere zu kopieren oder sogar eine leere Sandbox ohne Metadatenkonfigurationen zu erstellen (wie kostenlose Entwicklerorganisationen). Dies wird manchmal zu einer Herausforderung in Situationen des wirklichen Lebens. Salesforce plant, dieses Problem anzugehen, und diese Funktion wird möglicherweise bald allgemein verfügbar sein.

Wenn Sie außerdem sensible Daten in der Produktion haben, auf die Ihr Entwicklungs- oder Testteam Ihrer Meinung nach keinen Zugriff haben sollte, können Sie Sandbox-Vorlagen für vollständig und teilweise kopierte Sandboxen erstellen.

Was Sie bei der Bereitstellung beachten sollten

Wir haben die Branchenpraktiken des Anwendungslebenszyklusmanagements im Salesforce-Ökosystem behandelt. Metadaten- und Sandbox-Management spielen eine sehr wichtige Rolle beim Erstellen der Bereitstellungspakete und Payloads. Bei großen und komplexen Salesforce-Anwendungen hilft die Versionskontrolle sicherzustellen, dass die Metadatenänderungen nachverfolgt werden, und hilft auch bei der Erstellung einer Rollback-Strategie.

Das Sandbox-Management ist für große oder komplexe Projekte von entscheidender Bedeutung. Aber die Sandboxes sind im Salesforce-Ökosystem kostspielig, sowohl in Bezug auf finanzielle Ressourcen als auch auf Zeit. Die Formulierung einer Strategie für das Sandbox-Management ist immer entscheidend für den Release-Management-Prozess.

Wir hinterlassen Ihnen einige zusätzliche Punkte, die Sie bei Ihrem nächsten Einsatz berücksichtigen sollten:

1. Es können nur 10.000 Dateien oder eine 39-MB-ZIP-Datei auf einmal bereitgestellt werden. Wenn die Nutzlast zu groß ist, müssen Sie das Paket natürlich in mehrere Teile aufteilen und dann die Bereitstellung vornehmen.
2. Wenn die Bereitstellung aufgrund eines request timeout fehlschlägt, versuchen Sie, Objekte, benutzerdefinierte Felder und Profile aus dem Paket zu entfernen. Die Bereitstellung dieser Komponenten dauert länger.
3. Wenn ein Feldtyp geändert wird oder Änderungen in der Rollenhierarchie vorgenommen wurden, kann es aufgrund der Neuberechnung der Daten zu langen Verzögerungen kommen, die einige Zeit in Anspruch nehmen.
4. Salesforce sperrt alle Komponenten, die derzeit von einem Benutzer im System verwendet werden. Wenn wir versuchen, bereitzustellen, während dies der Fall ist, schlägt die Bereitstellung fehl.

Hoffentlich hilft Ihnen diese Übersicht bei Ihrer nächsten Salesforce-Version.

Quellen