Zum Inhalt springen

Release Management in Jitterbit App Builder

Dieser Artikel führt durch Best Practices, Voraussetzungen zum Erstellen eines Release und Schritte für das allgemeine Release Management in App Builder. Detaillierte Anweisungen zum Erstellen des App Builder Release innerhalb von App Builder selbst finden Sie im Artikel Release erstellen.

Informationen dazu, wie Release Management in eine übergeordnete Plattform-Upgrade-Strategie passt, finden Sie unter Produktionsupgrade-Strategien.

Best Practices

Die Entwicklungsumgebung ist keine Sandbox. App Builder erfasst jede Datenbankänderung, verfolgt sie und spielt sie in QA ab, wenn die Datenbank versendet wird. Daher sollte der Entwickler Änderungen in der Entwicklungsumgebung auf die gleiche Weise vornehmen, wie er erwartet, dass die Änderungen in QA und Prod angewendet werden. Es gibt zwei Arten von Änderungen, die App Builder in der Entwicklung erfasst und während eines Upgrades von QA und PROD anwendet:

Schemaänderungen

  1. Umbenennen einer Tabelle
  2. Hinzufügen/Ändern/Löschen einer Spalte
  3. Ändern eines Primärschlüssels
  4. Hinzufügen/Ändern/Löschen eines Fremdschlüssels
  5. Hinzufügen/Ändern/Löschen einer eindeutigen Einschränkung

Migrationsregeln – Migrationsregeln werden ähnlich wie eine Create/Update/Delete-Regel definiert und werden in der Entwicklungsumgebung ausgeführt. App Builder zeichnet die Regel auf und führt sie während eines Upgrades aus.

Alle abhängigen Anwendungen und Datenquellen transportieren

Nur eine Anwendung oder nur eine Datenquelle versenden

Obwohl es möglich ist, eine einzelne Anwendung oder eine einzelne Datenquelle von Dev zu QA zu versenden, sollte dies nur von fortgeschrittenen Administratoren mit detailliertem Wissen über die mit dem Objekt versendeten Änderungen durchgeführt werden. Im Allgemeinen ist es am besten, alle abhängigen Objekte beim Versenden einer Lösung von Dev zu QA und Prod einzubeziehen. Im Folgenden sind einige Szenarien zu berücksichtigen, wenn nicht alle abhängigen Objekte einbezogen werden:

Ein Designer fügt eine Spalte zu einem Datenobjekt in Datenquelle A hinzu. Anschließend fügt er ein Steuerelement zu einem Panel in Anwendung X hinzu, das an die neue Spalte gebunden ist. Wenn der Entwickler versucht, Datenquelle A zu QA zu versenden, wird das Upgrade erfolgreich sein. Das Datenobjekt hat eine neue Spalte, wird aber nicht von der Anwendung verwendet. Wenn der Entwickler jedoch Anwendung X zu QA versendet, ohne Datenquelle A in seine Lösung einzubeziehen, wird das Upgrade fehlschlagen. Während des Upgrades der Anwendung versucht App Builder, das neue Steuerelement hinzuzufügen, aber die Spalte, an die es gebunden ist, existiert nicht in der aktuellen Datenquelle in QA und kann daher nicht hinzugefügt werden.

Mehrere Anwendungen, die die gleiche Datenquelle verwenden

Angenommen, Anwendung X und Anwendung Y verweisen beide auf Datenquelle A. Ein Team arbeitet an Anwendung X und ein anderes Team arbeitet an Anwendung Y. Beide Teams haben Spalten zu Datenobjekten in Datenquelle A hinzugefügt und haben Steuerelemente zu Anwendungen X und Y hinzugefügt, die an diese Spalten gebunden sind. Eines der Teams hat auch ein Steuerelement aus Anwendung X entfernt und die Spalte „Spalte Z" entfernt, an die das Steuerelement gebunden war. Wenn ein Entwickler versucht, Anwendung Y und Datenquelle A zu QA zu versenden, wird das Upgrade fehlschlagen. App Builder versucht, Spalte Z aus Datenquelle A zu entfernen, aber die Spalte wird immer noch von Anwendung X in QA referenziert und das Upgrade kann die Spalte daher nicht entfernen. Es ist am besten, alle Anwendungen und Datenquellen einzubeziehen, auf die in der Lösung verwiesen wird, um sicherzustellen, dass das Upgrade erfolgreich ist.

Hinzufügen einer Spalte, die nicht null ist

Nutzen Sie Migrationsregeln. Angenommen, eine Tabelle „Employee" wurde zu QA und PROD versendet und mit Produktionsdaten gefüllt. Ein Entwickler entfernt dann alle Zeilen aus dieser Tabelle, um eine NOT NULL-Spalte hinzuzufügen (Active Boolean Allow Nulls = False). Dieser Vorgang wird in der Entwicklungsumgebung erfolgreich sein, da keine Mitarbeiterdatensätze vorhanden sind. Wenn dieser Changeset jedoch in QA oder PROD angewendet wird, schlägt er fehl. Eine RDBMS-Datenbank lässt nicht zu, dass eine NOT NULL-Spalte zu einer Tabelle hinzugefügt wird, die Zeilen enthält.

Stattdessen sollte man in der Entwicklungsumgebung die Mitarbeiterdatensätze nicht löschen. Man lässt sie so, dass die Umgebung repräsentativ für die QA- und PROD-Zielumgebungen ist. Man fügt die neue Spalte zur Tabelle „Employee" hinzu, erlaubt aber Nullwerte (Active Boolean Allow Nulls = True). Man erstellt eine Migrationsregel, die den Wert von Employee.Active für alle Mitarbeiter auf true/false aktualisiert. Man führt die Regel aus. Man ändert die neue Spalte so, dass Allow Nulls = False ist. Dieser Vorgang wird in der Entwicklung erfolgreich sein und wird auch bei der Bereitstellung in QA und PROD erfolgreich sein. App Builder führt während des Upgrades die folgenden Schritte aus:

  1. Active zur Tabelle „Employee" mit Allow Nulls = True hinzufügen
  2. Alle Zeilen der Tabelle „Employee" aktualisieren, um Active = true/false zu haben
  3. Die Spalte „Active" so ändern, dass Allow Nulls = False ist

Hinweis

Man verwendet unterstützte Ausdrücke, um das Bit „Active" basierend auf praktischen Bedingungen auf true/false zu setzen. Normalerweise wird nicht erwartet, dass alle Zeilen denselben Wert für diese Spalte haben, wenn man eine Spalte zu einer Tabelle hinzufügt. In diesem Szenario könnte die Migrationsregel „Active" für Vertragsmitarbeiter, die im letzten Jahr nicht unter Vertrag waren, auf False setzen, während alle anderen Mitarbeiterdatensätze Active = true erhalten.

Ändern des Primärschlüssels einer Tabelle

Man sollte vorsichtig sein, wenn man einen Primärschlüssel in einer Tabelle ändert, die bereits in QA bereitgestellt wurde und Daten enthält. Auch hier ist es am besten, sicherzustellen, dass die Entwicklungsumgebung Daten in der Tabelle enthält, damit sie die QA- und Prod-Umgebungen am besten darstellt. Es gibt mehrere Möglichkeiten, wie sich ein Primärschlüssel ändern kann. Im Folgenden ist ein Beispiel aufgeführt:

Angenommen, „Employee" hat eine Spalte „EmployeeId" (Integer Primary Key). Angenommen auch, dass „EmployeeAccrual" eine Spalte „EmployeeId" (Integer, Fremdschlüssel verweist auf Employee.EmployeeId) hat. Die Tabelle „Employee" hat auch eine Spalte „SocialSecurity" (String Unique Allow Nulls = False).

Der Entwickler hat beschlossen, den Primärschlüssel von „Employee" von „EmployeeId" zu „SocialSecurity" zu ändern. Dies sind die empfohlenen Schritte:

  1. „SocialSecurity" (String Allow Null = True) zu „EmployeeAccrual" hinzufügen.
  2. Eine Migrationsregel erstellen, die „EmployeeAccrual.SocialSecurity" aktualisiert, um „Employee.SocialSecurity" zu sein, indem man die beiden Tabellen auf „EmployeeId" verbindet. Die Migrationsregel ausführen.
  3. „SocialSecurity" in „EmployeeAccrual" so ändern, dass Allow Nulls = False ist
  4. Die Beziehung zwischen „Employee" und „EmployeeAccrual" auf „EmployeeId" löschen
  5. Die Spalte „EmployeeId" aus „EmployeeAccrual" löschen
  6. Primärschlüssel von „Employee" zu „SocialSecurity" ändern
  7. Die Spalte „EmployeeId" aus der Tabelle „Employee" löschen
  8. Beziehung zwischen „Employee" und „EmployeeAccrual" auf „SocialSecurity" erstellen

App Builder zeichnet diese Schritte auf und führt sie während des Upgrades von QA und Prod erfolgreich aus.

Hinweis

Während man die Schritte 1 bis 8 ausführt, wird erwartet, dass der Entwickler Änderungen an Datenobjekten, Aktionen, Panels, Steuerelementen usw. vornimmt. Man kann diese Änderungen jederzeit vornehmen. Im obigen Beispiel ist es möglich, dass die aufgelisteten 8 Schritte über einen Zeitraum von 8 Stunden ausgeführt werden, während mehrere Seiten, Datenobjekte und Steuerelemente auch in verschiedenen Phasen geändert werden. Der wichtige Punkt ist, die aufgelisteten Schritte in der richtigen Reihenfolge auszuführen, damit sie während eines Upgrades in der richtigen Reihenfolge ausgeführt werden. Es ist zu erwarten und in Ordnung, eine beliebige Anzahl von Änderungen an der logischen Datenquelle oder Anwendung vorzunehmen, während man diese Schritte ausführt.

Schema-Import vermeiden

Wenn die Absicht besteht, eine physische Datenbank von Dev zu QA zu Prod zu verschieben und diese physische Datenbank dann über die App Builder-Benutzeroberfläche weiter zu ändern und diese Änderungen in QA und Prod bereitzustellen, sollte man die Importfunktion für App Builder-Datenquellen nicht verwenden. Um in der Entwicklung vorgenommene Änderungen bereitzustellen, erfasst App Builder diese Änderungen, während sie über die Benutzeroberfläche vorgenommen werden. Das Importieren einer Datenquelle umgeht die App Builder-Benutzeroberfläche und synchronisiert das logische App Builder-Modell mit dem physischen Modell der importierten Datenquelle. Daher würden keine Änderungen in der importierten Datenquelle während eines Upgrades weitergegeben. Es gibt Situationen, in denen der Import mit Release Management unterstützt wird:

  1. Wenn die physische Datenbank außerhalb von App Builder in allen Umgebungen gepflegt und geändert wird, wird das Importieren der Datenquelle während des gesamten Entwicklungslebenszyklus unterstützt.
  2. Wenn die physische Datenbank von Dev/QA/Prod gemeinsam genutzt wird, wird das Importieren der Datenquelle während des gesamten Entwicklungslebenszyklus unterstützt.

Voraussetzungen für die Erstellung eines Release

Die folgenden Punkte sollten vor der Erstellung eines App Builder Release berücksichtigt und abgeschlossen werden:

  1. Stellen Sie sicher, dass der App Builder db User über Table- und Database Create-Berechtigungen in der Umgebung verfügt, in der Sie installieren.
  2. Stellen Sie sicher, dass ein Datenbankadministrator eine Datenbanksicherung sowohl der App Builder-Datenbank als auch aller Datenbanken durchführt, die physische und/oder Schemaänderungen durchlaufen.
  3. Stellen Sie sicher, dass das Umgebungspaket, das installiert wird, auf der gleichen Version von App Builder läuft wie die Quellumgebung.

Schritte für die Release-Verwaltung

  1. Überprüfen Sie anhand Ihrer Unternehmensstandards für Tests die Funktionalität der App Builder-Anwendung.
  2. Erstellen Sie eine Liste aller angehängten Data Sources für die Anwendung, für die Sie ein Release erstellen. Diese Informationen sind in der App Builder IDE verfügbar. Erstellen Sie Ihre Anwendung, klicken Sie auf Ihre Anwendung und überprüfen Sie das resultierende Data Sources Panel.
  3. Erstellen Sie ein Anwendungs-Release Template, und stellen Sie sicher, dass alle Anwendungen, die höher gestuft werden sollen, enthalten sind.
  4. Stellen Sie sicher, dass alle verknüpften Data Sources, die in Schritt 2 identifiziert wurden, im Template enthalten sind.
  5. Überprüfen Sie die Template-Konfiguration für Data Sources. Legen Sie Logical und Physical nur für Data Sources fest, für die Sie Schemaänderungen mit App Builder verwalten.
  6. Überprüfen Sie und committen Sie alle offenen Datenbank-Change-Management-Schritte für Datenbanken, die als Logical und Physical Install gekennzeichnet sind.
  7. Konfigurieren Sie die Data Config für Tabellen in Datenbanken, die für Logical und Physical Install gekennzeichnet wurden.
  8. Sobald Data Config abgeschlossen ist, bestätigen Sie Data Config.
  9. Erstellen Sie das Release. Detaillierte Anweisungen zum Erstellen eines Release in App Builder selbst finden Sie im Artikel Release erstellen.