Zum Inhalt springen

Release-Management im Jitterbit App Builder

Dieser Artikel erläutert Best Practices, Voraussetzungen für die Erstellung eines Releases und die Schritte für das allgemeine Release-Management im App Builder. Detaillierte Anweisungen zum Erstellen des App Builder Releases im App Builder selbst finden Sie unter Release erstellen Artikel.

Bewährte Methoden

Die Umfeld ist keine Sandbox. App Builder erfasst jede Datenbankänderung, verfolgt sie und gibt sie in der Qualitätssicherung wieder, sobald die Datenbank ausgeliefert wird. Daher sollte der Entwickler Änderungen in der Umfeld so anwenden, wie er es in der Qualitätssicherung und Produktion erwartet. Es gibt zwei Arten von Änderungen, die App Builder in der Entwicklung erfasst und bei einem Upgrade der Qualitätssicherung und Produktion 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 Regel zum Erstellen/Aktualisieren/Löschen definiert und in der Umfeld ausgeführt. App Builder zeichnet die Regel auf und führt sie während eines Upgrades aus.

Transportieren Sie alle abhängigen Anwendungen und Datenquellen

Nur eine Anwendung oder nur eine Datenquelle ausliefern

Obwohl es möglich ist, eine einzelne Anwendung oder Datenquelle von der Entwicklung an die Qualitätssicherung zu senden, sollte dies nur von erfahrenen Administratoren mit detaillierten Kenntnissen der mit dem Objekt gesendeten Änderungen durchgeführt werden. Generell empfiehlt es sich, alle abhängigen Objekte einzubeziehen, wenn eine Lösung von der Entwicklung an die Qualitätssicherung und die Produktion gesendet wird. Im Folgenden sind einige Szenarien aufgeführt, die zu berücksichtigen sind, wenn nicht alle abhängigen Objekte einbezogen werden:

Ein Designer fügt einem Datenobjekt in Datenquelle A eine Spalte hinzu. Anschließend fügt er einem Panel in Anwendung X ein Steuerelement hinzu, das an die neue Spalte gebunden ist. Versucht der Entwickler, Datenquelle A an die Qualitätssicherung zu senden, verläuft das Upgrade erfolgreich. Das Datenobjekt erhält eine neue Spalte, die jedoch nicht von der Anwendung verwendet wird. Führt der Entwickler jedoch Anwendung X an die Qualitätssicherung aus, ohne Datenquelle A in seine Lösung aufzunehmen, schlägt das Upgrade fehl. Während des Upgrades versucht App Builder, das neue Steuerelement hinzuzufügen. Die angebundene Spalte ist jedoch in der aktuellen Datenquelle der Qualitätssicherung nicht vorhanden und kann daher nicht hinzugefügt werden.

Mehrere Anwendungen verwenden dieselbe Datenquelle

Angenommen, Anwendung X und Anwendung Y verweisen beide auf Datenquelle A. Ein Team arbeitet an Anwendung X und ein anderes an Anwendung Y. Beide Teams haben einem Datenobjekt in Datenquelle A Spalten hinzugefügt und beide Teams haben den Anwendungen X und Y Steuerelemente hinzugefügt, die an diese Spalten gebunden sind. Eines der Teams hat außerdem ein Steuerelement aus Anwendung X entfernt und die Spalte Z entfernt, an die das Steuerelement gebunden war. Wenn ein Entwickler versucht, Anwendung Y und Datenquelle A an die Qualitätssicherung zu senden, schlägt das Upgrade fehl. App Builder versucht, Spalte Z aus Datenquelle A zu entfernen, aber die Spalte wird in der Qualitätssicherung noch von Anwendung X referenziert, weshalb das Upgrade die Spalte nicht entfernen kann. Um ein erfolgreiches Upgrade zu gewährleisten, sollten Sie alle Anwendungen und Datenquellen, auf die in der Lösung verwiesen wird, einbeziehen.

Hinzufügen einer Spalte ungleich Null

Nutzen Sie Migrationsregeln. Angenommen, die Tabelle „Mitarbeiter“ wurde an die Qualitätssicherung und Produktion übergeben und mit Produktionsdaten gefüllt. Ein Entwickler entfernt anschließend alle Zeilen aus dieser Tabelle, um eine Spalte mit dem Wert „Nicht Null“ hinzuzufügen (Active Boolean Allow Nulls = False). Dieser Operation ist in der Umfeld erfolgreich, da keine Mitarbeiterdatensätze vorhanden sind. Wird dieser Änderungssatz jedoch in der Qualitätssicherung oder Produktion angewendet, schlägt er fehl. Eine RDMBs-Datenbank erlaubt das Hinzufügen einer Spalte mit dem Wert „Nicht Null“ zu einer Tabelle mit Zeilen nicht.

Löschen Sie stattdessen in der Umfeld die Mitarbeiterdatensätze nicht. Belassen Sie sie, damit die Umfeld die Zielumgebungen für Qualitätssicherung und Produktion repräsentiert. Fügen Sie die neue Spalte zur Tabelle „Mitarbeiter“ hinzu, lassen Sie jedoch Nullwerte zu (Active Boolean Allow Nulls = True). Erstellen Sie eine Migrationsregel, die den Wert von „Mitarbeiter.Active“ für alle Mitarbeiter auf „true“/„false“ aktualisiert. Führen Sie die Regel aus. Ändern Sie die neue Spalte in „Allow Nulls = False“. Dieser Operation ist in der Entwicklung erfolgreich und wird auch nach der Auslieferung an Qualitätssicherung und Produktion erfolgreich sein. App Builder führt während des Upgrades die folgenden Schritte aus:

  1. Aktiv zur Mitarbeitertabelle hinzufügen Nullen zulassen = Wahr
  2. Aktualisieren Sie alle Mitarbeiterzeilen, sodass Aktiv = wahr/falsch ist.
  3. Ändern Sie die Spalte „Aktiv“ in „Nullwerte zulassen = Falsch“.

Hinweis

Verwenden Sie unterstützte Ausdrücke, um das Aktiv-Bit je nach praktischen Gegebenheiten auf „true“/„false“ zu setzen. Beim Hinzufügen einer Spalte zu einer Tabelle wird normalerweise nicht erwartet, dass alle Zeilen denselben Wert für diese Spalte haben. In diesem Szenario könnte die Migrationsregel „Aktiv“ für Vertragsmitarbeiter, die im letzten Jahr nicht unter Vertrag standen, auf „Falsch“ setzen, während für alle anderen Mitarbeiterzeilen „Aktiv“ = „true“ gesetzt wird.

Ändern des Primärschlüssels einer Tabelle

Seien Sie vorsichtig, wenn Sie einen Primärschlüssel einer Tabelle ändern, die bereits an die Qualitätssicherung gesendet wurde und Daten enthält. Stellen Sie außerdem sicher, dass die Umfeld Daten in der Tabelle enthält, damit sie die Qualitätssicherungs- und Produktionsumgebung optimal repräsentiert. Es gibt verschiedene Möglichkeiten, wie sich ein Primärschlüssel ändern kann. Ein Beispiel:

Angenommen, die Tabelle „Employee“ verfügt über eine Spalte „EmployeeId Integer Primary Key“. Nehmen Sie außerdem an, dass die Tabelle „EmployeeAccrual“ eine Spalte „EmployeeId Integer“ enthält (der Fremdschlüssel verweist auf „Employee.EmployeeId“). Die Tabelle „Employee“ enthält außerdem eine Spalte „SocialSecurity“ (String Unique Allow Nulls = False).

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

  1. Fügen Sie „SocialSecurity String Allow Null = True“ zu „EmployeeAccrual“ hinzu.
  2. Erstellen Sie eine Migrationsregel, die EmployeeAccrual.SocialSecurity in Employee.SocialSecurity aktualisiert und die beiden Tabellen anhand der EmployeeId verknüpft. Führen Sie die Migrationsregel aus.
  3. Ändern Sie SocialSecurity in EmployeeAccrual in Allow Nulls = False
  4. Löschen Sie die Beziehung zwischen Employee und EmployeeAccrual auf EmployeeId
  5. Löschen Sie die Spalte EmployeeId aus EmployeeAccrual
  6. Ändern Sie den Primärschlüssel von Employee in SocialSecurity
  7. Löschen Sie die Spalte EmployeeId aus der Employee-Tabelle
  8. Erstellen Sie eine Beziehung zwischen Employee und EmployeeAccrual auf SocialSecurity

App Builder zeichnet diese Schritte auf und führt sie beim Upgrade von QA und Prod erfolgreich aus.

Notiz

Während der Schritte 1 bis 8 wird erwartet, dass der Entwickler Änderungen an Datenobjekten, Aktionen, Bedienfeldern, Steuerelementen usw. vornimmt. Diese Änderungen können jederzeit vorgenommen werden. Im obigen Beispiel können die acht aufgeführten Schritte über einen Zeitraum von acht Stunden ausgeführt werden, wobei auch mehrere Seiten, Datenobjekte und Steuerelemente in verschiedenen Phasen geändert werden. Wichtig ist, die aufgeführten Schritte in der richtigen Reihenfolge auszuführen, damit sie bei einem Upgrade in der richtigen Reihenfolge ausgeführt werden. Es ist möglich und in Ordnung, während dieser Schritte beliebig viele Änderungen an der logischen Datenquelle oder Anwendung vorzunehmen.

Vermeiden Sie den Import von Schema

Wenn Sie eine physische Datenbank von der Entwicklung über die Qualitätssicherung in die Produktion verschieben und diese über die App Builder Benutzeroberfläche weiter bearbeiten und die Änderungen an die Qualitätssicherung und Produktion übermitteln möchten, verwenden Sie nicht die Importfunktion für App Builder Datenquellen. Um in der Entwicklung vorgenommene Änderungen zu übertragen, erfasst App Builder diese Änderungen, sobald sie über die Benutzeroberfläche vorgenommen werden. Beim Importieren einer Datenquelle wird die App Builder Benutzeroberfläche umgangen und das logische Modell von App Builder mit dem physischen Modell der importierten Datenquelle synchronisiert. Daher werden bei einem Upgrade keine Änderungen an der importierten Datenquelle übernommen. In einigen Situationen wird der Import durch das Release Management unterstützt:

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

Voraussetzungen zum Erstellen einer Version

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

  1. Stellen Sie sicher, dass der App Builder-Datenbankbenutzer in der Umfeld, in der Sie die Installation durchführen, über die Berechtigung zum Erstellen von Tabellen und Datenbanken verfügt.
  2. Stellen Sie sicher, dass ein Datenbankadministrator eine Datenbanksicherung sowohl der App Builder Datenbank als auch aller Datenbanken durchführt, bei denen physische und/oder Schema vorgenommen werden.
  3. Stellen Sie sicher, dass das zu installierende Umfeld auf derselben Version von App Builder ausgeführt wird wie die Umfeld.

Schritte zum Release-Management

  1. Überprüfen Sie die Funktionalität der App Builder Anwendung anhand der Teststandards Ihres Unternehmens.
  2. Erstellen Sie eine Liste aller angehängten Datenquellen für die Anwendung, für die Sie eine Version erstellen. Diese Informationen sind in der App Builder IDE verfügbar. Erstellen Sie Ihre Anwendung, klicken Sie darauf und überprüfen Sie das resultierende Datenquellen-Panel.
  3. Erstellen Sie eine Release-Vorlage für die Anwendung und stellen Sie sicher, dass alle Anwendungen, die beworben werden sollen, enthalten sind.
  4. Stellen Sie sicher, dass alle in Schritt 2 identifizierten verknüpften Datenquellen in der Vorlage enthalten sind.
  5. Überprüfen Sie die Vorlagenkonfiguration für Datenquellen. Legen Sie Logisch und Physisch nur für Datenquellen fest, für die Sie Schema mit App Builder verwalten.
  6. Überprüfen und bestätigen Sie alle offenen Schritte zur Datenbankänderungsverwaltung für Datenbanken, die als Logische und Physische Installation gekennzeichnet sind.
  7. Konfigurieren Sie die Datenkonfiguration für Tabellen in Datenbanken, die für die logische und physische Installation markiert wurden.
  8. Sobald die Datenkonfiguration abgeschlossen ist, bestätigen Sie die Datenkonfiguration.
  9. Erstellen Sie die Version. Detaillierte Anweisungen zum Erstellen einer Version im App Builder finden Sie im Abschnitt Erstellen einer Version Artikel.