So erstellen Sie ein Release-Paket in Jitterbit App Builder

Einführung

Diese Seite zeigt Ihnen, wie Sie ein Release-Paket erstellen, das eine ausgewählte Sammlung von Anwendungen, Datenquellen und anderen Komponenten ist, die zusammen für die Bereitstellung verpackt werden. Dieser Prozess wird verwendet, wenn Sie eine Anwendung von einer Umgebung in eine andere verschieben, z. B. wenn Sie eine Anwendung von der Entwicklungs- in die QA-Umgebung und von dort in die Produktionsumgebung verschieben.

Das folgende Diagramm zeigt, was ein Release enthält.

Ein Release erstellen

Das Erstellen eines Release in ein Paket und die anschließende Installation eines Pakets in einer neuen Umgebung finden beide im Bereich Deploy statt, auf den über die App Builder IDE zugegriffen wird. Während dieses Prozesses bewegen Sie sich von der linken Seite des Bildschirms Release Template Builder zur rechten Seite, während Sie alle hier beschriebenen Schritte durchlaufen:

1. Wählen Sie Action Drawer > IDE.

2. Wählen Sie Deploy > Create Release.

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 Template für den vorhandenen Vorlagendatensatz.

5. Aktualisieren Sie die Felder Name, Version und Developer auf dem Bildschirm Release Details, um den Build widerzuspiegeln, den Sie erstellen:

   

6. Klicken Sie auf die Schaltfläche Next.

7. Auf dem Bildschirm Solution Objects wählen Sie aus, was in das Release-Paket aufgenommen wird. Die Optionen sind wie folgt:

   • Application
   • Assembly
   • Bundle
   • Collection
   • Data Source
   • Function
   • Logical Data Type
   • Page
   • Role
   • Rule
   • SQL Object
   • Widget

   Um eines dieser Elemente hinzuzufügen, klicken Sie auf die Schaltfläche + Object, wählen Sie den Typ aus dem Menü aus und klicken Sie dann auf die Schaltfläche Save:

   

   Hinweise

   Die folgenden Punkte gelten für Release-Pakete:

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

   • Das Release-Paket enthält keine Instance Groups, Instance Security Provider oder Server-Anmeldedaten.

   • Neu unterstützte Objekte (z. B. Functions und Logical Data Types) werden nicht automatisch zu bereits vorhandenen Vorlagen hinzugefügt. Sie müssen sie selbst hinzufügen.

8. Klicken Sie auf die Schaltfläche Next.

9. Der Bildschirm Configure Data Sources listet alle für den Release-Build relevanten Datenquellen auf. (Wenn es keine Datenquellen gibt, wird dieser Schritt übersprungen.) Überprüfen Sie für jede aufgelistete Datenquelle die Spalte Include und stellen Sie sicher, dass sie für den Build wie gewünscht eingestellt ist. Je nach Datenquellentyp sind möglicherweise folgende Optionen verfügbar:

   • Logical Model Only: Verwenden Sie dies, wenn Sie nur die Daten verpacken möchten, die in App Builder selbst erstellt wurden und vorhanden sind. Beispiele: Datenobjekte und Geschäftsobjekte, Unterabfragen, CRUDs, Workflow, Bridges. Diese Option wird in der Regel für Datenquellen verwendet, die Sie nicht besitzen und/oder nicht über App Builder verwaltet werden (externe Datenquellen, API-Datenquellen usw.).

10. Nur physisches Modell: Verwenden Sie diese Option, wenn Sie nur die Datenquelltabellen und Spaltenstrukturen verpacken möchten, ohne die Daten.

    • Logisches Modell und physische Tabellen: Verwenden Sie diese Option, wenn Sie alle in App Builder vorhandenen Daten zusammen mit den zugrunde liegenden Datenquelltabellen und Spaltenstrukturen übernehmen möchten. Hier bezieht sich „physisch" darauf, dass App Builder die tatsächliche Datenbankebene verwaltet oder aktualisiert. Wenn Sie ein physisches Modell verschieben, werden alle Änderungen, die in der Entwicklung an der Datenbank vorgenommen werden, auch in der QA/Prod-Datenbank vorgenommen, wenn Sie das LP verschieben. Diese Option wird in der Regel 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

    Falls Sie Datenbankänderungen durchführen müssen, die committed werden sollten, verschieben Sie Logisch und Physisch für diese Datenbank. Der Release Management-Prozess unterstützt den Import von Tabellen. Wenn Sie Tabellen in eine Datenquelle importieren, werden diese importierten Tabellen im Zielsystem erstellt, wenn sie Teil des ersten physischen Change Sets sind.

11. Klicken Sie auf die Schaltfläche Weiter.

12. Falls Ihre App Übersetzungen enthält, wird das Fenster Solution Bundles angezeigt. Andernfalls wird das Fenster Versionshinweise angezeigt, das Übersichtsinformationen zum Release-Paket enthält:

    

    • Name: Der Name Ihrer Anwendung.

    • Version: Die Versionsnummer des zu erstellenden Pakets.

    • Veröffentlichungsdatum: Das Datum, an dem der Release angezeigt werden soll (dies ist ein flexibles Datum und kann sich vom tatsächlichen Veröffentlichungsdatum unterscheiden).

    • Build-Datum: Das Datum, an dem Sie das Paket committed haben.

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

    • Template-Beschreibung: Eine Textbeschreibung, was Ihre App oder Suite leistet.

13. Klicken Sie auf die Schaltfläche Weiter.

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

    Sie befinden sich jetzt zurück im Fenster Release Template Builder, wobei die Spalte Bereit ein grünes Häkchen enthält.

15. Klicken Sie auf die Schaltfläche Datenbankänderungen, und Sie wissen, dass Sie unbestätigte Änderungen zur Überprüfung und zum Commit haben, wenn ein rotes Häkchen in der Spalte DB auf dem Fenster Release Template Builder angezeigt wird. Das Fenster Change Management Requests listet alle datenquellenbezogenen Änderungen auf, die Teil des Pakets sind. Falls Sie Änderungen mit einem roten Häkchen in der Spalte Status sehen, müssen Sie manuell darauf klicken, um sie zu überprüfen und zu genehmigen.

    Durch Klicken zur Überprüfung gelangen Sie zum Fenster Change Management Request. Das Feld Patch-Nummer wird hier automatisch mit einem Wert ausgefüllt und gibt an, welche Iteration diese Paketaktualisierung widerspiegelt. Überprüfen Sie unbedingt alle Einträge im Bereich Änderungen, um sicherzustellen, dass diese Informationen dem entsprechen, was Sie mit dem Paket verschieben möchten. In diesem Fenster müssen Sie Folgendes eingeben:

    • Referenznummer: Dies kann den Wert der Patch-Nummer widerspiegeln, ein JIRA- oder AHA-Ticket-Verweis sein oder einen Client-Nummernwert verwenden.

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

16. Klicken Sie auf die Schaltfläche Speichern, und falls Sie fortfahren möchten, klicken Sie auf die Schaltfläche Diese Anfrage schließen.

17. Schließen Sie die verbleibenden Fenster, damit Sie das Fenster Release Template Builder angezeigt bekommen. Sie sehen nun ein grünes Häkchen in der Spalte DB.

18. Die Datenkonfiguration ist optional und wird nur verwendet, wenn Sie logische und physische Daten mit dem Paket verschieben. Vom Fenster Datenkonfiguration aus finden Sie Positionen aller Datenquellen und Tabellen für die Datenquelle zusammen mit dem zugewiesenen Eigentümertyp und der entsprechenden Aktion, die stattfindet, wenn die Tabelle in diese Umgebung verschoben wird. Die verschiedenen Eigentümertypen sind wie folgt:

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

19. Daten teilen: Fügt die neuen Datensätze nur in die nächste Umgebung ein. Beispiel: Email Templates, eine Tabelle, die du anpassen möchtest.

20. Entwicklerdaten: Leert die Tabelle in QA und fügt alle Datensätze aus dem Paket ein. Dies wird normalerweise für Nachschlagetabellen oder Tabellen verwendet, die Teil einer Konfiguration sind. Beispiel: CustomerType, EmployeeType.

21. Die Informationen für Owner Types können manuell überschrieben und für das spezifische Paket festgelegt werden, oder du kannst einfach auf Confirm Config klicken. Dies markiert diesen Prozess als abgeschlossen und kehrt zum Bildschirm Release Template Builder zurück. Hinweis: Die Best Practice der Jitterbit-Methodik ist, den Wert Install Option auf Tabellenebene festzulegen, was in der Anzeige Release Template Builder dem Owner Type entspricht. Install Options sind User Data, Share Data und Developer Data. Wenn die Werte auf Tabellenebene festgelegt sind, werden diese Einstellungen auf das Release-Paket übertragen. Das Festlegen dieser Informationen auf Tabellenebene ist hilfreich für Projekte mit mehreren Team-Mitgliedern.

22. Der Bereich SQL Config ermöglicht es dir, die Datenbank auszuwählen und zu prüfen, ob Objekte (Ansichten oder gespeicherte Prozeduren) auf der Datenbank auf der nativen SQL-Ebene gespeichert sind. Dies ermöglicht das Verschieben von Ansichten oder gespeicherten Prozeduren. Diese Informationen werden nicht automatisch auf der resultierenden Anzeige Code angezeigt, und du musst manuell auf die Schaltfläche Create klicken und sie hinzufügen. Dieser Schritt wird normalerweise nur in erweiterten Situationen verwendet und ist kein erforderlicher Schritt.

23. Der Schritt Build zeigt die Version für dieses Release an, ermöglicht dir, Notizen spezifisch zu diesem Release hinzuzufügen, und lässt dich eine Option auswählen, um vor dem Erstellen eine Momentaufnahme zu machen. Wenn du deine Release Notes strukturierst, solltest du ein Format wie im folgenden Screenshot verwenden. Ein konsistentes Vorgehen bei der Benennung deiner Release Notes im Laufe der Zeit ist wichtig, besonders wenn mehrere Personen an deinem Projekt arbeiten. Dies wird zu einem laufenden Protokoll der App-Release-Notizen.

24. Klicke auf die Schaltfläche Build Package, um einen Hintergrund-Job zu starten, der das Paket erstellt. Es gibt keine Benachrichtigung, die dich informiert, wenn das Paket fertig ist und/oder fehlschlägt. Um den Prozessstatus zu überprüfen, gehe zum App Builder IDE, Manage Servers and Schedules und überprüfe das Fenster Instance Running Jobs.

25. Die Schaltfläche Reset würde alle Informationen, die mit der Paketvorlage verbunden sind, löschen und dir ermöglichen, mit einem sauberen Blatt für deinen Paket-Build zu beginnen.

26. Klicke auf das Symbol Packages, das dich zum Bildschirm Solution Releases bringt, auf dem die herunterladbare LP-Datei für die nächste Umgebung bereitgestellt wird. Dies ist die Datei, die du zur Installation in der nächsten Umgebung verwenden wirst. Lade die Paketdatei von diesem Bildschirm herunter und speichere sie lokal auf deinem Computer.

27. Mit der verfügbaren LP-Datei gehe in deine nächste Umgebung, in der du sie installieren wirst (QA oder Prod). Gehe von dort aus zu Deploy your Application im App Builder IDE und klicke auf die Schaltfläche Install Release.

    Tipp

    Um den Inhalt des Pakets vor der Installation anzuzeigen, klicke auf die Schaltfläche Manifest.

28. Klicke auf die Schaltfläche Create und Browse, um die Paketdatei zu suchen und klicke auf Save. Nach dem Speichern wird das Fenster Solution auf der rechten Seite die Paketinformationen mit Name, Version, Developer, Release Date, Description und Release Notes anzeigen.

29. Klicke auf die Schaltfläche Install, nachdem du bestätigt hast, dass dies das Paket ist, das du installieren möchtest. Dieser Prozess läuft im Vordergrund. Bei Erfolg erhältst du eine Erfolgsmeldung. Bei Fehlschlag gehe zu Logs > App Server Fast Logs und du siehst spezifische Fehlerinformationen darüber, warum die Installation fehlgeschlagen ist.

Zeitpläne und Release-Pakete

Zeitpläne werden in ein Release-Paket (oder LP) aufgenommen, es sei denn, sie werden beim Erstellen des Pakets manuell entfernt. Standardmäßig sind Zeitpläne, die in einer Produktionsumgebung bereitgestellt wurden, „versiegelt" oder daran gehindert, bestimmte Änderungen an den Zeitplaninformationen vorzunehmen. Dies verhindert, dass jemand versehentlich Entwicklungsänderungen in einer nachgelagerten Umgebung vornimmt, was zu verschiedenen Problemen führen könnte, wenn versucht wird, die App in der Zukunft bereitzustellen. Zeitpläne sind Teil einer Anwendung, daher sind sie in diesen nachgelagerten Umgebungen „versiegelt". Du kannst Zeitpläne ein- oder ausschalten oder die Zeit anpassen, aber du kannst den Ausführungstyp eines Zeitplans nicht ändern.

Es gibt einige Szenarien, in denen man einen Schedule in der Entwicklungsumgebung einrichtet, aber in der Produktionsumgebung den Dev-Schedule deaktiviert. Beispielsweise bei der Interaktion mit einer API. Man möchte die API möglicherweise nur aus der Produktionsumgebung aufrufen, sodass man den Schedule in der Entwicklungsumgebung deaktivieren kann, sobald die Entwicklung abgeschlossen ist.

Nachdem ein Schedule zu einem LP hinzugefügt wurde, beachten Sie, dass nicht alle Schedule-Änderungen in zukünftigen Builds eines Pakets übertragen werden. Wenn man Events hinzufügt oder entfernt, die einem Schedule zugeordnet sind, werden diese Änderungen in einem neuen Build berücksichtigt. Andere Änderungen an einer Schedule-Definition werden nicht in zukünftige Builds übertragen.

Um Änderungen an einem versiegelten Production-Schedule vorzunehmen, kann man einen neuen Schedule erstellen, der dann in das nächste LP aufgenommen wird. Dieser Prozess stellt sicher, dass der Schedule korrekt mit allen neuen Einstellungen erstellt wird, die in den nachgelagerten Umgebungen berücksichtigt werden.