[SVN] Team-Projekt mit PHP: Wie mache ich das?

[Valle]

Hi DPler!

Ich arbeite mit einem 3-köpfigen Team an einem PHP-Projekt, dass ich nun gerne in ein SVN Repository umwandeln würde. Ich habe schon oft von SVN gelesen und gehört und möchte es nun endlich auch mal benutzen. Ich bin soweit der Meinung, dass ich das Prinzip verstanden habe. Dennoch werfen sich mir ein paar Fragen auf, bezüglich PHP.

Wie testet man die PHP-Dateien? Bisher haben wir alle nur mit Hilfe des FTP-Servers gearbeitet. Dabei wurden Dateien (z.B: auf Syntax-Fehler) getestet, indem wir sie nach dem Upload einfach im Browser aufriefen, entsprechende Fehler behoben und anschließend erneut hochluden. Das kann man bei SVN doch nicht machen, oder? Dann hat man ja mehr fehlerhafte Revisionen als funktionierende...

Wie bringe ich die Dateien zum Web-Server? Die Frage habe ich eigentlich schon so halb beantwortet, möchte aber gerne mal noch nachfragen, falls es da bessere Ideen gibt. Bisher habe ich in irgendeiner Konfigurations-Datei eine "post-commit" Action festgelegt. Die hat nichts anderes gemacht, als im htdocs-Ordner des Apache-Servers eine Kopie zu updaten. (Ich glaube mittels "svn update", bin jetzt aber nicht mehr so ganz sicher) Gibt es da vielleicht bessere Methoden? Man könnte auch export benutzen, damit man die .svn-Ordner nicht im htdocs-Ordner hat, aber dann dauert das Update bei einem commit ja noch länger (Und das Projekt wird schon etwas größer)

Kommen fertige Bibliotheken auch ins Repository? Wir wollen in unserem Projekt das Zend-Framework benutzen. Wer's kennt, der weiß, dass es um die 20 Megabyte groß ist. Wer es nicht kennt weiß es jetzt. *g* Müssen wir das jedes mal wenn wir eine Arbeitskopie erstellen mit runterladen? Wenn nicht, wie handhabe ich das dann am besten im htdocs-Ordner?

Was ist mit der Datenbank? Wir benutzen zum Projekt eine MySQL-Datenbank. Sollte diese einfach über die üblichen Wege (phpMyAdmin) geändert werden? Oder gibt es auch da irgendwelche besseren Möglichkeiten, um Konflikte zu vermeiden?

Ich hoffe ihr könnt mir einige meiner Fragen beantworten.

Edit:// Titel geändert. Klang vorher eher danach, als suche ich Mitglieder... Außerdem eine Frage hinzugefügt.

Mit freundlichen Grüßen,

Valle

[fkerber]

Hi!

Zitat von Valle:

Wie testet man die PHP-Dateien? Bisher haben wir alle nur mit Hilfe des FTP-Servers gearbeitet. Dabei wurden Dateien (z.B: auf Syntax-Fehler) getestet, indem wir sie nach dem Upload einfach im Browser aufriefen, entsprechende Fehler behoben und anschließend erneut hochluden. Das kann man bei SVN doch nicht machen, oder? Dann hat man ja mehr fehlerhafte Revisionen als funktionierende...

Man sollte am besten lokal eine Testumgebung haben und nur Sachen, die auch funktionieren ins Repository stellen. Ansonsten kann man auch eine Art Web-Frontend fürs SVN-Repository aufsetzen und sich dort Dateien im Webbrowser ansehen. Ob das mit PHP-Dateien auch so gut geht, weiß ich leider nicht.

Zitat von Valle:

Wie bringe ich die Dateien zum Web-Server? Die Frage habe ich eigentlich schon so halb beantwortet, möchte aber gerne mal noch nachfragen, falls es da bessere Ideen gibt. Bisher habe ich in irgendeiner Konfigurations-Datei eine "post-commit" Action festgelegt. Die hat nichts anderes gemacht, als im htdocs-Ordner des Apache-Servers eine Kopie zu updaten. (Ich glaube mittels "svn update", bin jetzt aber nicht mehr so ganz sicher) Gibt es da vielleicht bessere Methoden? Man könnte auch export benutzen, damit man die .svn-Ordner nicht im htdocs-Ordner hat, aber dann dauert das Update bei einem commit ja noch länger (Und das Projekt wird schon etwas größer)

Es gibt verschiedene SVN-Programme. z.B. Subclipse, was in Eclipse integriert ist oder TortoiseSVN als eigenständiger Client. Man kann dann lokale Ordner als workingCopy quasi anlegen. Mit svn update bekommt man immer das Neueste vom Server. Mit svn commit kann man selber online stellen. Dann gibt es noch weitere Sachen wie delete, rollback etc...

Zitat von Valle:

Kommen fertige Bibliotheken auch ins Repository? Wir wollen in unserem Projekt das Zend-Framework benutzen. Wer's kennt, der weiß, dass es um die 20 Megabyte groß ist. Wer es nicht kennt weiß es jetzt. *g* Müssen wir das jedes mal wenn wir eine Arbeitskopie erstellen mit runterladen? Wenn nicht, wie handhabe ich das dann am besten im htdocs-Ordner?

Wir haben sowas nicht ins Repository gestellt, sondern quasi einmal dafür gesorgt, dass das ganze lokal läuft und da daran ja nichts entwickelt wird (wenn ich dich richtig verstanden habe), ändert sich da ja auch nichts...


Hoffe, das hilft dir weiter.

Ciao, Frederic

[Valle]

Hallo fkerber!

Zitat von fkerber:

Man sollte am besten lokal eine Testumgebung haben und nur Sachen, die auch funktionieren ins Repository stellen. Ansonsten kann man auch eine Art Web-Frontend fürs SVN-Repository aufsetzen und sich dort Dateien im Webbrowser ansehen. Ob das mit PHP-Dateien auch so gut geht, weiß ich leider nicht.

D.h. ich erstelle meine Arbeits-Kopie einfach im htdocs-Ordner meines lokalen Webservers? Gut, mir fällt das leicht, ich habe einen Webserver hier. Hoffentlich geht das dem Rest aus dem Team auch so. Ich habe noch eine Frage bzgl. der Datenbank oben hinzugefügt, die wird jetzt dadurch besonders relevant, vielleicht kannst du dir das mal noch anschauen, bitte.

Zitat von fkerber:

Es gibt verschiedene SVN-Programme. z.B. Subclipse, was in Eclipse integriert ist oder TortoiseSVN als eigenständiger Client. Man kann dann lokale Ordner als workingCopy quasi anlegen. Mit svn update bekommt man immer das Neueste vom Server. Mit svn commit kann man selber online stellen. Dann gibt es noch weitere Sachen wie delete, rollback etc...

Oh, ich glaube da habe ich meine Frage etwas falsch gestellt. ich weiß, wie ich meine Dateien vom lokalen Rechner auf den SVN-Server kriege. Gemeint war allerdings, wie der Server die Daten zum Webserver kriegt! Das Repository des Servers beinhaltet ja nicht einfach die Dateien, wie sie auch in der Arbeitskopie aussehen, sondern irgendwelches anderes Zeugs. Ich brauch doch aber auf dem Webserver im Internet auch immer eine aktuelle Kopie vom PHP-Projekt, sonst kann ich den Code ja gar nicht benutzten. PHP gehört eben auf einen Server.

Zitat von fkerber:

Wir haben sowas nicht ins Repository gestellt, sondern quasi einmal dafür gesorgt, dass das ganze lokal läuft und da daran ja nichts entwickelt wird (wenn ich dich richtig verstanden habe), ändert sich da ja auch nichts...

Stimmt.

Mit freundlichen Grüßen,

Valle

[alcaeus]

Moin Valle,

wir verwenden in der Firma fuer solche Tests einen Webreader. Dieser checkt nach einem Commit (Stichwort: post-commit-hook) die Working-Copy in ein bestimmtes Verzeichnis aus, in dem die Software laeuft. Ansonsten kann ich Frederic nur zustimmen: immer lokal testen und dann einchecken. Vom trunk wird erwartet, dass wenigstens keine Syntaxfehler drin sind - ein eigener dev-branch kann hingegen das reinste Minenfeld sein.

Vorsichtig muss man bei den lokalen Testumgebungen (und auch beim Webreader) mit Datenbankaenderungen sein - diese muessen ja schliesslich auch in die Testumgebungen uebertragen werden.

Greetz
alcaeus

[Valle]

Zitat von alcaeus:

wir verwenden in der Firma fuer solche Tests einen Webreader. Dieser checkt nach einem Commit (Stichwort: post-commit-hook) die Working-Copy in ein bestimmtes Verzeichnis aus, in dem die Software laeuft. Ansonsten kann ich Frederic nur zustimmen: immer lokal testen und dann einchecken. Vom trunk wird erwartet, dass wenigstens keine Syntaxfehler drin sind

Genau diesen post-commit-hook meinte ich. Also scheine ich das soweit schon richtig gemacht zu habe. Danke!

Zitat von alcaeus:

- ein eigener dev-branch kann hingegen das reinste Minenfeld sein.

Was genau meinst du mit dev-branch? Könntest du mir das evtl. etwas näher erläutern?

Zitat von alcaeus:

Vorsichtig muss man bei den lokalen Testumgebungen (und auch beim Webreader) mit Datenbankaenderungen sein - diese muessen ja schliesslich auch in die Testumgebungen uebertragen werden.

Das heißt wohl, dass jeder Entwickler selbst darauf achten muss, dass er mit der DB nichts durcheinander wirft?

Mit freundlichen Grüßen,

Valle

[fkerber]

Hi!

Mit Datenbank habe ich sowas nie gemacht, die Frage kann ich also nicht wirklich beantworten.

Ob es einen direkten Weg vom SVN-Server zum Webserver geben kann, weiß ich ehrlich gesagt nicht.
Das einzige, was wir mal im Einsatz hatten war eine Art Webfrontend für den SVN-Server - Trac. Da gehören Features wie Ticket-Verwaltung u.ä. dazu und man kann durch das Repository browsen - aber ob damit auch sowas mit PHP-Dateien geht, weiß ich leider nicht.


Ciao, Frederic

[alcaeus]

Moin,

Zitat von fkerber:

Das einzige, was wir mal im Einsatz hatten war eine Art Webfrontend für den SVN-Server - Trac. Da gehören Features wie Ticket-Verwaltung u.ä. dazu und man kann durch das Repository browsen - aber ob damit auch sowas mit PHP-Dateien geht, weiß ich leider nicht.

wir verwenden auch Trac. Du kannst natuerlich auch PHP-Dateien angucken, ausfuehren geht aber nicht. Geschickter ist es echt, eine "Installation" der Software irgendwo laufen zu lassen und per Hook dorthin auszuchecken. Macht definitiv weniger Schwierigkeiten.

Was die Datenbank betrifft: es kann helfen, das Schema und die Grunddaten (Config-Werte, etc.) in einer SQL-Datei im Repository mitzufuehren. Wenn bei einem Update die SQL-Datei aktualisiert wird, muss man lokal (oder im Testbed in das automatisch ausgecheckt wird, aber dafuer ist der eincheckende Entwickler zustaendig) die Datenbank aktualisieren.

Nochwas: eine eventuelle Datenbank-Konfigurationsdatei sollte nicht, aber auch gar nicht ins SVN eingecheckt werden und auch ziemlich schnell per svn:ignore ignoriert werden. Du glaubst nicht wie oft man die Datei aus versehen eincheckt weil man sie lokal angepasst hat

Greetz
alcaeus