Seit dem oxaion open Release 5.1 stellt oxaion ausschließlich kumulative Patches bereit.

PTRs und PKs suchen

In den Release-Notes werden Hinweise zu manuellen Vor- und Nacharbeiten dokumentiert.

Die vollständige Liste aller Änderungen findet sich hier. Hier ist auch dokumentiert, welche PTRs bearbeitet wurden.

Patch einspielen

Grundlagen / Vorraussetzungen

Wie gelangt aktueller Code von oxaion zum Kunden?

Folgende Grafik soll den Fluss von akuellem Code zum Kunden verdeutlichen:

Hierbei ist ersichtlich dass, ein im für alle Kunden öffentlichen open GIT-Repository (application-server-public), markierter (getagged-ter) Stand automatisiert in den jeweiligen Release-Zweig (Branch) synchronisert wird. Im Beispiel ist hier der oxaion/5.1.x Zweig dargestellt.

Des weiteren ist zu sehen dass die aktualisierten Quellen von diesem Zweig (z.B. oxaion/5.1.x) aus in den jeweiligen stg-Zweig (stg/5.1.x = Staging Zweig des Releases 5.1) gemischt (gemerged) werden.

Vom stg-Zweig aus wird dann weiter in den prd-Zweig (prd/5.1.x = Produktiv-Zweig des Releases 5.1) gemischt, welcher die Quellen für die Produktions/Produktiv-Umgebung enthält.

In Umgebungen in denen eine weitere Stufe notwendig ist (auf Kundenwunsch) wird diese in Form eines develop Zweiges vorgeschalten und nach einer erfolgreichen Aktualisierung (=Patch) durch Mischen der Quellen aus dem prd-Zweig aktualisiert.

Voraussetzungen

prozesstechnische Voraussetzungen

Für die Durchführung einer Aktualisierung des oxaion Systems muss vor Beginn geklärt worden sein auf welchen Patch Stand (z.B. r5.1.1.11) aktualisiert werden soll.

Es können dabei mehrere Patches übersprungen werden. (nicht aber die Abarbeitung aller Release Notes!)

technische Voraussetzungen

Für die Durchführung einer Aktualisierung des oxaion Systems wird auf technischer Seite eine zum jeweiligen Release (hier 5.1) passende oxaion open IDE benötigt.

Diese muss sich auf dem entsprechenden stg-Zweig (hier stg/5.1.x) befinden und mittels Knopf aktualisiert worden sein.

Die Problem-Anzeige der IDE darf ausschließlich Warnungen, aber keinerlei Fehler enthalten vor dem Beginn des Patch-Prozesses:

personelle Voraussetzungen

Um eine Aktualisierung des oxaion open System durchzuführen sollte die durchführende Person:

• sicher im generellen Umgang mit der oxaion open IDE sein
• den Misch-Arbeitsfluss der IDE beherrschen (Merging)
• grundlegendes Wissen über die Funktionsweise von oxaion open mitbringen
• Zugriff auf Wissensträger der jeweiligen Fachbereiche haben (da für ein erfolgreiches Mischen Kenntnisse der (ggf modifizierten) fachlichen Prozesse notwendig sein können)

Durchführung

ohne IDE geänderte variable Sichten aktualisieren

Da variable Sichten auch ohne die IDE angepasst werden können müssen sie vor dem Mischen aktualsiert werden.

Die zu aktualisierendenen Sichten sind im Programm OP70130 "Sichtänderungen einspielen" mit dem Status "W" markiert.

Ist ein Programm mit Status "W" markiert so muss diese via "Sichten" Programm serialisiert und in die Versionskontrolle gebracht werden.

Mischen der Aktualisierungen in den stg-Zweig

Im ersten Schritt muss per Rechtsklick auf dem Projekt die Mischfunktion aufgerufen werden:

Ein Dialog mit den möglichen mischbaren Quellen erscheint.

Hier kann einfach der aktuellste Stand des oxaion/5.1.x Zweiges ausgewählt werden oder ein bestimmter Stand (Tag).

Wählt man den aktuellste Stand des oxaion/5.1.x Zweiges ist es wichtig hier den jeweiligen entfernten Zweig (Remote Tracking) zu wählen und nicht den ggf. vorhandenen lokalen (Local).

Die Optionen "No commit (...)" sowie "If a fast-forward, create a merge commit" sind im Beispiel ausgewählt um den Merge-Commit nochmals prüfen und ggf. auch einen eigenen Committext vergeben zu können.

Ist beides nicht gewünscht können die Standard-Optionen (die jeweils ersten der 3) belassen werden.

(optional) Konflikte lösen

Sollte beim Mischen Konflikte auftreten so werden diese als rot markierte Einträge im sog. "Unstaged Bereich" (Unstaged Changes) der GIT Staging View sichtbar.

Dort können sie doppelt geklickt werden. Dies öffnet einen 2-Wege-Vergleich in dem alle Unterschiede und Konflikte in der jeweiligen Datei sichtbar werden.

Sind die Konflikte beseitigt, und gespeichert, muss die entsprechende Datei per Drag&Drop in den sog. "Staged Bereich" (Staged Changes) der GIT Staging View gezogen werden.

Dies ist für alle konfliktbehafteten Dateien zu wiederholen. Dabei die Anleitung zur Konfliktlösung & Hilfestellungen beachten!

Server starten

Der Server kann mittels eines sogenannten Launchers in der IDE gestartet werden:

Die Ausgaben in der Konsole sollten in etwa folgendermaßen aussehen:

Client starten

Auch der Client wird über einen entsprechenden Launcher gestartet.

Übernahme der Datenbank-Änderungen

Nach dem erfolgreichen Login beginnt der 3-stufige Übernahmeprozess der gemischten Metadaten in die Datenbank.

Changesets

Changesets sind Datenbankimporte welche über kein eigenes Übernahmeprogramm verfügen da sie direkt beim Systemstart importiert werden (müssen) um direkt zur Verfügung stehen zu können.

Changesets können aktuell für Änderungen an TBV-Daten, Jobs, Registrierungs-Schlüsseln, (Fehler-)Nachrichten und pure SQL Anweisungen genutzt werden.

Die zum jeweiligen Patch passenden Changesets können in der IDE unter folgendem Pfad gefunden werden:

Da die Patches monatlich erscheinen liegen die zum jeweiligen Patch passenden in einem Unterverzeichnis welches zum Schema YYYY-MM passt. (YYYY = Jahr vierstellig, MM = Monat zweistellig)

Die beim Systemstart importierten Changesets können mittels eines eigenen Listprogrammes (OP70200) eingesehen werden:

Dieses Programm listet die folgenden Informationen:

1. Die XML Datei welche die entsprechenden Changesets enthält
2. den Typ des Changesets
3. den Ausführungsstatus (SUCCESSFUL, EXISTING, FAILED)
4. die Beschreibung des Changesets
5. das Ausführungsprotokoll (Begründung des Status)
6. den Ausführungszeitpunkt
7. die Prüfsumme des Changesets
8. die XML Repräsentation des Changesets

Per Rechtsklick kann ein Changeset als ausgeführt markiert werden oder noch einmal ausgeführt werden:

Die erstere Option dient dabei zum "deaktivieren" von Changesets für die aktuelle Umgebung (=DB).

Es sollte geprüft werden ob alle Changesets erfolgreich importiert werden konnten.

Referenzfelder

Die Referenzfelder werden mittels des Programmes OP70100 "Referenzfeldänderungen einspielen" übernommen.

In diesem Programm werden folgende Informationen gelistet:

1. Name des Referenzfeldes
2. Verwendung des Referenzfeldes (betroffene Dateien/Tabellen)
3. Beschreibungstext des Referenzfeldes
4. Art der Änderung (C = Change, A = Add, ...)
5. Importstatus der Metadaten des Referenzfeldes (rot = noch nicht importiert, grün = bereits importiert)
6. Erfassungsdatum
7. Name des Erfassers
8. Änderungsdatum
9. zuletzt geändert von

Vor Beginn der Übernahme der Änderungen muss die Liste der Änderungen mittels Klick auf den entsprechenden Menüpunkt aktualisiert werden:

Per Rechtsklick auf einen Eintrag der ersten Ebene (=Referenzfeld) können und die Änderungen vorab eingesehen werden oder die Referenzfeldmetadaten des betreffenden Feldes importiert werden.

Per Rechtsklick auf einen Eintrag der zweiten Ebene (=betroffene Tabellen) kann die entsprechende Tabelle aktualisiert werden (= Create Objects CO).

Sind alle geänderten Referenzfelder importiert und alle Tabellen aktualisiert kann fortgefahren werden mit dem nächsten Punkt.

Tabellen

Die Änderungen an den Datenbank-Tabellen werden mittels des Programmes OP70110 "Datenbankänderungen einspielen" übernommen.

In diesem Programm werden folgende Informationen gelistet:

1. Tabellenname (1. Ebene)
   1. Tabellenname abhängige Tabelle (2. Ebene)
2. Bezeichnung der Tabelle
3. Art der Änderung (C = Änderung, N = Neu, D = gelöscht)
4. Importstatus (rot = noch zu importieren, grün = bereits importiert)
5. Erfassungsdatum
6. Name des Erfassers
7. Änderungsdatum
8. Zuletzt geändert von

Vor Beginn der Übernahme der Änderungen muss die Liste der Änderungen mittels Klick auf den entsprechenden Menüpunkt aktualisiert werden:

Per Rechtsklick auf einen Eintrag erster Ebene können die Änderungen eingesehen, die Metadaten des Eintrags importiert oder die Änderung in der Datenbank vorgenommen werden.

Per Rechtsklick auf einen Eintrag der zweiten Ebene können die Metadaten des Eintrags importiert oder die Änderung in der Datenbank vorgenommen werden.

Sind alle Tabellen aktualisiert kann fortgefahren werden mit dem nächsten Punkt.

Programme

Die Änderungen an den Programm-Metadaten werden mittels des Programmes OP70120 "Generatordatenänderungen einspielen" übernommen.

In diesem Programm werden folgende Informationen gelistet:

1. Progamm-Name
2. Programmbezeichnung
3. Art der Änderung (C = Änderung, N = Neu)
4. Importstatus (rot = noch nicht importiert, grün = bereits importiert)
5. Erfassungsdatum
6. Name des Erfassers
7. Änderungsdatum
8. Zuletzt geändert von

Vor Beginn der Übernahme der Änderungen muss die Liste der Änderungen mittels Klick auf den entsprechenden Menüpunkt aktualisiert werden:

Per Rechtsklick auf einen Listeneintrag können die Änderungen an den Metadaten des Programmes anzeigt oder importiert werden:

variable Sichten

Die Änderungen an den variablen Sichten werden mittels des Programmes OP70130 "Sichtänderungen einspielen" übernommen.

In diesem Programm werden folgende Informationen gelistet:

1. Progamm-Name
2. Programmbezeichnung
3. Art der Änderung (C = Änderung, N = Neu)
4. Importstatus (rot = noch nicht importiert, grün = bereits importiert)
5. Erfassungsdatum
6. Name des Erfassers
7. Änderungsdatum
8. Zuletzt geändert von

Vor Beginn der Übernahme der Änderungen muss die Liste der Änderungen mittels Klick auf den entsprechenden Menüpunkt aktualisiert werden:

Per Rechtsklick auf einen Listeneintrag können die Änderungen an den Sichtdaten des Programmes angezeigt oder in die aktuelle Nutzerumgebung importiert werden:

Release Notes

In den jeweiligen Release Notes können weitere manuelle Nacharbeiten zum gemischten Patch notiert sein.

Diese sind ebenfalls abzuarbeiten.

Abschluss / Aufräumarbeiten

Nach Import/Aktualisierung aller datenbankrelevanten Änderungen muss noch die Version (version=5.1.1.x) in der gradle-customer.properties Datei um eins erhöht werden.

Optional wenn lokal gebauter Applikationsserver genutzt wurde:

Die Änderung an der gradle-customer.properties Datei, welche unter Punkt "IDE zur Nutzung des lokal gebauten Applikationsservers konfigurieren" vorgenommen wurde (useMavenLocal) muss rückgängig gemacht werden.

Nun kann die Git-Staging-Ansicht der IDE genutzt werden um die Änderungen an den Quellen zu veröffentlichen.

Sind alle Änderungen veröffentlicht wird der Applikationsserver (nicht der in der IDE) diese beim nächtlichen Build verwenden und nach einem Neustart stehen diese dann für Tests bereit.

Breaking-Change-Patch

Andere Umgebungen

Diese Dokumentation zeigt die Übernahme von Patches in den stg Zweig einer Installation.

Nach dem erfolgreichen Test auf einem nicht-IDE-Server müssen die gleichen Schritte auch für die Produktionsumgebung vorgenommen werden (inkl. der Vergabe eines Tags wie auch bei Nicht-Patch-Releases von kundeneigenen Änderungen).

Ebenso müssen diese Schritte für Rückmerges von Produktion (PRD) nach Staging (STG) oder Produktion (PRD) nach Entwicklung (develop) durchgeführt werden da Änderungen/Erweiterungen auch in Form von Hotfixes (welche auf dem prd-Zweig vorgenommen werden) erfolgen können.

Ermitteln, welcher Patch-Stand aktuell eingesetzt wird

via SYSINFO

ab Version 5.1.1.47 zeigt die SYSINFO folgende Informationen über die Version des open Application Servers:

• Revision: der Hash zum letztem Commit der Version
• Version: der letzte V-Tag (= Kunden-Versions-Tag) 
• Release: der letzte R-Tag (=oxaion-Versions-Tag)

via Bitbucket

In Bitbucket kann der aktuelle Patchstand über eine Suche nach dem aktuellsten oxaion-Versions-Tag ermittelt werden.

Dieser oxaion-Versions-Tag unterscheidet sich von Kunden-Versions-Tag durch den Präfix "r". Kunden-Versions-Tags haben den Präfix "v".

Im Beispiel wäre der aktuellste oxaion-Versions-Tag die Version "r5.1.1.11".