phpbar.de logo

Mailinglisten-Archive

[php] OT: CVS, Subversion ....

[php] OT: CVS, Subversion ....

"Dr. Volker Göbbels" goebbels at gmx.de
Mon Jul 5 22:10:56 CEST 2004


Aloha ;)

>hab mich nun schon seit längerer Zeit immer mal 
>wieder mit CVS, Subversion und Konsorten 
>auseinander gesetzt und bin auch immer wieder 
>einen Schritt zurückgegangen (will heissen 
>setzte momentan keines ein).

Oha ;)

>Nun zu der Frage was benutzt ihr so für den 
>Webbereich also php, mysql html, javascript und 
>was noch alles geht.

Das kommt auf die Anforderungen an:
- Kleine Projekte ohne besondere Prozessmodelle: CVS
- Mittlere Projekte mit besonderen Code Policies etc.: Surround SCM
- Große Projekte: IBM/Rational ClearCase

Letzteres aber nur für wirklich _große_ 
Geschichten. Weniger was die Anzahl Entwickler 
oder Codezeilen angeht sondern eher was die 
Anforderungen betrifft:
- Wenn ich neben reinen Scripten auch compilierbare Dinge ablegen muß.
- Wenn ich Entwicklungsbusinessprozesse habe, die 
kontrollierte Change Sets und/oder Baselining 
benötigen.
- Wenn der Entwicklungsprozess dem Rational 
Unified Process oder einem ähnlichn 
Verfahrensmodell folgen soll.
- Wenn ich versionierte Verzeichnisse oder Object Wink-Ins benötige.

Vieles von dem kann auch Surround SCM recht gut.

Subversion hab ich bisher noch nicht eingesetzt, 
weil es nichts von dem kann, was die größeren 
Systeme können und nichts extra bietet was ich 
nicht auch bei CVS habe.

>Ganz speziell gehts mir darum wie Ihr die 
>Strukturen aufbaut. Ich finde es halt immer ein 
>wenig lästig nich gleich ne Vorschau von den 
>geänderten Sachen zu bekommen bzw. es alles 
>lokal laufen zu lassen da meine LAMP konfig doch 
>häufig von den Standardprovidern abweicht.

Um die Notwendigkeit, Entwicklungssystem und 
Produktivsystem zu trennen kommst du ab einem 
minimalen QM-Verständnis nicht herum ;)
Bei mir ist das der (zugegebenermaßen üppig 
konfigurierte) Laptop (PowerBook 17")

>Gibt es nicht etwas wo das Repository auf nem 
>online Server läuft beim commiten der Daten 
>allerdings gleich die Files in einen "zweiten" 
>Ordner schiebt so das man sich die Seiten auch 
>gleich anschauen kann?? Vielleicht war ich auch 
>einfach nur zu blöd das ganze zu begreifen ;)

Solche Automatismen sind möglich. Und zwar mit so 
gut wie allen Systemen. Bei CVS würde man ins 
commitinfo was einhängen, bei den anderen würde 
man post-Checkin-Trigger einführen.

>Das zweite wichtige wäre ob es eine Möglichkeit 
>gibt in einem Atemzug auch 
>Datenbankveränderungen mit zu protokollieren. 
>Ist nicht selten passiert das ich dann doch die 
>ein oder andere Spalte bei Tabellen update 
>vergessen habe und mir dann den Wolf gesucht 
>haben.

Datenbanken werden in 2 Teilen versioniert:
1. Das DB Schema
Das kann als SQL File oder in Form der Dateien 
des jeweils präferierten DB-Modelling Tools. 
Empfehlenswert sind hier Tools, deren generisches 
Format ASCII/XML-basiert ist(DBDesigner, Dezign 
for Databases), weil man hier den Commits 
ansieht, was sich getan hat. Negativ fallen Tools 
wie ERwin auf, die ihre Modelle in binäre Formate 
speichern.

2. Basis- und Testdaten
Hier würde ich keine tabellarischen Dumps oder 
CSV Files sondern saubere insert-Statements 
abspeichern.

Zusätzlich empfehle ich noch den Einbau von 
Triggern oder commitinfo-Prozessen, die:
a. für die Codequalität sorgen, indem sie ein php 
-l oder ähnliches auf den Eincheck-Kandidaten 
loslassen.
b. Mails mit brauchbaren Diffs an den/die 
entwickler verschicken. Hier ist insbesondere 
CVSspam zu loben ;)

CVSspam kann man sogar dazu bringen, interaktive 
Links in die Mails aufzunhemne, die direkt auf 
einen zugehörigen Bugreport in Bugzilla verweisen.

So, das reicht an "Best practice" Geschwalle fürs erste denk ich ;)

Viele Grüße,
Volker Göbbels
-- 
Dr. Volker Göbbels					 vmg at arachnion.de
Arachnion GmbH & Co. KG				  http://www.arachnion.de
Sandkaulbach 4				        Tel. ++49 (0) 241 5591106
52062 Aachen					 Fax ++49 (0) 241 5591107

php::bar PHP Wiki   -   Listenarchive