So erstellen Sie ein Release-Paket im Jitterbit App Builder

Auf dieser Seite erfahren Sie, wie Sie ein Release-Paket erstellen, also eine ausgewählte Sammlung von Anwendungen, Datenquellen und anderen Komponenten, die für die Bereitstellung zusammengestellt werden. Dieser Prozess wird verwendet, wenn eine Anwendung von einer Umfeld in eine andere verschoben wird, z. B. wenn eine Anwendung von einer Entwicklungsumgebung in eine QA-Umgebung und von dort in eine Produktionsumgebung verschoben wird.

Erstellen einer Version

Das Erstellen einer Version in einem Paket und die anschließende Installation eines Pakets in einer neuen Umfeld erfolgt im Bereich Bereitstellen. Auf diesen Bereich können Sie über das App Builder IDE. Während dieses Vorgangs bewegen Sie sich von der linken Seite des Release Template Builder-Bildschirms zur rechten Seite, während Sie alle hier beschriebenen Schritte durchlaufen:

1. Wählen Sie Aktionsschublade > IDE.

2. Wählen Sie Bereitstellen > Release erstellen.

3. Um einen Build zu starten, können Sie entweder eine vorhandene Vorlage auswählen (wenn Sie ein vorhandenes App-Upgrade aktualisieren) oder auf + Release klicken, um eine neue Vorlage zu erstellen.

4. Wenn Sie eine vorhandene Vorlage verwenden, klicken Sie auf die Schaltfläche Vorlage für den vorhandenen Vorlagendatensatz.

5. Aktualisieren Sie die Felder Name, Version und Entwickler auf dem Bildschirm Releasedetails, um den Build widerzuspiegeln, den Sie erstellen:

   

6. Klicken Sie auf die Schaltfläche Weiter.

7. Wählen Sie auf dem Bildschirm Lösungsobjekte aus, was in das Release-Paket aufgenommen wird. Die Optionen sind wie folgt:

   • Anwendung
   • Assembly
   • Bundle
   • Sammlung
   • Datenquelle
   • Funktion
   • Logischer Datentyp
   • Seite
   • Regel
   • SQL-Objekt
   • Widget

   Um eines davon hinzuzufügen, klicken Sie auf die Schaltfläche + Objekt, wählen Sie den Typ aus dem Menü aus und klicken Sie dann auf die Schaltfläche Speichern:

   

   Hinweise

   Die folgenden Punkte gelten für Release-Pakete:

   • Wenn Sie ein Anwendungsobjekt hinzufügen, werden das Bundle und die Datenquelle der Anwendung automatisch zum Release-Paket hinzugefügt.

   • Das Release-Paket enthält keine Instanzgruppen, Instanzsicherheitsanbieter oder Serveranmeldeinformationen.

   • Neu unterstützte Objekte (wie Funktionen und logische Datentypen) werden nicht automatisch zu bereits vorhandenen Vorlagen hinzugefügt. Sie müssen sie selbst hinzufügen.

8. Klicken Sie auf die Schaltfläche Weiter.

9. Der Bildschirm Datenquellen konfigurieren listet alle für den Release-Build relevanten Datenquellen auf. (Wenn keine Datenquellen vorhanden sind, wird dieser Schritt übersprungen.) Überprüfen Sie für jede aufgeführte Datenquelle die Spalte Einschließen und stellen Sie sicher, dass sie für den Build wie gewünscht eingestellt ist. Abhängig vom Datenquellentyp sind die folgenden Optionen verfügbar:

   • Nur logisches Modell: Verwenden Sie diese Option, wenn Sie nur die Daten verpacken möchten, die erstellt wurden und in vorhanden sind App Builder selbst. Beispiele: Daten- und Geschäftsobjekte, Unterabfragen, CRUDs, Workflow, Brücken. Diese Option wird im Allgemeinen für Datenquellen verwendet, die Ihnen nicht gehören und/oder die nicht über App Builder (externe Datenquellen, API Datenquellen usw.).

   • Nur physisches Modell: Verwenden Sie diese Option, wenn Sie nur die Tabellen und Spaltenstrukturen der Datenquelle ohne die Daten verpacken möchten.

   • Logisches Modell und physische Tabellen: Verwenden Sie es, wenn Sie alle Daten mitnehmen möchten, die in App Builder selbst sowie die zugrunde liegenden Tabellen- und Spaltenstrukturen der Datenquelle. Hier bezieht sich physisch auf App Builder Wartung oder Aktualisierung der eigentlichen Datenbankebene. Wenn Sie ein physisches Modell verschieben, bedeutet dies, dass alle in der Entwicklung an der Datenbank vorgenommenen Änderungen beim Verschieben des LP auch in der QA/Prod-Datenbank vorgenommen werden. Diese Option wird im Allgemeinen für von Ihnen verwaltete Datenquellen verwendet.

   • Nicht einschließen: Verwenden Sie diese Option, wenn Sie diese Datenquelle nicht in diese Version einschließen möchten.

   Wichtig

   Wenn Sie Datenbankänderungen haben, die festgeschrieben werden müssen, sollten Sie Logische und Physische für diese Datenbank verschieben. Der Release-Management-Prozess unterstützt das Importieren von Tabellen. Wenn Sie Tabellen in eine Datenquelle importieren, werden diese importierten Tabellen im Zielsystem erstellt, wenn sie Teil des ersten physischen Änderungssatzes sind.

10. Klicken Sie auf die Schaltfläche Weiter.

11. Wenn Ihre App Übersetzungen enthält, wird der Bildschirm Lösungspakete angezeigt. Wenn nicht, wird der Bildschirm Versionshinweise mit Übersichtsinformationen zum Versionspaket angezeigt:

    

    • Name: Der Name Ihrer Anwendung.

    • Version: Die Versionsnummer des erstellten Pakets.

    • Veröffentlichungsdatum: Das Datum, an dem die Veröffentlichung erscheinen soll (dies ist ein vorläufiges Datum und kann vom tatsächlichen Veröffentlichungsdatum abweichen).

    • Erstellungsdatum: Das Datum, an dem Sie das Paket festgeschrieben haben.

    • Veröffentlichungsdatum: Das Datum, an dem Sie das Paket veröffentlicht haben.

    • Vorlagenbeschreibung: Eine Textbeschreibung der Funktion Ihrer App oder Suite.

12. Klicken Sie auf die Schaltfläche Weiter.

13. Überprüfen Sie die Informationen auf dem Bildschirm Veröffentlichen und klicken Sie dann auf die Schaltfläche Fertig.

    Sie sollten jetzt wieder auf dem Bildschirm Release Template Builder sein und in der Spalte Bereit ein grünes Häkchen sehen.

14. Klicken Sie auf die Schaltfläche Datenbankänderungen. Wenn in der Spalte DB auf dem Bildschirm Release Template Builder ein rotes Häkchen erscheint, wissen Sie, dass Sie unbestätigte Änderungen überprüfen und bestätigen müssen. Der Bildschirm Änderungsmanagementanforderungen listet alle datenquellenbezogenen Änderungen auf, die Teil des Pakets sein werden. Wenn Sie Änderungen mit einem roten Häkchen in der Spalte Status sehen, müssen Sie diese manuell anklicken, um sie zu überprüfen und zu genehmigen.

    Wenn Sie auf „Überprüfen“ klicken, gelangen Sie zum Bildschirm „Anforderung zur Änderungsverwaltung“. Hier wird das Feld „Patchnummer“ automatisch mit einem Wert ausgefüllt und gibt an, welche Iteration dieses Paketupdate widerspiegelt. Überprüfen Sie unbedingt alle Einträge im Bereich „Änderungen“, um sicherzustellen, dass diese Informationen Ihren Erwartungen entsprechen und mit dem Paket verschoben werden. Auf diesem Bildschirm müssen Sie Folgendes eingeben:

    • Referenznummer: Dies kann den Patchnummernwert widerspiegeln, eine JIRA- oder AHA-Ticketreferenz sein oder einen Clientnummerierungswert verwenden.

    • Kurzbeschreibung: Geben Sie eine Textbeschreibung des Pakets ein. Geben Sie bei Bedarf zusätzliche Informationen im Feld Kommentare ein.

15. Klicken Sie auf die Schaltfläche Speichern und, wenn Sie bereit sind, fortzufahren, auf die Schaltfläche Diese Anfrage schließen.

16. Schließen Sie die verbleibenden Bildschirme, sodass Sie den Bildschirm Release Template Builder sehen. In der Spalte DB wird nun ein grünes Häkchen angezeigt.

17. Die Datenkonfiguration ist optional und wird nur verwendet, wenn Sie logische und physische Daten mit dem Paket verschieben. Auf dem Bildschirm Datenkonfiguration finden Sie Einzelposten aller Datenquellen, Tabellen für die Datenquelle sowie den zugewiesenen Eigentümertyp und die entsprechende Aktion, die ausgeführt wird, wenn die Tabelle in diese Umfeld verschoben wird. Die verschiedenen Eigentümertypen sind wie folgt:

    • Benutzerdaten: Es werden keine Daten übertragen. Die Benutzer in jeder Umfeld sind für das Auffüllen dieser Tabelle verantwortlich. Beispiel: Kunden oder Bestellungen, bei denen es sich um Transaktionstabellen handelt.

    • Daten teilen: Fügt die neuen Datensätze nur in die nächste Umfeld ein. Beispiel:** Email-Vorlagen**, eine Tabelle, an der der Benutzer Änderungen vornehmen soll.

    • Entwicklerdaten: Kürzt die Tabelle in QA und fügt alle Datensätze aus dem Paket ein. Dies wird normalerweise immer dann verwendet, wenn Sie Nachschlagetabellen oder Tabellen haben, die Teil einer Konfiguration sind. Beispiel: CustomerType, EmployeeType.

18. Informationen für Eigentümertypen können manuell überschrieben und für das jeweilige Paket festgelegt werden, oder Sie klicken einfach auf Konfiguration bestätigen. Dadurch wird dieser Vorgang als abgeschlossen markiert und Sie kehren zum Bildschirm Release Template Builder zurück. Beachten Sie, dass die Jitterbit-Methode es als Best Practice empfiehlt, den Wert Installationsoption immer auf Tabellenebene festzulegen, der dem Eigentümertyp im Bildschirm Release Template Builder zugeordnet ist. Installationsoptionen sind Benutzerdaten, Freigabedaten und Entwicklerdaten. Wenn die Werte auf Tabellenebene festgelegt werden, werden diese Einstellungen auf das Release-Paket übertragen. Das Festlegen dieser Informationen auf Tabellenebene ist bei Projekten mit mehreren Teammitgliedern hilfreich.

19. Im Bereich SQL-Konfiguration können Sie die Datenbank auswählen und prüfen, ob auf der nativen SQL-Ebene Objekte (Ansichten oder gespeicherte Prozeduren) in der Datenbank gespeichert sind. Dadurch können Sie Ansichten oder gespeicherte Prozeduren verschieben. Diese Informationen werden auf dem resultierenden Code-Bildschirm nicht automatisch angezeigt. Sie müssen manuell auf die Schaltfläche Erstellen klicken und sie hinzufügen. Dieser Schritt wird normalerweise nur in fortgeschrittenen Situationen verwendet und ist kein obligatorischer Schritt.

20. Der Schritt Erstellen zeigt die Version für diese Version an und ermöglicht Ihnen, Anmerkungen hinzuzufügen, die speziell auf diese Version zugeschnitten sind. Wenn Sie Ihre Versionshinweise strukturieren, sollten Sie ein Format wie im folgenden Screenshot verwenden. Es ist wichtig, dass Sie im Laufe der Zeit einen konsistenten Prozess für die Benennung Ihrer Versionshinweise befolgen, insbesondere wenn an Ihrem Projekt mehrere Personen arbeiten. Dies wird zu einem laufenden Protokoll der App-Versionshinweise.

21. Klicken Sie auf die Schaltfläche Paket erstellen, wodurch ein Hintergrundjob gestartet wird, der das Paket erstellt. Es gibt keine Benachrichtigung, die Sie darüber informiert, wenn das Paket fertig ist und/oder fehlschlägt. Um den Prozessstatus zu überprüfen, müssen Sie zu App Builder IDE, Server und Zeitpläne verwalten und das Fenster „Ausgeführte Instanzjobs“ überprüfen.

22. Die Schaltfläche Zurücksetzen löscht alle mit der Paketvorlage verknüpften Informationen und ermöglicht Ihnen, bei der Erstellung Ihres Pakets von vorne zu beginnen.

23. Klicken Sie auf Symbol Pakete, das Sie zum Bildschirm „Lösungsfreigaben“ bringt, auf dem die herunterladbare LP-Datei für die nächste Umfeld erstellt wurde. Dies ist die Datei, die Sie zur Installation in der nächsten Umfeld benötigen. Laden Sie von diesem Bildschirm die Paketdatei herunter und speichern Sie sie lokal auf Ihrem Computer.

24. Wenn die LP-Datei verfügbar ist, wechseln Sie zu Ihrer nächsten Umfeld, in der Sie sie installieren werden (QA oder Prod). Von dort aus gehen Sie zu Bereitstellen Ihrer Anwendung vom App Builder IDE und klicken Sie auf die Schaltfläche Release installieren.

    Tipp

    Um den Inhalt des Pakets vor der Installation anzuzeigen, klicken Sie auf das Schaltfläche Manifest.

25. Klicken Sie auf die Schaltfläche Erstellen und Durchsuchen, um die Paketdatei zu finden, und klicken Sie auf Speichern. Nach dem Speichern wird im Lösungsbereich auf der rechten Seite die Paketinformationen zu Name, Version, Entwickler, Veröffentlichungsdatum, Beschreibung und Versionshinweisen angezeigt.

26. Klicken Sie auf die Schaltfläche Installieren, nachdem Sie bestätigt haben, dass dies das Paket ist, das Sie installieren möchten. Dieser Vorgang wird im Vordergrund ausgeführt. Wenn er erfolgreich ist, erhalten Sie eine Erfolgsmeldung. Wenn er fehlschlägt, gehen Sie zu Protokolle > App Server Fast Logs und Sie sehen spezifische Fehlerinformationen, warum die Installation fehlgeschlagen ist.

Zeitpläne und Release-Pakete

Zeitpläne werden in ein Release-Paket (oder LP) aufgenommen, sofern sie beim Erstellen des Pakets nicht manuell entfernt werden. Zeitpläne, die in einer Umfeld bereitgestellt wurden, sind standardmäßig „versiegelt“ oder daran gehindert, bestimmte Änderungen an den Zeitplaninformationen vorzunehmen. Dies verhindert, dass jemand versehentlich Entwicklungsänderungen in einer nachlegende Umfeld vornimmt, was zu verschiedenen Problemen führen könnte, wenn versucht wird, die App in Zukunft einsetzen. Zeitpläne sind Teil einer Anwendung und daher in diesen nachlegende Umgebungen „versiegelt“. Sie können Zeitpläne ein- oder ausschalten oder die Zeit anpassen, aber Sie können den Ausführungstyp eines Zeitplans nicht ändern.

Es gibt einige Szenarien, in denen Sie möglicherweise einen Zeitplan in der Entwicklung einrichten, der Entwicklungszeitplan in der Produktion jedoch deaktiviert wird. Beispiel: Interaktion mit einer API. Möglicherweise möchten Sie nur aus der Umfeld mit einer API interagieren. Sobald die Entwicklung abgeschlossen ist, können Sie den Zeitplan in der Umfeld deaktivieren.

Beachten Sie, dass nach dem Hinzufügen eines Zeitplans zu einem LP nicht alle Zeitplanänderungen in zukünftige Builds eines Pakets übernommen werden. Wenn Sie mit einem Zeitplan verknüpfte Ereignisse hinzufügen oder entfernen, werden diese Änderungen in einem neuen Build berücksichtigt. Andere Änderungen an einer Zeitplandefinition werden nicht in zukünftige Builds übernommen.

Um Änderungen an einem versiegelten Produktionsplan vorzunehmen, können Sie einen neuen Plan erstellen, der dann in den nächsten LP aufgenommen wird. Dieser Prozess stellt sicher, dass der Plan korrekt erstellt wird und alle neuen Einstellungen in den nachlegende Umgebungen berücksichtigt werden.