Konfigurationsmanagement in Oracle APEX Projekten

Konfigurationsmanagement in Oracle APEX Projekten

Dietmar Aust Opal-Consulting, Deutschland / Köln

www.opal-consulting.de

DOAG SIG Development :: Clean Code :: 22.09.2011 :: Köln

Version 1.0 / 22.09.2011 / D. Aust

Vorstellung Dietmar Aust ► Dipl.-Inform. Dietmar Aust, freiberuflicher Berater

► [email protected]

► http://daust.blogspot.com/

► 1997-2000: Consultant bei der Oracle Deutschland GmbH / Düsseldorf

► Schwerpunkte: Oracle Portal, Oracle Reports, Oracle Forms, PL/SQL, PLSQL Web Toolkit (OWA)

► Seit 09/2000: Freiberuflich

► Schwerpunkte: Oracle Portal, Oracle Reports, Oracle Application Express, Oracle Express Edition

► Seit 2006 ausschließlich APEX Entwicklung

► Entwicklung von Webapplikationen seit 14 Jahren

► Jasper Reports Integration

► Kostenlose Alternative für die PDF – Erstellung in APEX

► http://www.opal-consulting.de/tools

Seite 1

Konfigurationsmanagement in Oracle APEX Projekten Dietmar Aust, 22.09.2011

mailto:[email protected]



http://daust.blogspot.com/

http://www.opal-consulting.de/tools



Vorstellung Dietmar Aust ► Wichtige Applikationen

► AbiT : Absatzerfassung im Telekom Shop

► ShopDB / SPOTS: Shop-Datenbank für die Telekom Shops

► Vorträge

► DOAG Special Interest Day APEX (31.05.2007) − Absatzerfassung im T-Punkt (AbiT)

− Apex auf Oracle Express Edition (XE)

► DOAG 2007 (12.11.2007) − Standortauswahl mit Workflow und Geomarketing; Migration von MS Access

auf Apex 2.2

► ODTUG (New Orleans, 15.06.2008) − Mastering Unreasonable Deadlines with Oracle APEX at the German Telecom

Shops

► DOAG 2008 (01.12.2008) − PDF Erstellung mit APEX - eine kostenlose Alternative

Seite 2


Vorstellung Dietmar Aust ► Vorträge

► ODTUG 2009 (21.06.2009) − JasperReportsIntegration (PDF Erstellung mit JasperReports)

− jXLS (Native Excel Sheets erzeugen mit Excel Templates)

► OOW 2009 (11.10.2009) − JasperReportsIntegration

► DOAG2009 (17.11.2009) − Komplexe Excel Berichte mit APEX und jXLS erstellen

► ODTUG2010 (29.06.2010) − APEX Application Lifecycles: Managing the Change

► DOAG2010 (16.11.2010) − Der Lebenszyklus einer APEX Applikation: Managing the Change

Seite 3


Vorstellung Dietmar Aust ► Oracle APEX und XE in der Praxis

► Erschienen am 21.12.2009

► Autoren:

► Denes Kubicek

► Jens-Christian Pokolm

► Dietmar Aust

Seite 4


Vorstellung Dietmar Aust ► Expert Oracle Application Express

► Erschienen am 25.05.2011

► Charity Projekt für Carl Backstrom und Scott Spadafore (verstorbene Mitglieder aus dem APEX Team)

► Autoren:

► Dietmar Aust (Kapitel 9: Lifecycle Management)

► Martin Giffy D'Souza

► Doug Gault

► Dimitri Gielis

► Roel Hartman

► Michael Hichwa

► Sharon Kennedy

► Download der Skripte für Kapitel 9:

► http://www.opal-consulting.de/tools

Seite 5


► Denes Kubicek

► Raj Mattamal

► Dan McGhan

► Francis Mignault

► Anton Nielsen

► John Scott




Agenda

► Die Problemstellung

► Warum?

► Das Hintergrund-Projekt

► Die Herausforderungen

► Das Verfahren

► Wesentliche Randbedingungen / Grundsätze

► Die Bestandteile: Projektmanagement, Versionskontrolle, Namenskonventionen

► Rollout von A-Z

► Patch-Erstellung

► Installation im Testsystem

► Installation in der Produktion

► Tipps

Seite 6


Die Problemstellung Warum? ► Jeder benötigt ein gut strukturiertes Konfigurationsmanagement und

Lebenszyklus-Management für Applikationen

► Wenn es fehlt, sind die Kosten hoch und leider gut versteckt

► Es ist nicht leicht, eine gute Strukturierung zu finden

► Keine Standards in der Oracle Community, die Java Community hat sich anscheinend auf Maven verständigt

► http://maven.apache.org

► Ursprung: Verzeichnisbäume und Abläufe in den diversen Apache Projekten waren zu unterschiedlich => Entwickler konnten nicht einfach zwischen den Projekten wechseln

► Basiert technologisch auf ANT für das Build Management von Java Applikationen (ursprünglich)

► Umsetzung des Grundgedankens: “Konvention vor Konfiguration”

► Standard-Verzeichnisstruktur

► Viele Artefakte (Source Code bzw. Dokumentation) werden generiert.

Seite 7


http://maven.apache.org/

Die Problemstellung Das Hintergrund-Projekt

► Entstanden im Projekt “SPOTS” bei der Telekom Shop Vertriebsgesellschaft mbH, dem Shop-Informationssystem

► Das Konzept ist innerhalb der letzen vier Jahre entstanden und wird kontinuierlich weiterentwickelt

► Komplexität

► 2-3 Entwickler seit 05/2007

► 200 Tabellen, 100 Packages, 3000 Datenbank-Objekte

► APEX Applikation mit 140 Seiten

► Tablespace-Namen sind identisch auf Entwicklung, Abnahme und Produktion !!!

► Releases

► Vier Releases pro Jahr

► Durchschnittlich 100 (50-250) geänderte / neue Objekte

► Normalerweise vier interne Revisionen mit dem Test-Team

Seite 8


Die Problemstellung Herausforderungen

► Gleichzeitiges Arbeiten an Datenbank-Packages, Prozeduren, Views, etc.

► Änderungen werden gegenseitig überschrieben

► Vollständige Propagation aller Änderungen über Entwicklung, Abnahme und Produktion sicherstellen

► Jede Änderung an der Software sollte identisch auf die Abnahmesysteme und Produktion verteilt werden können

► Sollte komplett skriptbasiert sein, damit Fehler durch manuelle Vorgänge reduziert werden

► Es muss sichergestellt werden, dass alle Änderungen propagiert werden (DDL, DML, APEX, Konfigurationsdateien, etc.)

► Gleichzeitige Entwicklung unterschiedlicher Versionen (klassisches Branching / Merging)

► Z.B. Korrekturen an der aktuellen Produktionsversion (Hotfixes) während gleichzeitig die nächste Version entwickelt wird.

► Propagation einer Änderung in alle Branches der Software

Seite 9



► Aktueller Status / Version unklar

► Installationsdateien

► Applikationsdateien: APEX, JS, CSS

► Applikationsversion im Datenbank-Schema (Entwicklung, Abnahme, Produktion) ?

► Wurde das Skript xyz bereits im Datenbank-Schema abc ausgeführt?

► Wann wurde welche Version installiert?

► Das aktuelle Datenproblem in der Produktion … wann ist es entstanden und wurde es eventuell bereits durch einen Patch behoben?

► Dokumentation aktuell halten

► Dokumentation des aktuellen Releases (meist Änderungen) wird meistens gemacht, die Gesamtspezifikation veraltet schnell

Seite 10



► Antworten auf die üblichen Fragen im Projektalltag, um die Abläufe zu organisieren

► Letztendlich muss der Entwickler Auskunft geben können:

► Was ist der aktuelle Umfang des Releases?

− Must / Should / Could / Won‟t

► Wer implementiert welche Funktionen?

► Was sind die offenen Punkte / Fragen an die Fachabteilung?

► Wie hoch war die Schätzung für jede Anforderung?

► Welche Anforderungen wurden in dieser Version / Patch implementiert?

► Liegen wir in der Zeit / im Budget?

► Wir verspäten uns … warum?

Seite 11


Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Versionskontrolle: Lokale Sandbox vs. Shared Instance

► Lokale Sandbox: Dies ist das am meisten verbreitete Verfahren, um im Team mit Versionskontrolle zu entwickeln:

− Jeder Entwickler verwendet eine lokale Datenbank-Instanz, die Synchronisation erfolgt über ein zentrales Source Code Repository

► Shared Instance: Alle Entwickler programmieren in derselben Datenbank-Instanz

► Warum funktioniert die Lokale Sandbox nicht für SQL und APEX?

► Tabellen können nicht einfach mit der neuen Version der Struktur „überschrieben“ werden, alter table add / drop column – Statements sind notwendig.

► Zu jeder Änderung müsste ein Entwickler ein Synchronisations-Skript schreiben, so dass seine Kollegen ihre lokalen Datenbanken aktualisieren können. Funktioniert gar nicht, wenn lokal eine widersprüchliche Änderung gemacht wurde (z.B. kann ein lokales Constraint ein DML Statement verhindern).

► Funktioniert schlecht mit größeren Datenbeständen oder mehreren Schnittstellen.

Seite 12


Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Warum funktioniert die Lokale Sandbox nicht für SQL und APEX?

► APEX für technisches Branching / Merging ungeeignet

► APEX ist stark (relational) metadaten-getrieben, die jeweiligen Schlüssel (IDs) werden im Applikations-Export referenziert.

► Bsp.: Definition einer Werteliste:

► Wird beim Import die Applikations-ID geändert, ändern sich auch alle IDs der Objekte, dies kann nicht mehr rückgängig gemacht werden.

► Die ID einer Seite (APP_PAGE_ID) kann nachträglich nicht mehr geändert werden

► Bsp.: Page 11 wird in beiden Instanzen unabhängig voneinander angelegt, inhaltlich unterschiedlich. Was passiert, wenn die Seiten per Merge zusammengefügt werden?

► => Auch auf die Abnahmesysteme und die Produktion werden keine Applikationsteile propagiert, sondern immer das vollständige Applikationsfile (findet innerhalb einer Transaktion statt).

Seite 13


wwv_flow_api.create_list_of_values (

p_id => 5017504088986621 + wwv_flow_api.g_id_offset,

p_flow_id => wwv_flow.g_flow_id,

p_lov_name => '1_0',

p_lov_query=> '.'||to_char(5017504088986621 + wwv_flow_api.g_id_offset)||'.');

Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Servergestaltung - Entwicklung / Abnahme / Produktion?

► Normalerweise drei Umgebungen

► Für parallele Weiterentwicklung und Hotfixes der Produktion

Seite 14


Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Grundlegende Überlegung / Restriktion

► Die interaktiven Berichte verlieren die persönlichen Einstellungen, wenn sich die Applikations-ID geändert hat:

− http://dpeake.blogspot.com/2009/01/preserving-user-saved-interactive.html

− http://joelkallman.blogspot.com/2010/07/where-did-my-saved-interactive-reports.html).

► Konsolidierung der Umgebungen

1. Erstellung von Skripten und Dateien für das aktuelle Release

2. Installation der Skripte der Entwicklung in der Abnahme

3. Durchführung der Tests und Abnahme

4. Installation der Skripte der Entwicklung in der Produktion

Seite 15


http://dpeake.blogspot.com/2009/01/preserving-user-saved-interactive.html







http://joelkallman.blogspot.com/2010/07/where-did-my-saved-interactive-reports.html











Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Speichern von Dateien auf dem Application Server

► Nicht das /i/ - Verzeichnis von APEX nutzen! − Erschwert die Migration auf eine neuere APEX Version

► Eventuell verwendet APEX in späteren Releases dieselben Verzeichnisnamen bzw. Dateinamen => Namenskonflikte !

► Besser: Eigenes virtuelles Verzeichnis anlegen, z.B.:

► /apex_custom/

► /apex_custom/<applikation1>

► /apex_custom/<applikation1>/<theme1>

► /apex_custom/<applikation1>/<verwendete Bibliothek1>

► Alle referenzierten Dateien für die Applikation sollten in /apex_custom/<applikation1> (oder im Workspace) gespeichert werden:

► Erleichtert den Umzug auf einen anderen Server

► Seiteneffekte werden reduziert, wenn eine zentrale Bibliothek geändert wird. Oftmals können nicht alle betroffenen Applikationen gleichzeitig getestet werden, sondern werden nacheinander aktualisiert und getestet.

Seite 16


Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Die „Quellsysteme“ (normale Entwicklung, Hotfix-Entwicklung) müssen

die APP_ID der Produktion verwenden.

► Bei den Abnahmesystemen kann die APP_ID geändert werden.

► Branching und Merging von APEX Bestandteilen sollte manuell erfolgen

► Neue Seiten können später kopiert werden

► Seitenbereiche für die verschiedenen Applikationsbereiche vereinbaren, sonst wird z.B. in beiden Applikationsversionen inhaltlich unterschiedliche Seiten mit der Nr. 11 angelegt.

Seite 17


Das Verfahren Wesentliche Randbedingungen / Grundsätze ► Workspace ID auf allen Systemen identisch einrichten

► Vereinfacht die skriptbasierte Installationen per SQL/Plus

► Wie geht das?

► Export der Workspace Definition über Home > Application Builder > Exportieren

► Import im Zielsystem − Anmelden an der internen Workspace Administration: /apex/apex_admin

− Home > Workspaces verwalten > Workspace importieren

► Package APEX_APPLICATION_INSTALL (ab APEX 4.0)

► Ermöglicht skriptbasierte Installation, auch wenn Workspace-ID, Applikations-ID oder der Parsing User im Applikations-Export anders definiert ist.

Seite 18


Das Verfahren Die Bestandteile - Projektmanagement

• Datenbank

• Dateien

• APEX

• Wenig Raum für Fehler

• Subversion

• TortoiseSVN

• Scope

• Bugs / Issues

• Budget!

• Zeiterfassung!

Project Management

(PJM)

Versions-Kontrolle

Namens-Konventionen

Strikte Anweisungen für die Patch-

Erstellung

Seite 19


Das Verfahren Die Bestandteile - Projektmanagement ► Projektmanagement – Applikation, um den Scope zu verwalten

► Leichtgewichtig, als Werkzeug für Entwickler

► Excel-Sheets schnell ungeeignet

► Relevante Funktionen

► Welche Anforderungen wurden in Version xyz umgesetzt?

− Ein vollständige Liste einfach erstellen

− Wir arbeiten an der Spezifikation online im Tool, während wir mit der Fachabteilung diskutieren

− Wir exportieren die Detailspezifikation und importieren sie in ein Word-Dokument für das aktuelle Release, nur die Use Cases werden manuell überarbeitet.

► Budgets, Schätzungen und Zeiterfassung integriert

► Meilensteine

► Offene Punkte, einfach eine Liste für das nächste Meeting mit der Fachabteilung erstellen

Seite 20


Das Verfahren Die Bestandteile - Projektmanagement ► Demo:

► PJM Anwendung

− Ein Werkzeug für Entwickler

− Die nächsten Meilensteine

► Anforderungen

− Unter-Anforderungen, Aufwandsschätzungen, etc.

− Offene Punkte für das nächste Kundenmeeting erstellen

− Implementierte Funktionen in Revision 1?

► Zeiterfassung

− Ungeplante Aktivitäten

− Tätigkeitsnachweis im Format des Kunden exportieren

Seite 21


Das Verfahren Die Bestandteile - Versionskontrolle

• Datenbank

• Dateien

• APEX


• Subversion

• TortoiseSVN • Scope

• Bugs / Issues

• Budget!

• Zeiterfassung!

Project Management

(PJM)

Versions-Kontrolle

Namens-Konventionen


Erstellung

Seite 22


Das Verfahren Die Bestandteile - Versionskontrolle

► Subversion + TortoiseSVN

► http://tortoisesvn.net

► Integration im Windows Explorer

► Überlagerte Icons, Kontext-Menüs

► Versionskontrolle der Datenbank-Objekte

► Den einfachen Checkin-Checkout Mechanismus in Quest Toad verwenden

► Objekt exklusiv sperren für die Bearbeitung

− Andere Entwickler können danach über das GUI dieses Objekt nicht mehr ändern.

► Objekt direkt in der Datenbank verändern

► Die modifizierten Objekte werden sofort im Patch-Skript registriert

− Nur für “echte” DDL-Statements, z.B. “alter table add column”

− Für den Rest (Packages, Views, Trigger) leere Dateien (Am Ende wird das vollständige DDL generiert)

► Sperre entfernen

Seite 23


Das Verfahren Die Bestandteile – Namenskonventionen (Datenbank)

► Vorstellung einiger Highlights …

► Packages

► CGUD Konvention für Funktionen / Prozeduren

− create, get, update, delete

► Separate Packages für die Geschäftslogik und das User-Interface (UI)

► Packages der Geschäftslogik

− Können automatisiert getestet werden

► UI-packages

− Spezifische Logik nur für die APEX Applikation

− Link auf andere Seite generieren

− Seitenvalidierungen, die Session State referenzieren (v(„P5_ID‟)) oder Collections verwenden

Seite 24


Das Verfahren Die Bestandteile - Namenskonventionen (Datenbank)

► Präfix-Notation für alle Spalten

► Alle Spalten bekommen den Tabellen-Alias als Präfix

► Einfluss auf Views, APEX Seitenelemente

− => TRANSPARENZ !!!

► Beispiel: Ein APEX Formular basierend auf der View FM_BOOKINGS_RL_V

− Eine Referenz auf Element P5_ID muss erklärt werden

− Referenzen auf P5_BOOK_ID oder P6_USR_ID sind transparent und selbsterklärend

− Es gibt keinen Unterschied zwischen dem Datenmodell und Applikations- Elementen mehr

Seite 25


Das Verfahren Die Bestandteile – Namenskonventionen (Dateisystem)

► Layout des Dateisystems - SRC

► Quelldateien

− Organisation nach Quelltyp, dann Modul oder Schema

► src

− apex (alles, was in den Workspace importiert wird)

− static_file, image, css, plugin

− apex_custom (virtuelles Verzeichnis auf dem Webserver)

− sql

− schema1

− schema1_generated (exportierte Sourcen)

− schema2

− schema2_generated

Seite 26


Das Verfahren Die Bestandteile - Namenskonventionen (Dateisystem)

► Layout des Dateisystems - PATCH

► Versionen:

− Major.Minor.Patch.Revision

− Nur die ersten drei kommunizieren

► patch (neues Software Release)

− 1.0.0.0

− apex

− sql/schema1

− sql/schema2

− 1.0.0.1

− 1.0.0.2

Seite 27



► Layout des Dateisystems – PATCH_DATA

► patch_data

− (nur DML, insert, update, delete)

► Noch nicht final, aber

− Alle Patches sind nach Datum aufgeführt und unter Versionskontrolle

− Jede Ausführung wird in der Datenbank registriert

Seite 28



► Namenskonventionen für alle Dateien

► In den meisten Fällen: <objektname.sql> (z.B. für Tabellen, Views, Trigger, Fremdschlüssel, Typen, Prozeduren, Funktionen)

► Ausnahmen: (Packages oder Typen, diese haben jeweils eine Spezifikation und einen Body)

− Package_name.pks

− Package_name.pkb

► Alle Dateinamen sind in Kleinbuchstaben => können auf Windows und *nix Systeme ausgeführt werden

► Data manipulations scripts: <table_name>_data.sql

− Insert, Update, Delete

− Insert into FM_BOOKINGS => fm_bookings_data.sql

Seite 29



► Namenskonventionen für alle Dateien

► Einfach, Änderungen zu finden

− Wann haben wir die Konfigurationstabelle geändert?

− dir /s xlib_conf_values_data.sql

− Wann haben wir die Spalte xyz an die Tabelle shdb_standorte angefügt?

− dir /s shdb_standorte.sql

Seite 30


Das Verfahren Die Bestandteile – Patch Erstellung

Seite 31


• Datenbank

• Dateien

• APEX


• Subversion

• TortoiseSVN • Scope

• Bugs / Issues

• Budget!

• Zeiterfassung!

Project Management

(PJM)

Versions-Kontrolle

Namens-Konventionen


Erstellung

Rollout von A-Z Übersicht

Seite 32


Patch initialisieren

Änderungen durchführen

Patch finalisieren

Installation im Test-System

Dokumente aktualisieren

Installation in der

Produktion

Multiple Iterationen für das interne Testen

Rollout von A-Z Patch initialisieren

► Neues Patch-Verzeichnis über eine Vorlage neu erstellen (Zip-Datei oder ANT Skript)

► Patch 1.0.0.x als Kopie des TEMPLATE-Verzeichnisses

► Versionsnummer im Patch-Skript _patch.sql anpassen

Seite 33



► Versionsnummer in der APEX Applikation erhöhen

Seite 34



► Den Platzhalter #APP_VERSION# im Footer des Seitentemplates referenzieren

► Danach sieht man die aktuelle Version unten links in der Applikation

Seite 35


Rollout von A-Z Änderungen durchführen

Seite 36




Patch finalisieren



Installation in der

Produktion



Seite 37


► Eine Tabelle mit TOAD ändern und das SQL dazu anzeigen lassen

► Die Datei fm_bookings.sql im Verzeichnis sql/test speichern und in der Datei _patch.sql referenzieren


► Wenn andere Objekte geändert werden, so müssen diese einfach nur in der _patch.sql Datei registriert werden.

► Packages, Views, Prozeduren, Trigger und andere Objekte können vollständig aus der Datenbank generiert werden.

► Daher reicht die Erstellung leerer Dateien als Merkhilfe, später werden die generierten Dateien dann nur in das Patch-Verzeichnis kopiert

Seite 38



► Das _patch.sql Skript legt die Reihenfolge fest, in der die Objekte installiert werden müssen

► Typen, Tabellen, Fremdschlüssel, Views, Prozeduren, Funktionen, Package Header, Package Bodies, Trigger, DML-Skripte, andere Skripte

► Alle Skripte innerhalb eines Abschnitts werden in alphabetischer Reihenfolge aufgeführt

► Ist vorteilhaft für Subversion, vereinfacht das Zusammenführen von unterschiedlichen Versionen (Merge) und verursacht so weniger Konflikte

► Erhöht die Transparenz und Übersicht

► _patch.sql Skript zeigen

Seite 39



► Demo

► Spalte in Tabelle FM_BOOKINGS hinzufügen

− BOOK_CAN_BE_CANCELED_UNTIL

► Spalte in View FM_BOOKINGS_RL_V hinzufügen

► Package FM_BOOKING anpassen

Seite 40


Rollout von A-Z Patch finalisieren

Seite 41




Patch finalisieren



Installation in der

Produktion



► Die Datenbank-Objekte in das Dateisystem spoolen (erneut)

► Subversion wird die Änderungen automatisch hervorheben

► Die Dateien werden dann manuell in das Patch-Verzeichnis kopiert

Seite 42



► Export der APEX Applikations-Exportes als Datei mit Versionsnummer:

► f20100629_alm_demo_v1.0.0.4

► Alle anderen relevanten Dateien (CSS, Bilder, etc.) in das Patch-Verzeichnis kopieren

Seite 43



► Demo

► Die Datenbank-Objekte erneut in das Dateisystem spoolen

► Die geänderten Dateien kopieren

Seite 44


Rollout von A-Z Installation im Testsystem

Seite 45




Patch finalisieren



Installation in der

Produktion



► Den Patch im Testsystem installieren

► Restore Point für Flashback-Database setzen

− SELECT name FROM v$restore_point;

− create restore point BEFORE_REL_1_0_0_4;

► Patch installieren

► Falls erforderlich, Datenbank mit Flashback zurücksetzen

− shutdown immediate;

− startup mount;

− flashback database to restore point BEFORE_REL_1_0_0_4;

− alter database open resetlogs;

► Nach erfolgreicher Testdurchführung dann den Restore Point löschen

► drop restore point BEFORE_REL_1_0_0_4;

Seite 46



► Nach mehreren Iterationen ist das Skript fertig getestet

► Setzen des Restore Points

► Installation des Patches

► Korrektur des Skriptes

► Zurückkehren zum Restore Points

► Erneute Installation des Patches

► Der aktuelle Zustand im Dateisystem (Verzeichnis src/sql/test_generated) wird in Subversion committed, so dass wir beim nächsten Patch die Änderungen im Dateisystem erneut sehen können

Seite 47


Rollout von A-Z Dokumente aktualisieren

Seite 48




Patch finalisieren



Installation in der

Produktion



► Die aktuelle Version des Patches wird registriert in der Konfigurationstabelle

► Release Historie wird im Betriebshandbuch und / oder den Release Notes hinterlegt

Seite 49



► Die neuen und geänderten Use Cases des aktuellen Releases werden in das zentrale Dokument aller Use Cases integriert

► Ausschliesslich Copy/Paste, keine manuelle Integration

► Der Vorgang ist in 30 min. abgeschlossen

► Die technische Systemdokumentation sollte vollständig generiert werden

► Das Datenmodell aus dem Data Dictionary (Tabellen- und Spaltenkommentare verwenden!)

► Die APEX Applikation aus dem APEX Dictionary

► Die Datenbank-Packages mit pl/doc

Seite 50


Rollout von A-Z Installation in der Produktion

Seite 51




Patch finalisieren



Installation in der

Produktion


Rollout von A-Z Installation in der Produktion

► Checkliste vorher erstellen und einfach abarbeiten – Keine kreative Freiheit und an nichts denken müssen !!!

► Die aktuelle APEX Applikation exportieren

► Backup der Datenbank erstellen oder Restore Point for das Datenbank-Flashback setzen

► Sobald _patch.sql ausgeführt wird, wird die Applikation offline gesetzt

► Der Zugriff wird eingeschränkt auf registrierte IP-Adressen (oder wenn die Applikation nach Anmeldung am Workspace ausgeführt wird)

► Nach der Installation intern mit verschiedenen Benutzern testen.

► Nach der finalen Freigabe wieder für alle Benutzer freischalten

Seite 52


Tipps

► Jede Ausführung eines Skriptes muss in der Datenbank registriert werden (im Ziel-Schema)

► Alle Skripte sollten prinzipiell mehrfach ausgeführt werden können (und dann auf Fehler laufen, z.B. durch Unique Key Constraints)

► Adaptiver Code

► Wird ausgeführt in Abhängigkeit vom Instanztyp, keine verschiedenen Versionen für Entwicklung, Test und Prod!

► Tabelle xlib_conf_values enthält Konfigurationsparameter instance_type := DEV | TEST | PROD

Seite 53


Tipps

► Alle Dinge brauchen eine Ordnung!!!

► Nummerierung der Anforderungen, Use Cases, Menüeinträge, …

► Die Sortierung erfolgt in alphabetischer Reihenfolge

► Hilft Subversion beim automatischen Zusammenführen von Versionen (Merge), weniger Konflikte

► Mehr Übersicht => die Dinge sind einfacher zu finden

► Apache Rewrite Regeln verwenden, um sprechende URLs für die Anwender zu erstellen

Seite 54


Q&A

► Kontakt:

► Opal-Consulting Dietmar Aust

► Web: http://www.opal-consulting.de

► Blog: http://daust.blogspot.com/

► E-Mail: [email protected]

► Nächste Best Practice Schulung 24.10-26.10.2011

Q & A

Seite 55


http://www.opal-consulting.de/



http://daust.blogspot.com/




Documents

Konfigurationsmanagement in Oracle APEX Projekten