Github für Webdevelopment?

[jeko]

Hallo zusammen,

ich arbeite zur Zeit zusammen mit anderen Programmierern an einer Web-Applikation die sich auf PHP und MySQL-Datenbanken stützt.

Wir stossen dabei vermehrt auf das Problem, wenn zwei oder mehr Personen das gleiche Verzeichnis / die gleiche Klasse / das gleiche Modul oder im allgemeinen die gleiche Datei bearbeiten, dass Person A die Änderungen von Person B zwangsläufig überschreibt. Um diese Problem zu umfahren, haben wir uns zum Teil auf verstärkte IM-Kommunikation konzentriert und ein Script geschrieben, dass automatisch den Dateibaum auf dem Server nach Änderungen durchsucht und diese mitsamt Dateipfad und Zeitstempel ausgibt.

Wie man sich aber denken kann, ist dieses Verfahren sehr aufwändig; die Kette ist nur so stark wie ihr schwächstes Glied, was in diesem Fall soviel bedeutet, dass das ganze System seinen Dienst nicht erfüllen kann, wenn der Programmierer nicht regelmässig die Dateiänderungsliste konsultiert – es zwingt ihn ja niemand dazu, bzw. kann ihn nichts von einem unüberlegten Dateiupload auf den Server abhalten.

Mit dieser Erkenntnis haben wir uns schliesslich nach einem SVN-ähnlichen Service umgesehen (denn unser Shared Hoster stellt keinen solchen); SVN sollte ja eben solche Probleme lösen. Die Wahl fiel auf Github, dass ja derzeit in aller Munde ist und in fast jedem aktuellen Techtalk über den Bildschirm flackert.
Allerdings haben wir neben kleinen Anfangsschwierigkeiten auch das Problem, dass wir keine Ahnung haben, wie wir dieses System effizient nutzen können; wie muss man sich so einen allgemeinen Workflow im Bereich des Webdevelopments vorstellen?

Der Source kann ja auf Github liegen, aber wenn wir neue Module schreiben bzw. Core-Files ändern, ist es ja wichtig diese testen zu können - und dazu müssen sie über kurz oder lang zwangsläufig auf einen Server geladen werden um realitätsnahe Tests zu ermöglichen. Wo muss man jetzt mit Github ansetzen?

Was ich mir am ehesten vorstellen könnte, wäre eine Testumgebung, auf welcher getestet wird, dann die Änderungen ins Github-Repo gespiegelt werden und in regelmässigen Abständen das Github-Repo auf den Live-Server gespiegelt wird. Dieser Überlegung folgend stosse ich aber erneut auf das geschilderte Problem - was wenn zwei oder mehr Personen auf dem Testserver arbeiten?

Hat da jemand Erfahrungen mit?

Grüsse
jeko

 

[Albu]

Also mit git habe ich keinerlei Erfrahrungen, weiß nur, dass es sich dabei um ein verteiltes Versionsverwaltungssystem handelt. Verteilt bedeutet, dass jeder Entwickler sein Repository lokal vorhält und somit alle Änderungen und Versionen auf seinem Rechner verfügbar sind (ohne zusätzlichen Netztraffic wie z.B. bei SVN oder CVS). Die Synchronisation erfolgt dann mittels spezieller Befehle, die die Änderungen eines anderen Repositories holen, bzw. die eigenen auf ein entferntes pushen. Quelle und Ziel können dabei beliebig sein, d.h. ein Entwickler könnte auch Änderungen von einem anderen Entwickler holen, ohne über das übergeordnete Repository zu gehen (i.d.R. sind die hierarchisch angeordnet, je nach Projektgröße), weil er die Änderungen dringend für seine Arbeit benötigt, der andere Entwickler aber noch nicht bereit ist, diese auf der übergeordneten Instanz zu veröffentlichen.

Direkt gearbeitet habe ich damit allerdings noch nicht. Hauptgrund ist, dass ich meinen Benutzern ein solch komplexes System nicht zumuten kann, es sind schließlich nicht alles Entwickler. Außerdem ist es für ein zentrales Backup zumindest in meinem Fall besser ein zentralisiertes Versionsverwaltungssystem zu verwenden, denn den Leuten kann man zwar beibringen die Änderungen zu commiten, aber den Push auf den Server vergessen sie dann garantiert. Deswegen setzen wir Subversion ein, welches Dank TortoiseSVN prima in den Explorer / TotalCommander integriert ist.
Google sagt für Git gibt es inzwischen auch was Vergleichbares, das gab es aber damals als wir von CVS auf SVN umgestiegen sind soweit ich weiß noch nicht, und Kommandozeilen Commits kommen für die Designer, Grafiker, Webentwickler und Mausschubser schon mal gar nicht in Frage.

Prinzipiell ist jedes Versionsverwaltungssystem geeignet einen gemeinsamen Codestamm von einem verteilten Team bearbeiten zu lassen. Bei SVN ergibt sich halt die Notwendigkeit einen zentralen Server zu haben, den alle anrufen können. Bei Git kann theoretisch jeder unabhängig arbeiten, aber einen zentralen Masterserver bräuchte man auch hier. Für beides gibt es externe Lösungen, die ihr ja schon in Erwägung gezogen habt.

Was die Arbeitsweise angeht, so sollte jeder Entwickler seinen eigenen Testserver lokal aufsetzen, auf dem er seine Parts testen kann. Dies sollte kein Problem darstellen, die Apache-Konfiguration und die DB-Skripte lassen sich über die Versionsverwaltung verteilen und jeder kann sich seinen Server einrichten. Der zentrale Testserver, der nur die bereits getesteten Versionen erhält, wird aus dem Masterrepository gefüttert, dies kann per automatischem Skript erfolgen. Hier muss dann aber mindestens einer drübergucken, ob die ganzen Änderungen im Zusammenspiel auch noch ihre Arbeit tun.
Ebenfalls automatisch kann man sich Commit-Mails generieren lassen, so bekommt jeder, der es wissen will mit, wer welche Codeteile im Masterrepository geändert hat. Eventuell kann man die Commit-Mails auch mit einem Checkout auf dem zentralen Testserver koppeln, dann ist dort immer der aktuelle Release-Stand der Arbeit (Release im Sinne von "was der Programmierer freigegeben hat").

Bei Konflikten, sprich zwei Entwickler haben die selbe Datei bearbeitet oder ein Entwickler verschiebt ein Verzeichnis, in welchem ein anderer noch gearbeitet hat, merkt der zweite Entwickler beim Commit oder Push (je nach System), dass es einen Konflikt gibt. Diesen muss er dann lösen und kann erst nach dem Lösen seinen Commit fortsetzen (er sollte seine Lösung natürlich vorher lokal nochmal testen, bevor er sie endgültig in das Masterrepository verfrachtet).
Eventuell bekommt der Entwickler schon über die Commit-Mails mit, dass es einen möglichen Konflikt gibt und kann sich schon vor seinem Commitversuch mit dem anderen Entwickler unterhalten, bzw. könnte er die Änderungen vom Masterrepository zu sich ziehen, um den Konflikt zu umgehen / lokal zu lösen.

 

[ZeitGeist]

svn server kann man sich aber auch mieten,
auf https://opensvn.csie.org/ gibts die sogar umsonst, allerdings sind die Server sehr langsam.
Bessere Erfahrung habe ich mit http://www.projectlocker.com/ gemacht, hatte da das Angel-Paket für 5$ im Monat. Allerdings gibts da auch ne umsonst Version.

Bei beiden war auch trac dabei, nen Ticketsystem was durch aus praktisch ist.

 

[jeko]

Hallo Albu, hallo Zeitgeist,

danke für eure Antworten. Ich denke dein Ansatz ist nicht schlecht Albu, das probieren wir mal aus. Gibt nochmal ein gutes Stück Arbeit, aber das wird schon. Dankeschön!

Zeitgeist: Langsamer Server können einem ganz schön auf dem Nerv gehen wenn man gerade entwickelt, daher scheidet CSIE schon mal aus (danke für den Hinweis). Weiss auch nicht, bin gerade fixiert auf Github aber ProjectLocker scheint interessant zu sein; müsste abklären ob das Userlimit ein Problem darstellen könnte, aber das Trac-System klingt verführerisch.

Danke auf jeden Fall, denke das hat die Frage geklärt. Hoffe jetzt nur, dass sich die Leute nicht allzu sehr gegen Veränderung sträuben...

Grüsse
jeko