Verteilt programmieren / Apache aus SVN-Repo spleißen?

[Wursel]

Hallo Forum,

ich habe folgendes Problem, bei dem ich eure Meinung bzw. Tipps bräuchte:

Vor einigen Monaten habe ich ein kleines Intranetprojekt begonnen mit PHP und mysql. Daran habe nur ich entwickelt und der Webserver lief auch lokal auf meinem PC (wamp).

Der Projektumfang ist seit dem stark angewachsen und ich habe angefangen, mit Subversion (SVN) den PHP-Quelltext zu verwalten.

Jetzt ist angedacht, die Webseite auf einem dedizierten Webserver laufen zu lassen (Linux, LAMP). Zudem kommt ab Januar ein Praktikant, der beim Projekt helfen soll. Dieser wird evtl. später übernommen. Ab März kommt zusätzlich noch ein Azubi, der ebenfalls daran arbeiten soll.

Nun stelle ich mir die Frage, wie ich das am besten unter einen Hut bringe. Wie arbeiten wir drei dann an dem Projekt? Und wie bekommt der zentrale Webserver dann den aktuellen stabilen Stand?

Eine Möglichkeit wäre, mit Ecplipse direkt im SVN-Repository zu arbeiten. Dann würden wir drei direkt über den SVN-Server arbeiten. Was haltet ihr davon?

Dann gibt es aber noch das Problem, wie man die Entwickler-Webserver handhabt. Eine Idee von mir ist (falls das möglich ist): Alle drei verwenden den zentralen Webserver. Auf diesem gibt es zwei getrennte (Sub-)Domains. Eine für den stabilen Produktivstand (die Nutzer), die zweite als unstable für die Programmierer.
Kann man man den Apache so konfigurieren, dass dieser die Daten direkt vom SVN-Server holt? Also die HEAD Version für den Entwicklerzweig und die stabile aus einer Revision. Das hätte den Vorteil, dass wenn man z.B. die Revision 30 online stellt und sich dabei ein Problem heraus stellen sollte, dass nicht gleich gelöst werden kann, dann könnte man einfach die Revision 29 eintragen und in Ruhe die Revision 31 vorbereiten.

Oder ist das zu "frickelig" und ich sollte eher lokale SVN-update/SVN-commit verwenden? Dann bräuchte aber jeder einen lokalen Webserver, der dann auf das aktuelle lokale SVN-update zurück greift oder? Und am zentralen Webserver könnte ich dann für die nächste stabile Version immer ein SVN-update ziehen bzw. ein update to revision für eine ältere Version. Ein Vorteil der lokalen Dateien wäre sicherlich eine höhere Geschwindigkeit, wobei das bei uns aktuell noch kein Problem ist.

Viele Grüße,
Yusuf

[Christian Marquardt]

Oder ist das zu "frickelig" und ich sollte eher lokale SVN-update/SVN-commit verwenden?

Der normale Weg, wozu sonst ein SVN?

Dann bräuchte aber jeder einen lokalen Webserver, der dann auf das aktuelle lokale SVN-update zurück greift oder?

Ja, das lokal ausgecheckte

Jeder entwickelt lokal. Änderungen werden eingecheckt. Wer einen broken Head verursacht muss einen ausgeben

Ggf. schau dich nach CIS um

[fanderlf]

Bei uns hat jeder in der Arbeit auf seinem Rechner einen lokalen IIS installiert auf dem normal entwickelt wird. Dazu hat jeder einen Checkout des aktuellen Trunk (also das was letztenendes als Produkt ausgeliefert wird).
Wenn ich nun commite wird unser Build im Continuous Integration System angeworfen. Der baut das ganze Projekt (schaut natürlich auch ob Fehler aufgetreten sind) und packt das dann auf einen dedizierten Server auf dem ein Webserver läuft. Dieser Server sollte möglichst Live nah sein. Wenn ihr kein Release habt, weil es z.B. nur ein internes Tool ist was immer sofort deployed wird, dann kann der Build auch direkt auf diesen Server deployen (ja sowas gibts tatsächlich ).
Wenn ihr mal ein größeres Feature entwickelt was die Live Version teilweise kaputt oder unbrauchbar macht während der Entwicklung, dann kann man in SVN einen Branch erzeugen (Feature Branch). Für diesen steht idealerweise ein separater Build und auch ein separater Test Webserver zur Verfügung.

Das größte Hindernis hierbei kann aber die Struktur des Programms werden. Wenn nämlich ständig alle Leute an derselben Datei rumackern, weil diese 10000 Zeilen Code umfasst (ja auch das gibts wirklich), dann macht die Arbeit so keinen Spaß, weil man mehr Merge Konflikte auflösen muss, als was man wirklich arbeitet

Nur so ein paar Tips von meiner Seite

Gruß
Florian

[Wursel]

Hi,

vielen Dank für eure Antworten! Dann werde ich das auch mal so versuchen, dass jeder lokal einen WAMP bekommt und dort mit seinem aktuellen Import lokal daran arbeitet und regelmäßig/zeitnah seinen Code wieder committed.
Am zentralen Webserver machen wir dann immer wieder einen Import auf das Entwicklerverzeichnis und die Produktivversion kommt aus einer stabilen Revision auch per Import. Vielleicht am Anfang erst mal per Cron-Job nachts (Nightly build).

Ich habe das Projekt bisher so aufgebaut, dass jede Klasse in einer eigenen Datei steckt, die per Autoloader hinzugefügt wird, wenn sie das erste Mal aufgerufen wird. Das dürfte ja dann ein Vorteil sein, wenn mehrere daran arbeiten.

Wie macht ihr das mit dem commit/update eigentlich in der Praxis? Holt ihr euch immer morgens das Update, bevor ihr losprogrammiert und dann am Nachmittag, bevor ihr geht, wieder ein Commit? Oder auch immer wieder zwischendurch, wenn ihr mit etwas fertig geworden seit? Ich mache das momentan immer abends bzw. wenn ich am Tag etwas programmiert habe und fertig bin, dann auch direkt.

Ohne Continuous Integration System müsten wir das dann auf dem Server per Cron-Job machen und danach von Hand durch die Seiten schauen, ob noch alles läuft. Hm... ok das ginge mit so einem CIS vermutlich größtenteils automatisch/bequemer/zuverlässiger. Bekommt ihr dann eine Mail falls ein Fehler auftaucht, damit man gleich danach schauen kann (und einen ausgeben )?

Kennt ihr Tutorials, Bücher, Videos, Podcasts etc. (evtl. auch auf Deutsch), die diese Themen behandeln (Versionierung, CIS, im Team programmieren)? Etwas für den Einstieg. Ich denke es ist jetzt sinnvoll, dass ich mir in paar Grundlagen aneigne, bevor es los geht .

Viele Grüße,
Yusuf