phpbar.de logo

Mailinglisten-Archive

[php] php + sql + cvs

[php] php + sql + cvs

Dr. Volker M. Göbbels php_(at)_phpcenter.de
Fri, 23 Aug 2002 16:44:27 +0200


Hallo,

> Habe leider gestern nicht mehr geantwortet, da ich einen Notfall bei
> einem Kunden hatte :-(

Kein Problem, wenn die Hütte brennt geht das vor ;o))

>> 1. Wie du's schon machst: ASCII Dump fahren und den archivieren
>> 2. Binärdump fahren und über einen CVS Wrapper archivieren
>> 3. Basis-Version als ASCII Dump archivieren und dazu einen Baum der
>>    DB-Migrationsscripte, also der Scripte die die bestehende DB auf den
>>    neuen Stand patchen.
> Das sind auch die Möglichkeiten die mir eingefallen sind. Dabei ist
> Methode 3 die einzig vernünftige, was Rückverfolgung von Änderungen und
> das Auftreten von Seiteneffekten möglichst verhindert. Nur verlangt das,
> wie schon gesagt, einen sehr großen Aufwand und zudem sollten die
> Entwickler auch das manuelle Schreiben von DBA Scripten beherschen und
> nicht nur in DBA Stdiios herumklicken können.

Wer mit Oracle arbeitet sollte da eh etwas beschlagener sein. Sonst gibts
nachher Probleme mit der Applikation ... :->

> Die Methode funktioniert allerdings nicht mit Objekten, wie Stored
> Procedures, Packages und ähnlichem. Dort muß man den Source code
> exportieren und wie ein 'gewöhnliches' PHP Script im cvs behandeln.

Genau das würde man ja auch mit den DBA-Patch-Scripten machen. Wie reinen
ASCII Text archivieren.

> Insgesamt, beinhaltet die Methode aber ein sehr großes Potetial an
> Fehlermöglichkeiten, da der Entwickler sich immer bewußt sein muß nach
> jeder Änderung, sobald sie getestet ist, diese ins cvs zu stellen.

Das stimmt. Solche komplexen Mechanismen verlangen eine genaue Organisation
der Entwicklerteams. Soll heißen:
- Wer ist der DBA?
- Wer darf die Entwickler-DB ändern?
- Wie meldet er diese Änderungen dem DBA?

usw. ... Alles in allem Aufwand ohne Ende ;)

> Meistens, so habe ich die Erfahrung gemacht, werden Änderungen in der
> Datenbank parallel zu Änderungen in der Applikation gemacht und der
> Entwickler muß sich die Änderungen in der Datenbank mitschreiben, damit
> er sie auch nicht vergißt, sobald er die neue Version ins cvs released.

Natürlich. Alles was ein Entwickler tut, muß er dokumentieren. So ging das
in großen Projekten, die ich betreut habe auch:
Man notiert, welche Files man angefaßt hat und welche DB-Änderungen. Das
meldet man der Entwicklungsabteilung, die dann die Releases baut ...

> Ziel ist es ja eine definierte Version der Applikation mit der
> dazugehörenden funktionierenden Version der Datenbank zu haben und diese
> einander zuordnen zu können.

Exakt. Das ist so üblich. Die zugehörigen Programmfiles und
Datenbank-Quellen
werden einfach gleich gelabelt. Dazu gibts bewegliche Developer-Labels und
fixe
Release-Labels etc. Aber das ist ja eh Grundwissen, da brauch ich nicht so
viel
mehr drüber zu erzählen. Und die anderen 578 Mitleser müssen sich nicht
langweilen ;o)

Viele Grüße,
Volker Göbbels
--
Arachnion GmbH & Co. KG  -  Business Communication, Web Development
Gouleystraße 59, 52146 Würselen             http://www.arachnion.de
Dr. Volker M. Göbbels                              vmg_(at)_arachnion.de
Tel. 02405-424770                                  Fax 02405-424772


php::bar PHP Wiki   -   Listenarchive