Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Lernen der Grundlagen des Release-Managements

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

  • Identifizieren der drei Versionskategorien und Änderungsarten, die in jede Kategorie einfließen
  • Beschreiben von Änderungssets
  • Erläutern, warum es wichtig ist, Änderungen und Abhängigkeiten für Änderungssetversionen zu verfolgen

In dieser Einheit beginnen Calvin und seine Kollegen damit, den ALM-Prozess anzuwenden. Während Sie lesen, denken Sie über die Auswahlmöglichkeiten nach, die Ihnen für Ihr Team offenstehen. Arbeiten Sie anschließend die Module durch, die am Ende dieses Moduls aufgelistet sind, um sich mit dem Prozess vertraut zu machen, sodass Sie in der Lage sind zu entscheiden, was das Richtige für Sie ist.

Erstellen eines Versionsverwaltungsprozesses

Das Zephyrus-Team passt seine Anpassungspraktiken an die bewährten ALM-Schritte an. Es dauert ein wenig, bis es sich an den Prozess gewöhnt hat, aber der Aufwand lohnt sich. Die Entwicklungsgeschwindigkeit nimmt zu und die Unterbrechungen im Vertriebsteam nehmen ab. Das reicht aus, um das Team zu überzeugen und das Management ist hocherfreut.

Durch die Implementierung des ALM-Zyklus hat Zephyrus einen grundlegenden Versionsverwaltungsprozess angenommen. Das Team hat jedoch sowohl große als auch kleine Projekte, die gerade durchgeführt werden, und zwar alle in unterschiedlichen Phasen des ALM-Zyklus. Um dazu beizutragen, dass die Projekte und Erwartungen unter Kontrolle gehalten werden, ergänzt Calvin die Struktur, indem er einen Versionszeitplan erstellt und die Kriterien für unterschiedlich große Versionen definiert.

Versionen werden für gewöhnlich in eine der folgenden drei Kategorien eingeteilt.

Patch
Fehlerbehebungen und einfache Änderungen. Einfache Änderungen sind u. a. Berichte, Dashboards, Listenansichten und E-Mail-Vorlagen.
Nebenversion
Änderungen mit geringen Auswirkungen wie eine neue Workflowregel oder ein Trigger, der sich nur auf einen Geschäftsprozess auswirkt. Diese Versionen müssen normalerweise getestet werden; sie erfordern jedoch nur begrenztes Schulungs- und Änderungsmanagement. In der Regel liefert ein Team die Änderungen für ein kleineres Update innerhalb einiger Wochen.
Hauptversion
Änderungen mit signifikanten Auswirkungen wie Änderungen mit einer oder mehr Abhängigkeiten. Da sich diese Versionen deutlich auf die Benutzeroberfläche und die Datenqualität auswirken können, erfordern sie gründliche Tests, Schulungen und ein sorgfältiges Änderungsmanagement. Hauptversionen werden meist einmal pro Quartal herausgegeben (oder, wie bei Salesforce, dreimal pro Jahr).

Freigabe nach einem konsequenten Zeitplan. Versuchen Sie, neue Versionen in regelmäßigen zeitlichen Abständen und an einem bestimmten Wochentag herauszugeben. Beispielsweise werden kleinere Updates jeden Monat am ersten Dienstag um 20 Uhr MEZ herausgegeben. Die Zeitplankonsistenz ermöglicht die unternehmensweite Planung und weckt Erwartungen bei Geschäftskunden. Eines noch: Versuchen Sie, keine Versionen kurz vor oder nach Feiertagen oder anderen wichtigen Ereignissen herauszugeben.

Verfolgen eines Änderungssets auf seinem Weg bis zur Produktion

Auf seinem Weg durch die ALM-Schritte verwendet das Team bei Zephyrus das Änderungsset-Entwicklungsmodell. Mit der Setup-Benutzeroberfläche werden Änderungen in einer Entwicklungsumgebung erstellt, woraufhin diese Änderungen auf ihrem Weg durch die ALM-Schritte von einer Umgebung zur nächsten migriert werden.

In der Änderungssetentwicklung besteht das Versionsartefakt aus einem Set Metadatenänderungen, wie Diff oder Delta, bezogen auf das, was sich in der Produktionsorganisation findet. Es werden lediglich Metadaten freigegeben, die hinzugefügt oder geändert wurden; wenn sie nicht geändert wurden, sind sie nicht in der Version enthalten.

  • Jeder Entwickler verfolgt alle Änderungen, die in seiner Anpassung für die Version vorgenommen wurden. Das Tool für die Verfolgung kann alles sein; von einem Arbeitsblatt bis hin zu einem Arbeitserfassungssystem.
  • Bestimmte geänderte Komponenten sind ggf. noch nicht in der Metadaten-API verfügbar und müssen manuell von einer Umgebung zur nächsten migriert werden. Wenn Sie diese Änderungen verfolgen, werden Sie nicht vergessen, sie zu migrieren.
  • Als Release-Manager arbeitet Calvin darauf hin, abhängige Komponenten in der Version zu entdecken und einzubeziehen. Es ist beispielsweise unmöglich, ein neues benutzerdefiniertes Feld in die nächste Umgebung zu migrieren, wenn das benutzerdefinierte Objekt, zu dem es gehört, in der Zielorganisation nicht vorhanden ist. Das Änderungsset-Tool hilft Calvin dabei, diese Abhängigkeiten zu identifizieren.

Seite 'Komponentenabhängigkeiten', auf der Abhängigkeiten nach Namen und Bezug aufgeführt sind.

Hinweis

Hinweis

Das Migrieren von Profilen und Berechtigungssätzen kann schwierig sein. Schauen Sie sich die besonderen Überlegungen für das Einsetzen und Abrufen von Profilen und Berechtigungssätzen an, bevor Sie fortfahren.

Das Verfolgen der Änderungen in jeder Version ist arbeitsaufwändig, aber wenn Sie alles genau aufzeichnen, geht die Einführung problemlos vonstatten, wenn Sie zur Produktion übergehen.

Und jetzt alle zusammen!

Ihre Version kann mehrere Projekte enthalten, und jedes Projekt kann in separaten Umgebungen entwickelt und getestet werden. Vor dem Entwicklungsschritt migrieren Sie jedoch alle Änderungen aus allen Projekten zur Integration in dieselbe Umgebung. Ab diesem Punkt erfolgen Ihre Änderungen und Versionsanpassungen als einzelne integrierte Änderungssets auf dem Weg Richtung Produktion. In der Testversionsphase nach der Entwicklung, testen Sie alle Änderungen gemeinsam.

Calvin verfolgt als Release-Manager die Änderungen aller Personen, die einen Beitrag zu der Version geleistet haben. Er verfolgt auch alle Änderungen, die in der Produktion erfolgt sind und sich noch nicht aus den Entwicklungs- und Testumgebungen ergeben. Grund Dies ist die einzige Art und Weise, auf die sie Anpassungen erfolgreich vornehmen können, ohne versehentlich Änderungen der Produktionsorganisation zu überschreiben.