Einrichten Multi-Developer/Redakteur/Versionierung Umgebung

Ich bin auf der Suche nach allerlei Infos zur Einrichtung fuer gute Entwicklungsumgebung fuer Webdevelopment-Bereich.

Grob meine ich damit Developing, Staging, Live-Systeme, Sourcecode Versionierung, was einem nicht noch alles einfaellt.

Server-Systeme sind Linux, Client-System WXPPro.

Idealerweise wird der Source-Code lokal ausgecheckt und wenns funktioniert wieder eingecheckt. Knackpunkt Webdevelopment: jeder braucht eine lokale Webserver-Instanz, zur Not auch eine Datenbank. Dann wirds schon wieder komplexer. Da an mehreren Projekten gearbeitet wird, muessen lokal also mehrere VirtualHosts funktionieren. Noch ein eck komplexer. Jeder Entwicklung muss sich einmal alles einrichten beim ersten mal. Man koennte sagen, einmal die Konfigurationen machen und auf allen Entwickler-Rechnern einspielen. Aber trotzdem eine zache Sache, wenn sich was aendert.

Dann gibts noch das auschecken des Source-Codes auf den Entwicklungsrechner direkt, wo jeder jeden Code aendern kann und auch einchecken kann. Server- und Datenbankinstanz sind das Developmentsystem, d.h. keine per-Entwickler konfiguration notwendig. Nachteil: zwei Leute am selben File arbeiten geht nicht, man muss sich absprechen. Hier gehe ich davon aus, dass bei lokalem checkout eines Entwicklers das Versionierungssystem ein intellligentes Merge besitzt bzw. bei Konflikten den Entwickler notified.

Bei dem ganzen gibts jetzt aber noch kein Staging-System. Ich sehe das Staging-System zwischen Developing und Live-System. Andererseits denke ich mir, ich mache das Development-System automatisch zum Staging-System, wenn die Entwickler alle direkt auf einer File-Ebene arbeiten. Denn wenn jeder lokal Arbeitet, hat jeder ein lokales Entwicklungssystem, prueft seine Aenderungn auf funktionalitaet vor dem einchecken und beim einchecken werden die Aenderungen aufs Staging-System uebernommen.

Dann habe ich noch die Gruppe von Leuten, die keine Entwickler sondern Redakteuere sind. Historisch gewachsen muessen diese aber direkt Zugriff auf zumindest HMTL-Sourcen haben. HTML- und PHP ist im Datiesystem wild gemischt, eine klare Trennung nicht moeglich. Ein Redakteur hat andere Kenntnisse als ein Entwickler. Einem Redakteur kann man nicht mit einem File-basiertem Versionierungssystem konfrontieren. Auf welchem System sollen Redakteuere dann arbeiten? Ein eigenes Entwicklungssystem, auf dem alle Redakteure arbeiten? Wenn Redakteuere ihre Aenderungen aufs Live-System publizieren wollen, geht das zuerst in Staging-System zur ueberpruefung und dann erst aufs Live-System? Aber auch das wie ist nicht unwichtig. FTP-bedienen bekommen Redakteuere hin. Aber FTP wohin? Aufs Staging-System? Muesste ja auf eine Zwischenstation, damit es auch (automatisch?) eingecheckt wird.

Uiui .. und so verfaengt man sich leicht. Jemand gute Praxiserfahrungen?

In der Praxis haben alle Entwickler immer ueber ein Netzwerklaufwerk entwickelt, das war Development-System und nicht sehr aufwendig zu warten. Nur wenns mehr Entwickler werden? Ein commit auf solch einen Development-system wuerde eine automatische aktualisierung am Staging-System mit sich bringen. Dann ist nur die Frage, wie es von dort ins Live-System kommt. Muesst man eigens Routinen entwicklen o.ae. ...

Ist jetzt aber lang geworden

Zitat

pro devcoder eine eigene db? saemtliche alter's commands ebenfalls einchecken ? - koennte man alt werden

ein phpmyadmin hack wäre sexy, der automatisch in eine datenbank "eincheckt" (für alle) und dadurch tablestruktur und eventuell auch datenveränderungen festhält und diese per wunsch in ein sql file exportiert. würde imo zumindestens einen teil der dbsync erleichtern - nur so eine idee

praxis ist bei uns in der firma nur fileversionierung, die dbs sind lokal ergo retail version muss händisch zusammengebastelt werden. steinzeit halt, allerdings lohnt sich bei uns der aufwand für eine automatisiertere lösung nicht.

mat meint das ca so:

das interface zur dbms speichert in einem unabhaengigen file saemtliche table veraenderungen/erstellungen (am besten auch testdaten)
dieses extra file kann mit-commited werden (am besten das file ebenfalls innerhalb des rep. anlegen)
fuer den final-tag wird ein script von einem table export verwendet

nachteil: man muss halt jedem developer eine eigene db anlegen - waer ansich nicht so schlimm - erhoeht aber dennoch den aufwand unverhaeltnissmaessig imho

der vermutlich beste weg ist immer noch das datenbankmodell moeglichst frueh auszureifen und dann nur noch in ausnahmefaellen zu veraendern - aber siehe realitaet -> naja...

Update wird noetig. Folgender Schlachtplan wurde erstellt:


Es gibt Entwickler und Redakteuere.
Es gibt Apache Development, Stage und Live.
Es gibt MySQL Development und Live.


Entwickler machen keine lokalen checkouts sondern arbeiten alle gemeinsam auf einem Share, das quasi einen 'Megacheckout' von allen Projekten darstellt. Dieses Share wird ueber Samba zur Verfuegung gestellt und ist einer starren Struktur fuer die Porjektverzeichnisse ausgeliefert, da Apache diese Verzeichnisse braucht.

Entwickler commited die Daten und sind somit im Versionierungsststem. Entwickler muessen die Daten manuell auf das Stage System spielen, dies wird nicht automatisch gemacht. Das Stage-System ist Firmenintern, d.h. es ist nur ein weiteren Share, wo die entsprechenden Dateien einfach nur hinkopiert werden muessen.

Das Stage-System ist besondern konfiguriert, so dass jedes Projekt unter zwei verschiedenen URLs angesprochen werden kann. Mit url1 ist das Projekt so konfiguriert, dass es den MySQL Dev verwendet, mit URL greift es auf Mysql Live nur lesend zu.

Es gibt ein eigenes Web-Interface fuer Entwickler dass Daten von Stage auf Live publiziert. Technik dahinter nicht fixiert, ev. rsync o.ae.

Entwickler haben somit keinen direkten Zugriff auf Live-System. Existiert fuer Ausnahmefaelle, ist aber nicht die Regel.

Syncs via Web-Interface werden authentifiziert und protokolliert.


Redakteuere arbeiten direkt auf dem Share. Redakteuere haben aber ein eigenes Share, das ein Teil des bestehenden Entwickler-Shares ist.

Redakteuere haben ein eigenes Web-Interface, dass die Daten im Hintergrund in das Versionierungssystem commited. Das Versionierungssystem veroeffentlicht diese commits dann automatisch auf das Staging und Live-System. Hier sollte das Live-System zwar eigentlich nicht drin sein, aber es geht praktikabel nicht anders. Redaktuere zweimal etwas commiten/syncen muessen ist nicht drin.

Further comments?

Demnaechst kann ich auch ein Diagramm zur Veranschaulichung reinstellen. Btw, falls jemand gute Tipps hat (OpenSource), her damit. Hab dia verwendet, aber ich kann nicht alle Objekte auf einmal skalieren (wtf?) und ich hab net von Anfang an drauf geachtet und jetzt wird das immer ueber 10 A4 Seiten ausgedruckt Sodipodi muss ich noch testen, Inscape ist beim ersten Versuch gleich abgeschmiert. Herrgott, immer diese Unix-win32 Ports