Im zweite Teil der Reihe geht es um das Zusammenführen (merge) von parallelen Entwicklungssträngen (fork) von Oracle APEX-Anwendungen.
Das Zusammenführen zweier paralleler Entwicklungsstränge bringt einiges an Aufwand mit sich. Ich möchte Ihnen in diesem Beitrag ein mögliches Vorgehe beschreiben.
Zu Anfang geht es darum sich das Delta der beiden Releases bewusst zu machen. In welchen Punkten weichen die Datenbank Schemas voneinander ab? Welche Datenbankobjekte müssen in dem Zielschema neu erzeugt werden? Welche werden nicht mehr benötigt oder müssen angepasst werden?
Im zweiten Schritt stellen Sie sich ähnliche Fragen für die eigentliche Anwendung. Welche Anwendungsteile, seien es Seiten, Regionen, Items oder Shared Components, sind neu, entfallen oder wurden geändert?
Aus diesen Analysen ergibt sich eine ToDo Liste der Anpassungen, die Sie durchführen müssen.
Im nächsten Schritt führen Sie die Objekte der Schemas zusammen, so dass Sie ein gemeinsames neues Datenmodell für das neue Release erhalten. Auf dieser Basis passen Sie dann die Supporting Objects im Basisentwicklungsstrang an.
Zu guter Letzt, geht es noch an das Überarbeiten der Anwendung. Dabei müssen Sie neue Seite aus dem parallelen Release in die Basisversion integrieren. Evtl. müssen Sie nicht mehr benötigte Bestandteile entfernen. Der aufwändigste Part wird in der Regel die manuelle Integration von partiellen Änderungen , z.B. in einer vorhandenen Seite sein.
Datenmodelle vergleichen und Unterschiede ermitteln
Es gibt sicher viele Ansätze, mit denen Sie ausgehend von einem Entwicklungsstand eines Datenmodells die Änderungen zu einem neues Release ermitteln können. An dieser Stelle möchte Ich Ihnen zwei Varianten vorstellen.
Änderungen protokollieren
Mit etwas Disziplin könnten Sie jede Änderung, die Sie vornehmen, als DDL-Skript speichern. Ich persönlich finde allerdings, dass man durch solche Verwaltungsaufgaben immer aus seinem Arbeitsfluss gerissen wird. Wenn Sie so ein Vorgehen präferieren, dann schauen Sie sich doch einmal diesen Beitrag Protokollieren von Strukturänderungen an. Dort stelle ich Ihnen eine Möglichkeit vor, wie Sie einen DDL-Trigger nutzen können, der alle Änderungen an einem Schema protokolliert.
Auf Basis dieses Protokolls können Sie ein DDL-Skript entwickeln, um damit das Datenmodell eines Releases in das Modell eines neueren Releases zu überführen.
Schema vergleichen
APEX bringt aber auch von Haus aus eine sehr nützliche Funktion für diesen Fall mit. Im SQL Workshop finden Sie im Bereich Utilities den Link Schema Comparison. Da hinter verbirgt sich ein Werkzeug, mit dem Sie die Objekte eines Schemas mit denen eines anderen Schemas vergleichen können. Ihnen werden allerdings nur die Schemas angezeigt, die dem Workspace zugeordnet wurden.
Wie Sie im ersten Teil dieser Beitragsreihe lesen konnten, können Sie einem APEX-Workspace mehrere Schemas zuordnen. Möchten Sie nun für eine neue Version Ihrer Anwendung ein Upgrade-Skript entwickeln, so können Sie wie folgt vorgehen.
Stellen Sie aus Ihrem Anwendungsarchiv die Vorgängerversionen Ihrer Anwendung wieder her.
Dabei wählen Sie ein anderes Schema als bei der aktuellen Version Ihrer Anwendung. Wenn Sie in Ihrer Anwendung die notwendigen DDL-Skripte als Supporting Objects hinterlegt haben, führen Sie diese bei der Installation aus.
Jetzt haben Sie in Ihrem Workspace das Schema Ihres Basisentwicklungsstrangs und das Schema des Vorgänger Releases im Zugriff.
Den Vergleich der jeweils enthaltenen Objekte können Sie anschließend mit Hilfe des Utilities Schema Comparison durchführen.
Die Handhabung ist einfach. Wählen Sie die zu vergleichenden Schemas aus und legen Sie bei Bedarf noch einen Filter fest. Dann klicken Sie auf Compare.
Als Ergebnis erhalten Sie eine Übersicht der abweichenden Datenbankobjekte. Anhand dieser Liste können Sie die fehlenden DDL-Skripte erstellen.
Anwendungsteile vergleichen, Unterschiede ermitteln
Eine APEX-Anwendung wird durch Ihre Eigenschaften definiert. Diese Daten werden bei APEX in Tabellen gespeichert. Diese strukturierte Ablage der Definition macht es möglich, Anwendungen sehr detailliert vergleichen zu können.
Im Internet findet man vereinzelt Ansätze, mit denen Sie die Unterschiede zweier Anwendungen ermitteln können. Beispielsweise existiert ein Open Source Projekt auf github namens apex-diff, welches einen Vergleich ermöglicht.
Ein andere Möglichkeit bieten die APEX-Views. Über diese können Sie entsprechende select-Statements entwickeln, die einzelne Bestandteile zweier Anwendungen miteinander abgleichen. So ein Abgleich – hier für die Pages – kann z.B wie in Listing 1 aussehen.
SELECT
n.page_id,
n.page_name,
'Page was changed ( N: '
|| n.last_updated_on
|| ' , O: '
|| o.last_updated_on || ' )' AS info
FROM
apex_180100.apex_application_pages n,
apex_180100.apex_application_pages o
WHERE
n.application_id = 115
AND o.application_id = 113
AND n.page_id = o.page_id
AND n.last_updated_on <> o.last_updated_on
UNION
SELECT
n.page_id,
n.page_name,
'New page in application ' || n.application_id AS info
FROM
apex_180100.apex_application_pages n
WHERE
n.application_id = 115
AND NOT EXISTS (
SELECT
'X'
FROM
apex_180100.apex_application_pages o
WHERE
o.application_id = 113
AND n.page_id = o.page_id
)
UNION
SELECT
o.page_id,
o.page_name,
'Deleted page ' AS info
FROM
apex_180100.apex_application_pages o
WHERE
o.application_id = 113
AND NOT EXISTS (
SELECT
'X'
FROM
apex_180100.apex_application_pages n
WHERE
n.application_id = 115
AND n.page_id = o.page_id
);
Listing 1: App 115 mit App 113 vergleichen
Das Ergebnis sieht dann beispielhaft so aus.
Auf Basis der APEX-Views können Sie auf diese Art und Weise für alle Komponenten einer APEX -Anwendung entsprechende Vergleiche erstellen.
APEX selbst bietet für den Anwendungsvergleich unter seinen Workspace–Utilities aber auch ein entsprechendes Werkzeug namens Application Comparison.
Dieses liefert Ihnen eine Liste mit abweichenden Objekten.
Zusammenführen von Entwicklungszweigen (fork)
Grundsätzlich müssen Sie hier zwei Bereiche der Anwendung betrachten. Die Datenbankobjekte und die Anwendung.
Datenmodell bzw. Datenbankobjekte
Auf Basis der im vorhergehenden Abschnitt ermittelten Unterschiede können Sie nun das Schema des Basisentwicklungsstrangs auf den benötigten aktuellen Stand bringen.
Zuerst legen Sie die neue Objekte an. Dazu können Sie z.B. ein DDL-Statemit auf Basis des vorhandenen Objektes extrahieren oder Sie ermitteln die DDL- Anweisung wie oben beschrieben mit einem DDL-Trigger aus einer Log Tabelle.
Abweichende Datenbankobjekte (Tabellen, Views , Packages,…) müssen nun von Hand überarbeitet werden. Hier müssen Sie entscheiden, ob eine Version durch eine aktuelle Version komplett ersetzt werden kann oder ob eine manuelle Ergänzung notwendig ist. Als Beispiel seien hier neue Spalten in einer Tabelle oder neue Funktionen in einem PL/SQL Package erwähnt.
Als Ergebnis haben Sie in Ihrem Basisschema abschließend alle benötigten Datenbankobjekte aus beiden Entwicklungssträngen zusammen gefügt.
Supporting Objects
APEX bietet mit den Supporting Objects – wie bereits erwähnt – die Möglichkeit DDL und DML-Skripte in der Anwendung zu hinterlegen, die bei der Installation der Anwendung ausgeführt werden.
Ein einfacher Ansatz ist es ein DDL-Skript zu entwickeln, welches alle benötigten Datenbankobjekte von Grund auf neu erzeugt. Da es aber recht zeitaufwendig und fehleranfällig ist ein komplett neues Installationsskript zu erstellen, können Sie auch einfach ein weiteres DDL-Skript nach dem bereits vorhandenem laufen lassen. Dieses ergänzt dann die neuen Objekte.
Die Migration der bestehenden Daten einer produktiven Vorgängerversion kann in einem zweiten Schritt über ein Upgrade Skript erfolgen. Bei diesem Ansatz fügen Sie dem produktiven Workspace ein neues Schema hinzu in dem Sie die Anwendung inkl. aller Datenbankobjekte des neuen Releases installieren. Abschließend wird dann über die Supporting Objects ein Skript ausgeführt, welches die Daten aus der Vorgängerversion in die neue Tabellen des neuen Schemas überführt.
Dieser Ansatz bietet aus meiner Sicht den Vorteil, dass Sie immer eine sehr einfache Fallback-Variante haben. Die Altdaten und die alte Anwendung werden nicht angetastet und können im Fehlerfall weiter genutzt werden.
Werkzeuge
APEX bietet in seinem SQL Workshop das Werkzeug Generate DDL, mit dem Sie – auch selektiv – für vorhandene Datenbankobjekte DDL-Skripte erzeugen können.
Auf dieser Basis können Sie dann entsprechende Skripte erstellen und diese in den Supporting Objects hinterlegen.
Ein anderes sehr nützliches Tool finden Sie direkt in den Supporting Objects. In dem Bereich Installation Scripts können Sie über die Schaltfläche Create > einen Wizzard starten, der Ihnen zu Beginn u.a. die Option “Create from Database Object’ anbietet.
Bei dieser Variante können Sie für verschiedene Datenbankobjekte entsprechende DDL Skripte erzeugen lassen und direkt in den Supporting Objects speichern.
Anwendungsteile zusammen führen
Jetzt müssen Sie sich noch um die Anwendung selbst kümmern. Leider ist auch hier einiges an Handarbeit angesagt. Es sind verschiedene Bereiche zu berücksichtigen.
Meine Empfehlung ist es mit den Shared Components zu beginnen. Da diese von verschiedenen anderen Teilen Ihrer Anwendung verwendet werden. Anschließend sind die Seiten und deren Bestandteile an der Reihe.
Shared Components
Um die Bestandteile der Shared Components von einer Anwendungsversion in eine Andere zu übernehmen, gibt es verschiedene Methoden.
1. Es gibt Komponenten bzw. Einstellungen, die Sie schlicht manuell überführen müssen.
2. Einige der Komponenten können Sie über Create > As a Copy of an … > Copy from Application aus einer anderen Anwendung des Workspaces übernehmen. Wo immer es geht, sollten Sie diese Möglichkeit nutzen. Eine Übersicht der Shared Components, bei denen ich diese Möglichkeit gefunden habe, finden Sie in Abbildung 11.
3. Als Alternative bietet sich für die meisten Shared Components noch der Export und anschließende Import an. Wobei auch dieser Ansatz durch notwendige Anpassungen (Workdpace-Id, App-Id und evtl. ein Offset) an dem Exportfile nicht optimal ist. Beachten sie bitte, dass beim Import Komponenten wie z.B. Seiten durch Seiten mit der gleichen Id überschrieben werden. Mehr dazu finden Sie unter anderem hier.
Pages und Co.
Als letzter Schritt sind jetzt noch die eigentlichen Seiten und deren Inhalte abzugleichen.
Neue Seiten können Sie über den Application Builder aus dem parallelen Release in Ihre Basisanwendung übernehmen. Dazu klicken Sie im Page Designer auf das + in der Toolbar. In dem sich öffnenden Drop-Down-Menü wählen Sie Page as Copy.
Jetzt folgen ‘Sie nur noch dem Wizzard und geben dabei an, dass Sie eine Seite aus einer anderen Applikation kopieren möchten. (Page in another Application)
Möchten Sie eine bereits vorhandenen Seite komplett ersetzen, so können Sie die neue Seite mit einer anderen PageId erzeugen lassen oder Sie löschen im Vorfeld die ursprüngliche Seite und kopieren die Seite dann mit der herkömmlichen Seitennummer.
Geht es Ihnen darum, nur einzelne Bestandteile einer Seite aus dem Fork zu übernehmen, müssen Sie im ersten Schritt die Quellseite aus dem Fork in die Basisversion als Kopie einfügen. Anschließend öffnen Sie diese Seite und klicken mit der rechten Maustaste auf die Bestandteile der Seite die Sie kopieren möchten. In dem sich öffnenden Kontextmenü wählen Sie den Eintrag Copy to other Page und beantworten anschließend die Fragen des Wizzards.
Wie bereits in dem Abschnitt über das Kopieren der Shared Components erwähnt, bietet APEX die – meiner Meinung nach nicht zu Ende gedachten Funktion – des Komponenten-Exports und -Imports. Über diese Funktion ist es Ihnen möglich selektiv Bestandteile einer Anwendung zu exportieren. Vor dem Import der Komponenten müssen Sie aber auch hier vorab das SQL-Skript manuell anpassen.(s.o.)
Fazit
Es ist schon ein mühsames Geschäft, verschiedene Versionen einer Anwendung zu Verwalten und zu beherrschen. Ich versuche immer parallele Entwicklungsstränge nach Möglichkeit zu vermeiden. Der Aufwand diese Stränge wieder in einem Basisentwicklungsstrangs zusammenzuführen ist mitunter sehr aufwändig.
Allerdings treffen Sie auch auf ähnlich Probleme, wenn Sie versuchen Komponenten aus bereits vorhanden Anwendungen in einer neuen – thematisch vielleicht anders gelagerten – Anwendung zu übernehmen und wiederzuverwenden. Auf Komponentenbasis stehen Ihnen dafür Plug/Ins zur Verfügung. Für zusammenhängende Teile (Module) eine Anwendung, die aus mehreren Seiten, Shared Components und Datenbankobjekten bestehen, bietet APEX kein wirklich praxistaugliches Konzept.
Sie können Funktionalitäten höchsten in kleine, in sich abgeschlossenen Anwendungen aufteilen. Dies funktioniert in der Praxis aber meist nur, wenn Sie auf Single Sign On setzen.
Beitragsreihe
[catlist name=”APEX SCM (Reihe)”]
