Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Planen von Änderungen an Ihrer Organisation

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Beschreiben, welche Entwicklungsumgebung bei der Arbeit mit dem Änderungsset-Entwicklungsmodell in den einzelnen ALM-Schritten zu verwenden ist
  • Erstellen einer neuen Sandbox
  • Einrichten einer Methode zur Nachverfolgung von in einer Version vorgenommenen Änderungen

Einführung

Wenn Sie das Modul Modelle für Anwendungslebenszyklus und -entwicklung abgeschlossen haben (wenn nicht, wird empfohlen, es zunächst durchzuarbeiten, bevor Sie dieses Modul lesen), haben Sie Calvin Green von Zephyrus Relocation Services schon kennengelernt. In diesem Modul liefert das Team bei Zephyrus mithilfe der deklarativen Änderungssetentwicklung eines seiner Salesforce-Anpassungen.

Calvin an seinem Schreibtisch bei Zephyrus mit seinem Vetforce-Kaffeebecher

Zephyrus möchte Kunden, die international unterwegs sind, Dienstleistungen in Form von Sprachtraining anbieten. Das Bildungsteam des Unternehmens bindet jetzt Sprachspezialisten ein, die eine große Bandbreite an Kurstypen entwickeln. Einige Kunden lernen eine Sprache ganz neu. Andere benötigen lediglich einen Auffrischungskurs. Und wieder andere möchten ein spezielles Vokabular, wie z. B. für die Arbeit, lernen. Es sind viele Faktoren zu berücksichtigen, wenn einem Kunden ein Sprachkurs empfohlen werden soll.

Calvin und sein Team entschließen sich, ihrer Organisation Sprachkursinformationen mithilfe der Änderungssetentwicklung hinzuzufügen.

Der ALM-Zyklus: Version planen, Entwickeln, Testen, Version erstellen, Version testen, Veröffentlichen

Schriftliches Festhalten der Versionspläne

Calvin legt seine Versionspläne schriftlich fest, sodass die Beteiligten wissen, was vor sich geht, damit weniger Potenzial für Verwirrungen bleibt. Außerdem findet er, dass das schriftliche Festhalten oftmals versteckte Probleme ans Licht bringt. Zuweisungen, Testpläne, Entscheidungen und Meilensteine lassen sich besser konkret überdenken als abstrakt. Und Calvin weiß, dass nichts in Stein gemeißelt ist; er geht davon aus, dass der Plan während des gesamten Freigabeprozesses immer wieder überarbeitet wird, wenn wieder neue Informationen zur Verfügung stehen.

Vorbereiten der Versionsumgebungen

Wenn Sie eine Version planen, vergewissern Sie sich, dass die an der Version Beteiligten auf die Umgebungen zugreifen können, die sie für die einzelnen Schritte im ALM-Prozess benötigen. Calvin und sein Team arbeiten mit dem Änderungsset-Entwicklungsmodell, sodass sie Sandbox-Umgebungen verwenden, die für die Aufgaben in jedem ALM-Schritt optimiert sind. Denken Sie daran, dass eine Sandbox lediglich eine Kopie Ihrer Produktionsorganisation in einer separaten Umgebung ist. Einige Sandboxes enthalten keine Produktionsdaten, während andere unterschiedliche Beträge enthalten. So verwendet Calvins Team Sandboxes in jedem ALM-Schritt.
  • Schritte entwickeln und testen: Jedes Teammitglied hat seine eigene Developer-Sandbox, in der es die ihm zugewiesene Anpassung erstellt. Developer-Sandboxes enthalten keine Produktionsdaten.
  • Version erstellen: Jedes Teammitglied migriert seine Anpassungen aus seiner jeweiligen Developer-Sandbox zur Integration in eine gemeinsame Developer Pro-Sandbox. Developer Pro-Sandboxes enthalten keine Produktionsdaten, aber Sie können sie mit Testdaten versehen.
  • Version testen: Für Benutzerakzeptanztests verwendet das Team eine Vollständige Sandbox, um eine komplette Reproduktion zu erstellen. Eine Vollständige Sandbox enthält Produktionsdaten.
  • Veröffentlichen: Nachdem die Version in Produktion gegangen ist, kann das Team die im letzten Schritt erstellte Vollständige Sandbox verwenden, um Benutzer zu schulen, ohne die Produktionsdaten offenzulegen.

Die Schritte im Anwendungslebenszyklus: mit Developer Pro-Sandboxes entwickeln und testen; Version mit einer Developer Pro-Sandbox erstellen, Version mit einer vollständigen Sandbox testen und zur Produktion freigeben

Erstellen der Umgebungen

Calvin erstellt für den Anfang zwei Developer-Sandboxes: eine für ihn selbst und eine für seine Kollegin Ella. In diesen Sandboxes erstellen und testen Calvin und Ella ihre jeweiligen Anpassungen. Indem er eine Sandbox für jeden Entwickler erstellt, hält Calvin die Änderungen so lange isoliert, bis das Team bereit ist, sie zu integrieren.

Sandboxes sind in der Professional, der Enterprise, der Unlimited und der Performance Edition verfügbar. Calvin zeigt Ella, wie eine Sandbox erstellt wird.

  1. Geben Sie unter "Setup" im Feld Schnellsuche den Text Sandboxes ein und wählen Sie dann Sandboxes aus.
  2. Klicken Sie auf Neue Sandboxversion.
  3. Geben Sie einen Namen und eine Beschreibung für die Sandbox ein.
  4. Wählen Sie als Sandbox-Typ Developer aus.
  5. Klicken Sie auf Version starten.

Das Erstellen der Kopie kann eine Weile dauern, insbesondere, wenn Ihre Produktionsorganisation viele Daten oder Anpassungen hat. Calvin erhält eine Benachrichtigungs-E-Mail, wenn die neue Sandbox mit dem Kopieren fertig ist.

Calvin geht genauso vor, um eine Developer Pro-Sandbox für die Integration und eine Vollständige Sandbox für die Benutzerakzeptanztests und die Benutzerschulung zu erstellen.

Einrichten Ihrer Änderungsverfolgungsmethode

Wenn Sie das Änderungsset-Entwicklungsmodell verwenden, müssen Sie unbedingt alle Änderungen nachverfolgen, und zwar insbesondere die Änderungen, die manuell migriert werden müssen. Wenn Sie Änderungen manuell migrieren, nehmen Sie Änderungen aus einer Umgebung und erstellen sie in einer anderen Umgebung ganz genauso wieder. Sie müssen Änderungen migrieren, wenn die geänderte Komponente noch nicht in der Metadaten-API unterstützt wird.

Woher weiß Calvin, welche Komponenten in der Metadaten-API unterstützt werden? Im "Metadata Coverage"-Bericht können Sie sehen, ob Metadatentypen in der Metadaten-API und anderen Metadatenkanälen unterstützt werden. Dieser dynamisch generierte Bericht ist Ihre beste Quelle für Informationen über die Metadaten-Abdeckung. Für den Zugriff auf den "Metadata Coverage"-Bericht wechseln Sie zu https://developer.salesforce.com/docs/metadata-coverage.

Calvin verfolgt alle Änderungen und Erweiterungen nach, die das Vertriebsteam angefordert hat. Er verwendet ein benutzerdefiniertes Tool, mit dem Entwickler alle von ihnen vorgenommenen Änderungen protokollieren können. Um auf der sicheren Seite zu sein, vergewissert Calvin sich, dass das Tool über Felder für die entscheidenden Informationen über alle Änderungen einer Version und für Änderungen verfügt, die direkt in der Produktion vorgenommen wurden.

  • Wer wird mit der Vornahme der Änderung beauftragt?
  • Muss diese Änderung manuell migriert werden?
  • Welche Komponente ist von dieser Änderung betroffen?
  • Welche Organisationen haben die Änderung zurzeit?
  • Wann wurde die Änderung in den einzelnen Umgebungen vorgenommen?

Warum verfolgt Calvin die in der Produktion vorgenommenen Änderungen, wenn sie nicht Teil einer in Entwicklung befindlichen Version sind? Nur so kann er sicher sein, dass die bereitgestellten Anpassungen das Verhalten der Produktionsorganisation nicht überschreiben oder unerwartet ändern.

Nahezu alle Änderungen, die Calvin und Ella mit der Salesforce-Benutzeroberfläche vornehmen, werden im Setup-Aktivierungsprotokoll festgehalten. Calvin checkt das Aktivierungsprotokoll mithilfe eines Berichts im Änderungsverfolgungs-Tool des Teams gegen, um zu verhindern, dass Änderungen verloren gehen.

Weitere Informationen zur Verwendung des Setup-Aktivierungsprotokolls finden Sie unter Überwachen von Setup-Änderungen in der Salesforce-Hilfe.