DseWiki: ProjektStrukturImCvs

Meine Projekte starten meist mit folgender Directory Struktur:

projekt -- das Projekt Root Verzeichnis

classes -- da kommt compiliertes rein

: compile -- die produktiven Klassen
: test -- die Test Klassen

lib -- benötigte libraries

code -- der Sorcecode

: src -- produktiver Sourcecode
: test -- Sourcecode für Tests

db -- db - scripte

Und daran schliesst sich auch gleich meine Frage an: Ich verwende in meinem aktuellen Projekt auch eine Datenbank. Die DatenbankStruktur? ist leider sehr eng mit der ModelStruktur? verwoben, d. h. die Java Sourcen hängen unmittelbar von der DatenbankStruktur? ab.

Wie kann ich CVS dazu benutzen, die Datenbank-Scripte sinnvoll zu verwalten ?

Die in meinem Projekt bisher praktizierte Lösung war, für jedes Feature die nötigen Patches in einer eigenen Datei zu speichern. Dadurch wird es sehr schwirig,

zu deployen (installierte Versionsstände müssen ermittelt werden und dann müssen die angepassten FeatureScripts? in der richtigen Reihenfolge deployt werden).
geziehlt eine Datenbankstruktur für Tests zu erzeugen.
weil die Entwicklungsreihenfolge der Features nicht mehr eindeutig aus dem CVS zu ermitteln ist.

Ich hab mir deshalb überlegt (analog zu JavaSourceFiles?), Das StrukturScript? jeder DatenbankTabelle? in einem eigenen File zu verwalten und alle Patches, die während der Entwicklung dazukommen, sequentiell in diese Datei zu schreiben. Auch das hat Nachteile:

Ich muß explizit eine Reihenfolge (Strukturscripte, Trigger & Proceduren, Daten-/Transformationsscripte) definieren.
Ich benötige Tools um Patches zum Deployment zu erhalten.

Anm: deployen heißt: Applikation (beim Kunden) herunterfahren, Patches (Software / DB) ausliefern & installieren, Configuration anpassen, Applikation wieder starten.

Wie geht Ihr mit dieser Problematik um ?

Einige der von dir verwendeten Begriffe sind mir nicht ganz klar. Was genau meinst du z. B. mit "deployen"? Ich bin gewohnt, unterschiedliche Dinge wie Datenbankentwicklung und Anwendungsentwicklung in unterschiedliche Module zu packen. Eine Releasebaseline setzt sich dann aus den einzeln getaggten Modulen zusammen.

Zum Thema Reihenfolge der Skripte wäre ein naheliegender Vorschlag, diese in Form eines Masterskripts festzulegen. Das Masterskript kann die Reihenfolge durchgehen und in der Datenbank checken, ob das jeweils nächste Skript bereits ausgeführt wurde. Bei jedem nichtausgeführten Skript oder ab dem ersten nicht ausgeführten Skript kann dann das Masterskript andere Skripte aufrufen. Du siehst, ich setze voraus, dass die Skripte sich in einer Datenbanktabelle eintragen, die dann vom Masterskript analysiert wird. -- SaschaDördelmann

Sobald ich einen funktionierenden Weg 'von Hand' gefunden habe, werde ich über eine Automatisierung nachdenken. Wobei sich dein Vorschlag gut anhört :-)