Zum Inhalt springen

Release-Management im Jitterbit App Builder

Dieser Artikel beschreibt bewährte Verfahren, Voraussetzungen für den Aufbau eines Releases und Schritte für das allgemeine Release-Management im App Builder. Für detaillierte Anweisungen zum Erstellen des App Builder Releases innerhalb des App Builders selbst siehe den Artikel Build a release.

Bewährte Verfahren

Die Entwicklungsumgebung ist kein Sandbox. Der App Builder erfasst jede Datenbankänderung, verfolgt sie und wird sie in QA wieder abspielen, wenn die Datenbank ausgeliefert wird. Daher sollte der Entwickler Änderungen in der Entwicklungsumgebung auf die gleiche Weise anwenden, wie sie erwarten würden, dass die Änderungen in QA und Prod angewendet werden. Es gibt zwei Arten von Änderungen, die der 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 im Entwicklungsumfeld ausgeführt. Der App Builder zeichnet die Regel auf und führt sie während eines Upgrades aus.

Transport aller abhängigen Anwendungen und Datenquellen

Versand nur einer Anwendung oder nur einer Datenquelle

Obwohl es möglich ist, eine einzelne Anwendung oder eine einzelne Datenquelle von Dev nach QA zu versenden, sollte dies nur von fortgeschrittenen Administratoren mit detaillierten Kenntnissen über die Änderungen, die mit dem Objekt versendet werden, durchgeführt werden. Im Allgemeinen ist es am besten, alle abhängigen Objekte einzuschließen, wenn eine Lösung von Dev nach QA und Prod versendet wird. Folgende Szenarien sind zu berücksichtigen, 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 ein Steuerelement zu einem Panel in Anwendung X hinzu, das an die neue Spalte gebunden ist. Wenn der Entwickler versucht, Datenquelle A nach QA zu versenden, wird das Upgrade erfolgreich sein. Das Datenobjekt wird eine neue Spalte haben, obwohl sie von der Anwendung nicht verwendet wird. Wenn der Entwickler jedoch Anwendung X nach QA versendet, ohne Datenquelle A in seiner Lösung einzuschließen, wird das Upgrade fehlschlagen. Während des Upgrades der Anwendung wird der App Builder versuchen, das neue Steuerelement hinzuzufügen, aber die Spalte, an die es gebunden ist, existiert nicht in der aktuellen Datenquelle in QA und daher kann es nicht hinzugefügt werden.

Mehrere Anwendungen, die dieselbe Datenquelle verwenden

Angenommen, Anwendung X und Anwendung Y beziehen sich beide auf Datenquelle A. Ein Team arbeitet an Anwendung X und ein anderes Team an Anwendung Y. Beide Teams haben Spalten zu einem Datenobjekt in Datenquelle A hinzugefügt, und beide Teams haben Steuerelemente zu den 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, die an das Steuerelement gebunden war, gelöscht. Wenn ein Entwickler versucht, Anwendung Y und Datenquelle A an QA zu übergeben, wird das Upgrade fehlschlagen. App Builder wird versuchen, Spalte Z aus Datenquelle A zu entfernen, aber die Spalte wird weiterhin von Anwendung X in QA referenziert, und daher wird das Upgrade fehlschlagen, um die Spalte zu entfernen. Es ist am besten, alle Anwendungen und Datenquellen, die in der Lösung referenziert werden, einzuschließen, um sicherzustellen, dass das Upgrade erfolgreich ist.

Hinzufügen einer Nicht-Null-Spalte

Nutzen Sie die Migrationsregeln. Angenommen, eine Tabelle "Mitarbeiter" wurde an QA und PROD übergeben und mit Produktionsdaten gefüllt. Ein Entwickler entfernt dann alle Zeilen aus dieser Tabelle, um eine NICHT NULL-Spalte (Aktiv Boolean Erlaube Nullwerte = Falsch) hinzuzufügen. Dieser Vorgang wird in der Entwicklungsumgebung erfolgreich sein, da es keine Mitarbeiterdatensätze gibt. Wenn jedoch dieser Änderungsdatensatz in QA oder PROD angewendet wird, wird er fehlschlagen. Eine RDBMS-Datenbank erlaubt es nicht, eine Nicht-Null-Spalte zu einer Tabelle hinzuzufügen, die Zeilen enthält.

Stattdessen sollten in der Entwicklungsumgebung die Mitarbeiterdatensätze nicht gelöscht werden. Lassen Sie sie so, dass die Umgebung repräsentativ für die Zielumgebungen QA und PROD ist. Fügen Sie die neue Spalte zur Tabelle Mitarbeiter hinzu, aber erlauben Sie Nullwerte (Aktiv Boolean Erlaube Nullwerte = Wahr). Erstellen Sie eine Migrationsregel, die den Wert von Mitarbeiter.Aktiv für alle Mitarbeiter auf wahr/falsch aktualisiert. Führen Sie die Regel aus. Ändern Sie die neue Spalte so, dass Erlaube Nullwerte = Falsch ist. Dieser Vorgang wird in der Entwicklung erfolgreich sein und wird auch erfolgreich sein, wenn er an QA und PROD übergeben wird. App Builder wird während des Upgrades die folgenden Schritte ausführen:

  1. Fügen Sie Active zur Employee-Tabelle hinzu, Allow Nulls = True
  2. Aktualisieren Sie alle Employee-Zeilen, um Active = true/false zu haben
  3. Ändern Sie die Active-Spalte in Allow Nulls = False

Hinweis

Verwenden Sie unterstützte Ausdrücke, um das Active-Bit basierend auf praktischen Bedingungen auf true/false zu setzen. Typischerweise wird beim Hinzufügen einer Spalte zu einer Tabelle nicht erwartet, dass alle Zeilen denselben Wert für diese Spalte haben. In diesem Szenario könnte die Migrationsregel Active auf False für Vertragsmitarbeiter setzen, die im letzten Jahr nicht beschäftigt wurden, während alle anderen Mitarbeiterzeilen Active = true haben.

Ändern des Primärschlüssels einer Tabelle

Seien Sie vorsichtig, wenn Sie einen Primärschlüssel in einer Tabelle ändern, die bereits an QA ausgeliefert wurde und Daten enthält. Es ist am besten sicherzustellen, dass die Entwicklungsumgebung Daten in der Tabelle hat, damit sie die QA- und Prod-Umgebungen am besten repräsentiert. Es gibt mehrere Möglichkeiten, wie sich ein Primärschlüssel ändern kann. Folgendes ist ein Beispiel:

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

Der Entwickler hat beschlossen, den Primärschlüssel von Employee von EmployeeId auf 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 auf Employee.SocialSecurity aktualisiert, indem Sie die beiden Tabellen über EmployeeId verbinden. Führen Sie die Migrationsregel aus.
  3. Ändern Sie SocialSecurity in EmployeeAccrual in Allow Nulls = False
  4. Entfernen Sie die Beziehung zwischen Employee und EmployeeAccrual auf EmployeeId
  5. Entfernen Sie die Spalte EmployeeId aus EmployeeAccrual
  6. Ändern Sie den Primärschlüssel von Employee auf SocialSecurity
  7. Entfernen Sie die Spalte EmployeeId aus der Employee-Tabelle
  8. Erstellen Sie eine Beziehung zwischen Employee und EmployeeAccrual auf SocialSecurity

App Builder wird diese Schritte aufzeichnen und erfolgreich ausführen, während QA und Prod aktualisiert werden.

Hinweis

Während der Durchführung der Schritte 1 bis 8 wird erwartet, dass der Entwickler Änderungen an Datenobjekten, Aktionen, Panels, Steuerelementen usw. vornimmt. Fühlen Sie sich frei, diese Änderungen jederzeit vorzunehmen. Im obigen Beispiel ist es möglich, dass die 8 aufgeführten Schritte über einen Zeitraum von 8 Stunden durchgeführt werden, während mehrere Seiten, Datenobjekte und Steuerelemente in verschiedenen Phasen ebenfalls geändert werden. Der wichtige Punkt ist, die aufgeführten Schritte in der richtigen Reihenfolge auszuführen, damit sie während eines Upgrades in der richtigen Reihenfolge durchgeführt werden. Es wird erwartet und ist in Ordnung, während der Durchführung dieser Schritte beliebig viele Änderungen an der logischen Datenquelle oder Anwendung vorzunehmen.

Avoid importing schema

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

  1. Wenn die physische Datenbank in allen Umgebungen außerhalb des App Builders verwaltet und geändert wird, wird das Importieren der Datenquelle während des gesamten Entwicklungszyklus unterstützt.
  2. Wenn die physische Datenbank von Dev/Qa/Prod geteilt wird, wird das Importieren der Datenquelle während des gesamten Entwicklungszyklus unterstützt.

Prerequisites to building a release

Die folgenden Punkte sollten berücksichtigt und abgeschlossen werden, bevor ein App Builder-Release erstellt wird:

  1. Stellen Sie sicher, dass der App Builder-Datenbankbenutzer über Berechtigungen zum Erstellen von Tabellen und Datenbanken in der Umgebung verfügt, in die Sie installieren.
  2. Stellen Sie sicher, dass ein Datenbankadministrator ein Datenbank-Backup sowohl der App Builder-Datenbank als auch jeder Datenbank, die physische und/oder Schemaänderungen unterliegt, durchführt.
  3. Stellen Sie sicher, dass das Umgebungs-Paket, das installiert werden soll, auf der gleichen Version von App Builder läuft, auf der die Quellumgebung läuft.

Schritte zur Durchführung des Release-Managements

  1. Überprüfen Sie die Funktionalität der App Builder-Anwendung gemäß den Standards Ihres Unternehmens für Tests.
  2. Erstellen Sie eine Liste aller angehängten Datenquellen für die Anwendung, für die Sie ein Release erstellen. Diese Informationen sind im App Builder IDE verfügbar. Erstellen Sie Ihre Anwendung, klicken Sie auf Ihre Anwendung 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 gefördert 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 Konfiguration der Vorlage für Datenquellen. Setzen Sie Logisch und Physisch nur für Datenquellen, für die Sie Schemaänderungen mit App Builder verwalten werden.
  6. Überprüfen und bestätigen Sie alle offenen Schritte zur Verwaltung von Datenbankänderungen für Datenbanken, die als Logisch und Physisch Installieren gekennzeichnet sind.
  7. Konfigurieren Sie die Datenkonfiguration für Tabellen in Datenbanken, die für Logisch und Physisch Installieren gekennzeichnet sind.
  8. Sobald die Datenkonfiguration abgeschlossen ist, bestätigen Sie die Datenkonfiguration.
  9. Erstellen Sie das Release. Für detaillierte Anweisungen zum Erstellen eines Releases innerhalb des App Builders selbst, siehe den Artikel Ein Release erstellen.