Nachfolgend wird beschrieben, wie ein Update von der Test-Umgebung in die Produktiv-Umgebung vereinfacht eingespielt werden kann.

Für die Test-Umgebung wird nachfolgend die Bezeichnung STAGING verwendet, für die Produktiv-Umgebung PRODUCTION.

Vorwort

Diese Anleitung dient alternativ zu Patches einspielen für eine Vereinfachung des Update-Vorgehens und ist insbesondere bei der Übernahme eines Updates aus der Test-Umgebung in die Produktiv-Umgebung geeignet.
Für das Einspielen von Patches von oxaion in die Test-Umgebung hingegen ist sie nicht geeignet und stattdessen Patches einspielen anzuwenden!

Grundsätzlich gilt als Patch jede neue Version von oxaion im Rolling Release.
Ein solcher Patch wird in Kundeninstallationen stets zuerst in STAGING (ggf. DEVELOP) übernommen und dort ausführlich getestet. Mit der Freigabe des Patches werden die Änderungen nach PRODUCTION übernommen.

Unabhängig von der Standard-Weiterentwicklung und parallel dazu werden in STAGING auch Kundenmodifikationen entwickelt und getestet. Nach deren Freigabe werden sie ebenfalls nach PRODUCTION übernommen.
Bei der Übernahme von STAGING nach PRODUCTION gelten daher zumeist folgende beiden Annahmen

  1. der Merge der Sourcen von STAGING nach PRODUCTION läuft konfliktfrei und bedarf daher keiner manuellen Eingriffe
  2. die im Update enthaltenen Änderungen sind in STAGING bereits getestet und freigegeben, sodass das Update in PRODUCTION automatisch ablaufen kann

Sind beide Annahmen erfüllt, kann das Update der PRODUCTION wie nachfolgend beschrieben in einigen wenigen Schritten und nahezu ohne manuellen Aufwand erfolgen.

Durchführung

Voraussetzungen

Merge über Bitbucket

Für das Einspielen von Updates in PRODUCTION wird nach dieser Anleitung keine IDE benötigt.
Stattdessen ist der Zugriff auf Bitbucket erforderlich, um das Mischen in der Versionskontrolle durchzuführen.

automatische Aktualisierung

Die Aktualisierung erfolgt automatisch durch Neustart des Applikation-Servers. Dafür ist eine spezielle Konfiguration erforderlich, die im Rahmen der Installation vorzunehmen ist.

In den credentials.properties ist der zusätzliche Parameter StartupUpdate zu hinterlegen → /data/conf/credentials.properties

#beim Start automatisch die Metadaten aktualisieren
StartupUpdate=true


Ist diese Konfiguration noch nicht enthalten, ist der Parameter vor der Übernahme des Updates einzufügen.
Damit die neue Einstellung aktiviert wird, ist anschließend configureServer über das Installations-Skript install-oxaion.sh aufzurufen, sodass die server.xml mit dem neuen StartupUpdate aktualisiert wird.

Alternativ zum configureServer kann die server.xml auch manuell um folgenden Eintrag erweitert werden. Der Eintrag muss vor den anderen event-listenern eingefügt werden.

<!-- Beim Starten des PRODUCTION-Server automatisch die Datenbank und Metadaten aktualisieren -->

<event listener="com.oxaion.open.StartupUpdate" on="STARTUP"/>

Der Neustart wird später über einen Job im Applikation-Server ausgeführt. Dafür ist Zugang über den oxaion open Client erforderlich.

Mischen der Aktualisierungen in den PRODUCTION-Zweig

Zum Mischen des STAGING-Zweiges in den PRODUCTION-Zweig wird Bitbucket genutzt und der Merge über einen Pull-Request durchgeführt.
Dazu wird Bitbucket im Browser geöffnet und das gewünschte Projekt ausgewählt →  http://bitbucket.oxaion.de/projects/OPEN/repos/application-server-oxaion/browse

Anschließend wird ein neuer Pull-Request erstellt. Dazu in der Navigation links wählen und betätigen. 

Für den Pull-Request werden Quell und Ziel angegeben:
Quelle ist, woher das Update kommt → STAGING
und Ziel ist, wohin das Update geht → PRODUCTION

Bitbucket zeigt zur besseren Orientierung die aktuellen Commits je Zweig an sowie alle Commits, die in der Quelle vorhanden sind, aber im Ziel noch fehlen.
Somit erhält man schnell einen guten Überblick, welche Änderungen von STAGING nach PRODUCTION übernommen werden.

Mit öffnet sich die Detail-Ansicht zum Pull-Request (=PR). Es kann eine Überschrift und eine Beschreibung angegeben sowie die Prüfung des PR veranlasst werden.
Mit wird der PR angelegt und auf einem automatischen Branch gepusht.
Dadurch startet gleichzeitig auch die Push-Verarbeitung (Build auf dem oxaion Jenkins) und Bitbucket prüft die Möglichkeit der automatischen Übernahme.


In der PR-Übersicht wird der Merge des PR über die Navigation rechts oben angestoßen:


Für den Merge wird eine Commit-Nachricht der Form "[VERSION]: Merge STAGING nach PRODUCTION" angegeben,
die Art des Merges wird ausgewählt, bspw. , und der Merge durch Bestätigen von ausgeführt. 



automatischer Merge

Treten beim Merge Konflikte auf, die Bitbucket nicht automatisch lösen kann, ist der Merge über Bitbucket nicht möglich,
sondern muss manuell über eine oxaion open IDE erfolgen, siehe auch Patches einspielen, Kapitel Mischen der Aktualisierungen.

Bitbucket stellt Konflikte oder andere Probleme, die einen automatischen Merge verhindern, bspw. wie folgt dar:

Erfolgt der Merge über die IDE, kann dennoch anschließend der Neustart inkl. automatischer Aktualisierung wie unten beschrieben durchgeführt werden.


Der erfolgreiche Merge erstellt einen Commit auf dem Ziel-Zweig PRODUCTION und startet automatisch den Build-Prozess auf dem oxaion Jenkins.
Der Status des Builds ist in der Commit-Historie zum Git-Projekt im Bitbucket einsehbar:

Legende:
Build wird noch ausgeführt
Build ist abgeschlossen  


Sobald der Build-Prozess erfolgreich abgeschlossen ist, steht auf dem Nexus eine neue Version für den AppServer zur Verfügung.
Durch Neustart mit Aktualisierung wird der AppServer auf die neue Version angehoben sowie automatisch das Update der Datenbank analog den Schritten in Patches einspielen ausgeführt,
vgl. Server-Neustart und automatische Aktualisierung.

Server-Neustart und automatische Aktualisierung

Ist der Build-Prozess erfolgreich abgeschlossen, steht auf dem Nexus die neue Version für den Applikation-Server zur Verfügung.
Zur Aktualisierung des Applikation-Servers sowie der Datenbank wird anschließend ein Neustart angestoßen.

Der Neustart erfolgt durch Ausführen des Jobs *TASK-Update-Restart in Jobs planen (US00310) →
Dafür kann der Client zum Applikation-Server verwendet werden oder alternativ auch der Client aus der IDE heraus.
Wird der IDE-Client verwendet, ist darauf zu achten, dass der Job nicht lokal, sondern auf dem Applikation-Server (SRV01) ausgeführt wird.

Der Neustart samt Aktualisierung kann einige Zeit in Anspruch nehmen.
Der Fortschritt ist insbesondere über die console.log unterhalb dem Log-Verzeichnis des Servers einsehbar.

Der Vorgang umfasst:

  • Download der aktuellen Version des AppServers
  • Installation der aktuellen Version des AppServers
  • Neustart des AppServer-Prozesses
  • Aktualisierung der Datenbank inkl. (und analog zu den Schritten aus Patches einspielen automatisch)
    • Aktualisierung der Datenbank-Tabellen, inkl. Indizes und Views
    • Aktualisierung der Referenzfelder
    • Aktualisierung der Metadaten

Sobald der Applikation-Server erfolgreich aktualisiert und gestartet ist, werden die manuellen Nacharbeiten durchgeführt, siehe Release Notes.

Sind keine Release Notes zu beachten, kann der Neustart samt Aktualisierung auch ohne manuellen Anstoß automatisch in der Nacht erfolgen.
Standardmäßig wird dafür der Jobs *TASK-Update-Restart mit täglicher Ausführung um 01:01 Uhr ausgeliefert.
Die Konfiguration des Jobs erfolgt nach Bedarf entsprechend der Kundenumgebung.

Release Notes

Nicht automatisch erfolgt die Umsetzung der in den Release Notes manuell zu tätigen Anpassungen.
Diese sind nach dem erfolgreichen Neustart (inkl. Aktualisierung) abzuarbeiten.


  • Keine Stichwörter