Versionsverwaltung und Konfigurationsmanagement ist für den Entwicklungszyklus gerade auch im Rahmen agiler bzw. iterativer Entwicklung von Oracle Application Express (APEX) Anwendungen ein wichtiges aber sicherlich oft vernachlässigtes Thema. Im ersten Teil geht es um die Versionierung und das Betreiben unterschiedlicher paralleler Versionen in einer Entwicklungsumgebung.
Was versteht man unter Konfigurationsmanagement?
Laut Wikipedia versteht man unter Konfigurationsmanagement
“Konfigurationsmanagement (KM; englisch configuration management, CM) ist eine Managementdisziplin, die organisatorische und verhaltensmäßige Regeln auf den Lebenslauf eines Produkts und seiner Konfigurationseinheiten [..] anwendet.
[..]
Es sind vier Teilgebiete (Teilprozesse) des KM zu unterscheiden:
- Konfigurationsidentifizierung (KI),
- Konfigurationsbuchführung (KB),
- Konfigurationsüberwachung (KÜ) und
- Konfigurationsaudit (KA).
Ihre koordinierte Umsetzung ist für ein erfolgreiches Konfigurationsmanagement unumgänglich.“
Quelle: https://de.m.wikipedia.org/wiki/Konfigurationsmanagement, 24.06.2018
Im Rahmen der Entwicklung von Software spricht man von Software-Configuration-Management(SCM).
Wie bei vielen Managementsystemen kommen solche Definitionen meist sehr sperrig daher. Im Rahmen der Anwendungsentwicklung mit APEX soll hier eine pragmatische Umsetzung des Ganzen gezeigt werden.
Agile Softwareentwicklung mit APEX
Beginnt man ein neues APEX-Projekt, so wird man je nach Projektmanagementmethode und Größe des Projektes unterschiedlich an die Sache heran gehen.
Aus meiner Sicht bietet sich aber gerade ein agiles Vorgehen für die Entwicklung von APEX-Anwendungen an. Welches konkrete Vorgehensmodell Sie dabei wählen ist zweitrangig.
Bei einem agilen Ansatz starten Sie mit einem ersten Teil Ihres Datenmodells und entwickeln dann sehr zügig die jeweiligen Seiten in Ihrer Anwendung. So erhalten Sie sofort vorzeigbare Anwendungsteile, die Sie mit Ihren Kunden, Productowner, … durchsprechen und abstimmen können.
Aber auch wenn Sie grossschrittiger vorgehen müssen und Ihren Kunden fertig entwickelte Releases ausliefern, gehen Sie als Entwickler wahrscheinlich itterativ an die Sache heran.
Sie starten also mit einem leeren Schema und einem Workspace, erstellen die ersten Tabellen. Dann kann schon die erste Version der Anwendung per Application Wizzard erzeugt werden. Durch die Nutzung der Metadaten, welche die Datenbank APEX zur Verfügung stellt, fügen Sie die ersten Seiten der Anwendung hinzu. Jetzt erweitern Sie das Datenmodell und ergänzen die zugehörigen Seiten in der Anwendung. Die Businesslogik lagern Sie in PL/SQL-Packages aus. Je nach Komplexität und Umfang des Projektes abstrahieren Sie zwischen Datenmodell und Anwendung noch über Views. Auf diese Weise entstehen sukzessive weitere Datenbankobjekte und Anwendungsteile.
Alle diese Teile sind Bestandteil einer sogenannten Konfigurationseinheit.
Sie erzeugen also eine Kette von Builds, die dann weiter zu einem Release der Anwendung führen.
Anschließend oder auch schon parallel werden Sie die Anwendung in einem Testsystem mehr oder weniger ausgiebig testen (lassen) und dann an Ihren Kunden ausliefern.
Je nach Anwendung entwickeln Sie das System weiter. In Ihrem Entwicklungssystem steht dann mit großer Wahrscheinlichkeit nicht mehr die Version, mit der Sie Ihre Kunden beliefert haben, zur Verfügung. Dies führt bei Supportanfragen Ihres Kunden dazu, dass Sie in einem Supportsystem, das ausgelieferte System mit entsprechendem Releasestand wiederherstellen müssen. Fixen Sie den Fehler in dem (veralteten Release), so muss die so bereinigte Version bei Ihren Kunden eingespielt werden. Zusätzlich müssen Sie nun das Problem auch noch in Ihrem aktuellen Entwicklungsstand der Anwendung beheben.
Noch komplizierter wird dieses Szenario, wenn Sie verschiedene Releasestände an mehrere Kunden ausgeliefert haben, dabei aber evtl. auch noch individuelle Anforderungen einzelner Kunden berücksichtigten mussten.
Aus diesem Lebenszyklus einer Software ergeben sich verschiedene Probleme:
- Wie Verwalten Sie unterschiedliche Versionen (Releasestände und Builds) Ihrer APEX-Anwendungen ?
- Wie erstellen Sie Test-, Integrations- und Supportsysteme, in denen Sie verschiedene Versionen Ihrer Anwendung verwalten können ?
- Wie führen Sie parallele Entwicklungslinieren (Forkes) wieder in Ihrer Basisanwendung zusammen ?
- Wie dokumentieren und identifizieren Sie die Änderungen an Ihren Anwendungsversionen inkl. aller Bestandteile (Tabellen, Views, Triggers, PL/SQL-Packages,…) ?
Konfigurationseinheiten: Komponenten einer APEX Anwendung
Aus welchen Bestandteilen besteht denn nun eine APEX-Anwendung?
Wenn Sie versuchen, diese Frage zu beantworten, schauen Sie sich doch einfach an, was Sie alles benötigen, um eine APEX-Anwendung in einem Produktivstem zum Laufen zu bringen.
Vorausgesetzt, dass eine laufende Oracle-Datenbank mit eingerichtetem APEX (in der korrekten Version) zur Verfügung steht, benötigen Sie zuerst ein Export-File der APEX-Anwendung. Dabei handelt es sich um ein SQL-Skript, mit dem Sie eine Anwendung in APEX exportieren und importieren können.
Die Anwendung basiert natürlich auf Tabellen und verwendet verschiedene anderen Datenbankobjekte. APEX bietet die Möglichkeit, diese Datenbankobjekte über entsprechende DDL-Skripte bei der Installation bzw. dem Import einer Anwendung anlegen zu lassen.
Um diese Tabellen initial mit Stammdaten zu füllen, erstellen Sie entsprechende DML-Skripte.
All diese Skripte können Sie in den sogenannten Supporting Objects hinterlegen, die Sie im Application Builder über die gleichnamigen Schaltfläche aufrufen können.
Auch für das Upgraden einer produktiven Anwendung, ist es möglich in den Supporting Objects Skripte zu hinterlegen, welche die Änderung zum Vorgänger-Release abdecken.
Natürlich kann man das benötigte Datenmodell über einen Dump oder separate SQL-Skripte in einem Produktivstem einrichten. Da die Supporting Objects aber Bestandteil einer APEX-Anwendung sind und diese mit in dem Anwendungs-Exportfile vorhanden sind, ist es am geschicktesten, diese Möglichkeit zu verwenden. Gerade auch im Hinblick auf die Versionsverwaltung bringt das einige Vorteile mit sich.
Versionierung
Damit Sie den Überblick über die Versionsstände Ihrer Anwendung behalten, ist es ganz hilfreich für etwas Ordnung zu sorgen. APEX bietet Ihnen die Möglichkeit, Ihren Anwendungen beschreibende Eigenschaften mitzugeben. Diese Eigenschaften finden Sie etwas versteckt hinter dem Button Edit Application Properties im Application Builder.
Wie Sie hier sehen können, finden Sie ein Textfeld namens Release. Hier können Sie für jede Version Ihrer Anwendung den zugehörigen Releasestand festhalten. Das klingt erst einmal banal, bringt aber den praktischen Vorteil mit sich, dass Sie bei einer archivierten oder ausgeliederten Anwendung wissen, welche Version Ihrer Anwendung Sie gerade vor sich haben.
Aber wie können Sie eine Versionsnummer konzipieren, die Ihnen einen Überblick verschafft?
Es gibt da sicher verschiedene Möglichkeiten. Ich möchte Ihnen hier die von mir bevorzugte Variante vorstellen.
<Hauptentwicklungslinie>.<Entwicklungszweig>.<Build>
Zu Begin einer Anwendungsentwicklung, also vor dem ersten Release geht es also mit 0.0.1 los.
Nach einer Iteration oder dem erreichen eines Meilensteins erhöhen Sie die Build Nr. auf 0.0.2.
Haben Sie eine releasefähige Version Ihrer Anwendung erreicht, so erhöhen Sie die erste Stelle um 1.
Version 1.0.0
Diese Version nehmen Sie produktiv und entwickeln an der Anwendung weiter.
Es entsteht also Build 1.0.1… 1.0.2 …
Müssen Sie einen Fehler in Version 1.0.0 beheben, erstellen Sie einen Forke Ihrer Anwendung und geben diesem die Version 1.1.0. Änderungen an dieser Version laufen jetzt paralell zu Ihrer Hauptentwicklungslinie (Baseline), die bereits bei Version 1.0.2 angelangt ist.
Für einen anderen Kunden erweitern Sie die Version 1.0.0 um eine individuelle Funktion. Diese ist dann wieder ein Forke der Version 1.0.0 und wird mit 1.2.0 benannt.
Um nun den Aufwand dauerhaft in den Griff zu bekommen und den Überblick nicht zu verlieren, ist es ratsam, die Bugfixes aus den Strang 1.1.x und evtl. die kundenspezifischen Funktionen in den Basisentwicklungsstrang zu integrieren (merge). Was in APEX nicht immer so einfach ist. Aber dazu im zweiten Teil der Beitragsreihe später mehr.
Die neuen Funktionen und Bugfixes fulminieren dann irgendwann in einem neuen Release 2.0.0.
Ihre Entwicklungslinien sehen jetzt so aus.
Im Application Builder werden Ihnen Ihre Anwendungen über ein Interaktiven Report präsentiert. Blenden Sie dort über Actions >> Columns die Version und evtl. andere für Sie relevante Spalten ein. Anschließend speichern Sie sich über Actions >> Report >> Save Report Ihre individuelle Berichtsansichten.
Hilfreich finde ich auch die Zuordnung von Anwendungen zu Gruppen. Z.B. können Sie so zwischen Test, Produktiv, Support und Entwicklung unterscheiden.
Anwendungsgruppen (Application Groups) legen Sie über das Menü App Builder >> Workspace Utilities-Database >> Application Groups fest. Über die Anwendungseigenschaften (Button Edit Application Properties) ordnen Sie Ihre Anwendung einer Gruppe zu. Diese Gruppen lassen sich genau wie die Version im Interaktiven Report einblenden.
Die Abbildung 5 zeigt ihnen eine aufbereitete Übersicht der Anwendungen in APEX, die bei dem oben skizzierten Projektablauf entstanden sind.
Archivierung von Releaseständen
APEX bietet verschiedene Möglichkeiten Anwendungen zu archivieren. Die Basis für diese Ansätze ist ein Exportfile. Über den Application Builder können Sie alle Eigenschaften eines APEX-Programms in Form eines SQL-Skriptes exportieren.
Diese Datei beinhaltet die komplette Definition aller Seiten, Regionen, Items, Prozesse,… aber auch aller Shared Components wie Dateien oder Listen und – wie bereits erwähnt – die Supporting Objects. Nutzen Sie all diese Möglichkeiten, so können Sie die komplette Anwendung inkl. der Datenbankobjekte in einer einzigen Datei zusammenfassen und später diesen (Release)Stand wiederherstellen.
Somit ergibt sich als einfache Möglichkeit verschiedene Versionen einer APEX-Anwendung zu archivieren, der regelmäßige manuelle Export der Anwendung und Speicherung in einer nach Versionen benannten Ordnern. Diese Idee kann man nun mit einer Software zur Versionsverwaltung wie z.B. SVN oder GIT kombinieren. Im Internet finden Sie verschiedene Beispiele, wie Sie mit verschiedenen Tolles diesen Weg automatisieren können. In dem Artikel ORACLE APEX DEPLOYMENT:YOU’RE DOING IT WRONG stellt Martin D’Souza die Möglichkeit vor, via. SQLcl zu automatisieren.Mit APEX selbst wird der APEX Java Exporter ausgeliefert, über den Ihnen viele Möglichkeiten zum Exportieren von Anwendungen und Komponenten zur Verfügung stehen.
Wählen Sie beim manuellen Exportieren einer Anwendung das File Format “Database”, so archiviert APEX die Datei im sogenannten Export Repository. Dieses finden Sie in den Workspace Utilities-Database >> Export >> Export Repository (in der rechten Sidebar). Allerdings bietet die Tabelle nicht wirklich viele Informationen zu den archivierten Anwendungen.
Einen anderen Ansatz finden Sie in diesem Blog-Beitrag. Dabei werden die einzelnen Bestandteile (Seiten) einer Anwendung separat extrahiert und übersichtlich in einem Verzeichnisbaum bzw. der Datenbank gespeichert. Dieser Ansatz lässt auch automatisieren.
Eine weitere ebenfalls automatisierbare Variante bietet Oracle mit einem seiner Packaged Applications “APEX Application Archive”. Mit dieser Applikation lassen sich Backups Ihrer Anwendungen erstellen, die dann in der Datenbank verwaltet werden. Erweitern Sie das Ganze noch mit Hilfe des Datenbankschedulers ( dbms_schedule ), können Sie die Archivierung komplett automatisieren. Wie Sie das im Einzelnen funktioniert, können Sie sich in dieser Beitragsreihe genau ansehen.
[catlist name=”APEX Application Archive”]
Ich persönlich favorisiere diese Möglichkeit, da Sie sich sehr schnell einrichten und anpassen lässt und mit der Package Application “APEX Application Archive” ein Programm zur Verwaltung der einzelnen Releasestände zur Verfügung steht.
Parallele Versionen in APEX betreiben
Aber wie können Sie diese unterschiedlichen Versionen Ihrer Anwendungen in APEX parallel bearbeiten und betreiben?
Eine einfache Möglichkeit ist es eine Kopie Ihrer Anwendung in dem Workspace anzulegen.
Allerdings gehören zu Ihrer Anwendung auch ein Datenmodell und die entsprechenden Datenbankobjekte. Diese werden zwischen den einzelnen Releaseständen Ihrer Anwendungen voneinander abweichen.
APEX bietet für dieses Problem eine einfache aber sehr elegante Lösung. Sie können Ihrem Workspace weitere Datenbank-Schemas zuweisen.
Dazu gehen Sie so vor.
1. Melden Sie sich am Administration Service als Admin an.
2. Im Menü finden Sie unter Manage Workspace den Eintrag Manage Schema Assignment.
3. Über Add Schema können Sie nun über einen Wizzard weitere Schemas anlegen.
Hinweis: APEX bietet hier zwei Möglichkeiten. Sie können ein vorhandenes Schema hinzufügen oder ein Neues anlegen. Diese Zweite Version lief in der von mir verwendeten Version auf einen Fehler. Um das Problem zu umgehen, legen Sie also einen User von Hand (z.B. über sqlplus) an und ordnen Sie diesen hier zu.
4. Melden Sie sich wieder als Entwickler an Ihrem Workspace an.
5. Exportieren Sie die Anwendung, die Sie in einem neuen Schema als neues Build/Release anlegen möchten.
6. Importieren Sie die Anwendung und wählen Sie im Import-Wizzard das neue Schema aus.
7. Klicken Sie auf Next >.
8. In diesem Schritt wählen Sie die Option “Install Supporting Objects” = YES.
9. Setzen Sie die Installation fort und folgen Sie dem Wizzard. Dabei werden nun die DDL-Skripte, welche Sie in den Supporting Objects hinterlegt haben, ausgeführt und somit die benötigten Datenbankobjekte in dem neuen Schema erzeugt.
Beitragsreihe
[catlist name=”APEX SCM (Reihe)”]