Verwalten Sie die Versionskontrolle mit einem zentralen Entwicklungsserver (LAMP).

Ich arbeite in einem kleinen Team mit bis zu 5 (Web-) Entwicklern. Da unser Team häufig wächst und wir Probleme mit mehreren Personen hatten, die an demselben Code arbeiteten, haben wir beschlossen, ein VCS einzurichten.

Momentane Situation

Derzeit arbeiten wir mit einem zentralen Entwicklungsserver (LAMP). Jeder Entwickler arbeitet also mit derselben Codebasis. Wenn der Code getestet und für unseren Live-Server bereit ist, kopieren wir ihn einfach über FTP. Ich weiß, dass dies eine Art Anno 1600-Workflow ist, aber ja - es ist das, was es ist und auch der Grund für diese Frage.

Auf dem Entwicklungsserver sieht unsere Verzeichnisstruktur folgendermaßen aus:

/var/www 
      /Project1 
      /Project2 
      /Project3 
      ...

Zusätzlich gibt es einige kleine Nicht-Webanwendungen - Android / iPhone / Windows 8 usw. Apps und einige C # -Tools, die ebenfalls im VCS enthalten sein sollten.

Ziel und Probleme

Unser Ziel ist es, ein sauberes Setup für ein VCS zu erhalten, das mit einer Issue-Tracking-Software zusammenarbeitet, es uns ermöglicht, gleichzeitig am selben Projekt zu arbeiten, ohne unsere Codes zu überschreiben, und uns einfach den Vorteil der Versionskontrolle bietet.

Ich denke, die erste Frage für uns ist, welche Technologie wir verwenden sollen. Einige von uns haben bereits Subversion erlebt. Aber weil Git eine Art "Standard" wird und es unter den Webbenutzern viele "Pro-Git" -Argumente gibt, verwenden wir Git.

Da beginnt unsere Unsicherheit. Für die Verwendung von git - einem dezentralen VCS - müssen anscheinend separate Entwicklungsserver auf dem Computer jedes Entwicklers verwendet werden. Die Probleme damit sind:

• Manchmal arbeiten wir auf verschiedenen Computern. Wenn wir also vergessen, unseren Code zu pushen, haben wir ein Problem.
• Wir müssten mit virtuellen Maschinen arbeiten, da die Entwicklungsserver mit unseren Live-Servern identisch sein sollten (dies wäre in unserer Umgebung einfach nicht durchsetzbar, glauben Sie mir, es ist nicht möglich).
• Der Entwicklungsserver diente normalerweise auch als "Tryout" - oder "Präsentations" -Server, auf dem Nicht-Entwickler nachschauten, was los ist.

Gibt es ein anderes mögliches Setup mit git, damit wir vom System profitieren können, während wir noch einen einzelnen (!) Entwicklungsserver verwenden? Vielleicht mit unterschiedlichen Verzeichnissen für jeden Entwickler. Oder können wir immer noch an derselben Codebasis arbeiten und möglicherweise die Dateien sperren, an denen wir arbeiten, und sie dann in ein Repository übertragen. Es ist vielleicht wichtig zu sagen, dass es zwar für uns zu einem Faktor wurde, es aber immer noch ungewöhnlich ist, dass mehrere Entwickler gleichzeitig an demselben Teil einer Anwendung arbeiten.

Hier sind Sie auf dem richtigen Weg.

Vielleicht mit unterschiedlichen Verzeichnissen für jeden Entwickler.

Ja, definitiv unterschiedliche Verzeichnisse für jeden Entwickler.

Die Maschine, auf der Sie sich befinden, ist ziemlich uninteressant. Stellen Sie einfach sicher, dass sich jeder Entwickler als er selbst anmeldet und eine Kopie des Git-Repos in seinem eigenen Home-Verzeichnis auscheckt. Sie werden mehrere Kopien des Codes in Ihrem Dateisystem haben, aber hey, die Festplatte ist kostenlos.

Es ist wahr, dass Git den dezentralen Betrieb unterstützt . Aber Sie werden es in Ihrem typischen Workflow nicht so verwenden. Stellen Sie einfach sicher, dass ein nacktes Repo auf einem praktischen Server verfügbar ist, und lassen Sie alle davon profitieren. Greifen Sie über http, ssh oder sogar über das Dateisystem darauf zu, wenn Sie möchten.

Sie haben einen "Tryout" -Bereich als Teil Ihres Workflows erwähnt. Tu dir selbst einen Gefallen. Stellen Sie einen anderen Entwickler namens Jenkins ein, der Ihren Code auch mit git überprüft. Er ist hier implementiert: http://jenkins-ci.org/ (und läuft unter http://tomcat.apache.org/download-70.cgi ). Auf diese Weise wird bei jedem Push an das zentrale Repo sofort eine aktualisierte Version Ihrer Website im Home-Verzeichnis von Jenkins verfügbar, in der Sie sie schnell ausprobieren und die Gesundheit prüfen können. Wir nennen dies kontinuierliche Integration, und es wird definitiv Ihren Workflow verbessern.

 It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

Wenn nur wenige Leute auf demselben Computer und derselben Codebasis arbeiten, müssen Dinge schief gehen. Wegen des Überschreibens und weil, wenn man etwas kaputt macht, andere warten müssen, bis sie repariert sind, um ihre Sachen zu testen.

Sie müssen nur wenige Umgebungen unterscheiden. Sieht so aus, als bräuchten Sie drei (sehr häufig):

• Produktion - wo das Projekt tatsächlich von Endbenutzern verwendet wird.
• Staging - Ort, an dem Entwickler seine Arbeit mit anderen Entwicklern zusammenführen, testen und manchmal Kunden einen Blick in diesen Bereich werfen können.
• Entwicklung - wo jeder Entwickler alleine arbeitet, bevor er mit anderen fusioniert.

Üblicherweise bedeutet Entwicklungsumgebung, dass Maschinenentwickler daran arbeiten. Wenn Sie es auf einem freigegebenen Computer behalten möchten, können Sie dies auch tun. Umgebungen und Maschinen sind etwas Entkoppeltes. Sie müssen nur eine andere Codebasis für jedes Projekt, jeden Entwickler und jede Umgebung haben.

Im Fall von Git und 5 Entwicklern im Unternehmen gibt es also 5 Repositorys für die Entwicklungsumgebung . Für die Staging- Umgebung (Zusammenführen von Code) benötigen Sie ein Repo zum Zusammenführen und ein anderes zum Testen von Code und zum Anzeigen des aktuellen Status des Clients, da es keine gute Idee ist, auf nicht nackte Repositorys zu pushen. Wenn der Produktionsserver dort einen anderen Git hat. Wenn nicht, würden Sie einfach Dateien über FTP aus der Staging- Umgebung in die Produktion übertragen . So wenige Repositories für jedes Projekt.

Und der Workflow sieht folgendermaßen aus: Sie arbeiten an Ihrer Entwicklungsumgebung . Wenn Sie eine Funktion hinzugefügt oder einen Fehler behoben haben, übertragen Sie Ihre Änderungen auf das Bare-Repo der Staging- Umgebung und ziehen dies auf dem Non-Bare-System heraus (ein Git-Hook könnte dies sofort tun.) und wenn das Projekt bereit ist, eine neue Version zu veröffentlichen, pushen Sie sie (oder übertragen sie per FTP) in die Produktion .

Manchmal arbeiten wir auf verschiedenen Computern. Wenn wir also vergessen, unseren Code zu pushen, haben wir ein Problem.

Wenn Sie eine Entwicklungsumgebung auf demselben gemeinsam genutzten Server ausführen müssen, können Sie Ihre Dateien über rsync vom lokalen Computer auf den Server synchronisieren oder ein Netzwerklaufwerk oder was auch immer zuordnen. Dies ist jedoch immer etwas langsamer als bei der Arbeit auf dem lokalen Computer . Das Arbeiten vor Ort hat jedoch das von Ihnen erwähnte Problem. Auch ohne VCS. Wie bei der Verwendung von FTP - wenn Sie etwas auf Ihrem Computer ändern und vergessen, es zu übertragen - passiert dasselbe. Sie möchten Ihren zerlegten Code jedoch nicht mit der Staging- Umgebung zusammenführen. Es muss in der Entwicklung bleiben, bis es einen vernünftigen Zustand erreicht.

We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).

Wev-Server ohne GUI verbrauchen nicht viele Ressourcen. Ich denke, ihr könntet an dem Code arbeiten und ihn auf seiner eigenen Maschine testen. Also Entwicklungsumgebung lokal und nur Staging auf dem gemeinsam genutzten Server. Sie können sich etwas wie Vagrant ansehen, um die Verwaltung von Images virtueller Maschinen zu erleichtern. Sie würden also sicherstellen, dass jedes Projekt die richtigen Einstellungen erhält. Dies würde sicherstellen, dass Sie auf die gleiche Weise testen, sicherer sind (jetzt, wenn der gemeinsam genutzte Server ausfällt, kann niemand mehr arbeiten und Sie müssen dort ein gutes Backup haben) und schneller (keine Übertragung bis zum Zusammenführen erforderlich). Git ist in dieser Angelegenheit besser als zehn SVN, da es auf jedem Computer mit Verlauf und allem ein vollständiges Repo enthält. Wenn also ein PC kaputt geht, gibt es immer noch gute Kopien an einem anderen Ort.

Auch Dinge wie Gitosis können Ihnen bei der Verwaltung der Repo-Einstellungen der Staging- Umgebung helfen , und Redmine oder andere Projektverwaltungssoftware bietet häufig Möglichkeiten zur Integration in VCS.

Weil Git eine Art "Standard" wird und es unter den Webbenutzern viele "Pro-Git" -Leute gibt, verwenden wir Git.

Dies ist eine schlechte Grundlage für die Auswahl in der SCM-Welt. Git ist nicht "Standard", sondern "Mode" mit viel Lärm. "Pro Git" ist in vielen Fällen mehr Fanboyismus als eine vernünftige und begründete Entscheidung

Arbeiten Sie gleichzeitig am selben Projekt, ohne unsere Codes zu überschreiben, und geben Sie uns einfach den Vorteil der Versionskontrolle

Verzweigungen in jedem SCM ermöglichen es Ihnen, es auch mit Git zu erhalten (Stichwort: "Git-flow")