Release-Management im Jitterbit App Builder

Dieser Artikel führt durch bewährte Methoden, Voraussetzungen für die Erstellung eines Releases und Schritte für das allgemeine Release-Management in App Builder. Detaillierte Anweisungen zum Aufbau des App Builder Freigabe innerhalb App Builder selbst, siehe Eine Version 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, wenn die Datenbank ausgeliefert wird. Daher sollte der Entwickler Änderungen an der Umfeld auf die gleiche Weise vornehmen, wie er es in der Qualitätssicherung und in der Produktion erwarten würde. Es gibt zwei Arten von Änderungen, die App Builder erfasst in der Entwicklung und gilt bei einem Upgrade von QA und PROD:

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 Erstellen/Aktualisieren/Löschen-Regel 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

Auslieferung nur einer Anwendung oder nur einer Datenquelle

Obwohl es möglich ist, eine einzelne Anwendung oder eine einzelne 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. Im Allgemeinen ist es am besten, alle abhängigen Objekte einzuschließen, 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 eingeschlossen 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. Wenn der Entwickler versucht, Datenquelle A an QA zu senden, ist das Upgrade erfolgreich. Das Datenobjekt enthält eine neue Spalte, die jedoch nicht von der Anwendung verwendet wird. Wenn der Entwickler jedoch Anwendung X an QA gesendet hat, ohne Datenquelle A in seine Lösung aufzunehmen, schlägt das Upgrade fehl. Während des Upgrades der Anwendung App Builder Wir versuchen, das neue Steuerelement hinzuzufügen, aber die Spalte, an die es gebunden ist, existiert in der aktuellen Datenquelle in QA nicht und kann daher nicht hinzugefügt werden.

Mehrere Anwendungen verwenden die gleiche Datenquelle

Angenommen, Anwendung X und Anwendung Y verweisen beide auf Datenquelle A. Ein Team arbeitet an Anwendung X und ein anderes Team an Anwendung Y. Beide Teams haben Datenobjekten in Datenquelle A Spalten hinzugefügt und beide Teams haben Steuerelemente zu Anwendungen X und Y 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, und daher kann die Spalte beim Upgrade nicht entfernt werden. Um sicherzustellen, dass das Upgrade erfolgreich ist, sollten Sie alle Anwendungen und Datenquellen einschließen, auf die in der Lösung verwiesen wird.

Hinzufügen einer Spalte ungleich Null

Machen Sie sich Migrationsregeln zunutze. Angenommen, eine Tabelle „Mitarbeiter“ wurde an QA und PROD gesendet und mit Produktionsdaten gefüllt. Ein Entwickler entfernt dann alle Zeilen aus dieser Tabelle, um eine Spalte mit dem Wert NON NULL hinzuzufügen (Active Boolean Allow Nulls = False). Dieser Operation ist in der Umfeld erfolgreich, da keine Mitarbeiterdatensätze vorhanden sind. Wenn dieser Änderungssatz jedoch in QA oder PROD angewendet wird, schlägt er fehl. Eine RDMBs-Datenbank lässt nicht zu, dass einer Tabelle, die Zeilen enthält, eine Spalte mit dem Wert NULL hinzugefügt wird.

Löschen Sie stattdessen in der Umfeld die Mitarbeiterdatensätze nicht. Lassen Sie sie, damit die Umfeld repräsentativ für die Zielumgebungen QA und PROD ist. Fügen Sie der Tabelle „Employee“ die neue Spalte hinzu, lassen Sie jedoch Nullwerte zu (Active Boolean Allow Nulls = True). Erstellen Sie eine Migrationsregel, die den Wert von Employee.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 bei der Übermittlung an QA und PROD erfolgreich sein. App Builder führt während des Upgrades die folgenden Schritte aus:

1. Aktiv zur Mitarbeitertabelle hinzufügen Nullen zulassen = Wahr
2. Alle Mitarbeiterzeilen aktualisieren, sodass Aktiv = Wahr/Falsch ist
3. Die Spalte Aktiv so ändern, dass Nullen zulassen = Falsch ist

Ändern des Primärschlüssels einer Tabelle

Seien Sie vorsichtig, wenn Sie einen Primärschlüssel in einer Tabelle ändern, die bereits an die Qualitätssicherung gesendet wurde und Daten enthält. Auch hier sollten Sie sicherstellen, dass die Umfeld Daten in der Tabelle enthält, damit sie die Qualitätssicherungs- und Produktionsumgebungen optimal repräsentiert. Es gibt mehrere Möglichkeiten, wie sich ein Primärschlüssel ändern kann. Im Folgenden finden Sie ein Beispiel:

Angenommen, Employee hat eine Spalte EmployeeId Integer Primary Key. Nehmen Sie außerdem an, dass EmployeeAccrual eine Spalte EmployeeId Integer hat (Fremdschlüssel verweist auf Employee.EmployeeId). Die Employee-Tabelle hat 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 wird diese Schritte aufzeichnen und sie beim Upgrade von QA und Prod erfolgreich ausführen.

Vermeiden Sie den Import von Schema

Wenn die Absicht besteht, eine physische Datenbank von Dev zu Qa zu Prod zu verschieben und diese physische Datenbank durch die App Builder UI und senden Sie diese Änderungen an QA und Prod, dann verwenden Sie nicht die Importfunktion für App Builder Datenquellen. Um Änderungen in der Entwicklung voranzutreiben, App Builder erfasst diese Änderungen, sobald sie über die Benutzeroberfläche vorgenommen werden. Beim Importieren einer Datenquelle wird die App Builder UI, Synchronisation der App Builder logisches Modell, das mit dem physischen Modell der importierten Datenquelle übereinstimmt. Daher würden bei einem Upgrade keine Änderungen an der importierten Datenquelle weitergegeben. Es gibt Situationen, in denen der Import mit Release Management unterstützt wird:

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

Voraussetzungen zum Erstellen einer Version

Die folgenden Punkte sollten vor dem Bau berücksichtigt und erledigt werden an App Builder Freigabe:

1. Stellen Sie sicher, dass die App Builder Der db-Benutzer verfügt über Berechtigungen zum Erstellen von Tabellen und Datenbanken in der Umfeld, in der Sie die Installation durchführen.
2. Stellen Sie sicher, dass ein Datenbankadministrator eine Datenbanksicherung der App Builder Datenbank und alle Datenbanken, bei denen physische und/oder Schema vorgenommen werden.
3. Stellen Sie sicher, dass das zu installierende Umfeld auf derselben Version läuft wie App Builder auf der die Umfeld ausgeführt wird.

Schritte zum Release-Management

1. Überprüfen Sie anhand der Teststandards Ihres Unternehmens die Funktionalität des App Builder Anwendung.
2. Erstellen Sie eine Liste aller angehängten Datenquellen für die Anwendung, für die Sie eine Version erstellen. Diese Informationen sind verfügbar unter App Builder IDE: Erstellen Sie Ihre Anwendung, klicken Sie auf Ihre Anwendung und überprüfen Sie das resultierende Datenquellenfenster.
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 verwalten möchten. App Builder.
6. Überprüfen und bestätigen Sie alle offenen Schritte zur Datenbankänderungsverwaltung für Datenbanken, die als Logische und Physische Installation markiert sind.
7. Konfigurieren Sie die Datenkonfiguration für Tabellen in Datenbanken, die für Logische und Physische Installation markiert sind.
8. Sobald die Datenkonfiguration abgeschlossen ist, bestätigen Sie die Datenkonfiguration.
9. Erstellen Sie die Version. Detaillierte Anweisungen zum Erstellen einer Version innerhalb App Builder selbst, siehe Eine Version erstellen Artikel.