Umstellung eines Entwicklungsteams von FTP auf ein Versionierungssystem

Question

Ich arbeite in einem kleinen LAMP-Entwicklungsstudio, in dem die Idee war, einfach den Code fertigzustellen und zum nächsten Punkt auf der Liste überzugehen.

Das Team arbeitet in Zend Studio 5.5 und ist über FTP oder SFTP mit dem Live-Server verbunden. Was sie daran lieben, ist die Geschwindigkeit, mit der sie ihren Code einsetzen können (da sie nur den Live-Code ändern).

Aber natürlich ist das aus vielen offensichtlichen Gründen nicht gut.

Ich würde sie gerne auf ein Versionierungssystem (CVS, SVN oder ein anderes Tool) umstellen, aber der Haken an der Sache ist, dass ich nicht ihr Vorgesetzter bin, so dass ich ein Zuckerbrot brauche, damit sie damit anfangen.

Welche Art von Setup müsste ich auf ihrem Rechner einrichten, damit sie wie gewohnt mitprogrammieren können?

Ich würde dieses Setup auf meinem Rechner erstellen und es ihnen dann zeigen.

Ich weiß, das ist etwas ungewöhnlich, aber es ist zu einer Leidenschaft von mir geworden, ihre Denkweise vom üblichen Hacken des Codes auf Struktur und Eleganz zu ändern. Danke!

UPDATE (für die Antwort von Jonathan Leffler):

1. Ja
2. Non
3. Ja, das tun sie wirklich

Eine weitere Frage: Das Studio stellt ein zentralisiertes CMS-System her, das auf Hunderten von Websites gehostet wird. Sollen die einzelnen Websites im Hauptkompositum oder in ihrem eigenen System geändert werden?

Answer 1

Fragen:

1. Hatten Sie (sie) noch nie eine Katastrophe, bei der Sie (sie) zu einer früheren Version der Website zurückkehren mussten, dies aber nicht konnten, weil sie kaputt gegangen war?

2. Verwenden sie einen Staging-Webserver, um Änderungen zu testen?

3. Sie ändern doch sicher nicht den Code auf dem Produktionsserver, ohne ihn irgendwo zu testen?

Ich vermute, dass die Antwort auf die erste Frage "ja (sie hatten Katastrophen)" und auf die zweite "nein" lautet, und ich zögere, die Antwort auf die dritte Frage zu erraten (aber so wie es sich anhört, könnte die Antwort lauten "ja, das tun sie wirklich"). Wenn das stimmt, bewundere ich ihre Tapferkeit und bin erstaunt, dass sie nie einen Fehler machen. Ich würde es nie riskieren, Änderungen direkt auf einer Live-Website vorzunehmen.

Ich würde empfehlen, selbst ein Versionskontrollsystem oder VCS (irgendein VCS) zu verwenden. Arbeiten Sie die Feinheiten für den Code aus, um den Sie sich kümmern, und entwickeln Sie eine geschickte Verteilung, die es einfach macht (wahrscheinlich immer noch mit SFTP), den VCS-Code auf der Website zu verteilen. Zeigen Sie aber auch, dass die Bewahrung der früheren Versionen ihre Vorteile hat - denn Sie können wiederherstellen, wer was wann gemacht hat. Für den Anfang werden Sie vielleicht feststellen, dass Sie die aktuelle Version der Seite (Datei), an der Sie arbeiten wollen, herunterladen und diese neueste Version in das VCS einspeisen müssen, bevor Sie mit der Änderung der Seite beginnen, weil jemand anderes sie seit der letzten Aktualisierung in Ihrem Haupt-Repository geändert haben könnte. Sie könnten auch einen täglichen "Scrap" der Dateien durchführen, um die aktuellen Versionen zu erhalten - und Änderungen zu verfolgen. Sie hätten weder das "Wer", noch das genaue "Wann" (besser als auf den Tag genau), noch das "Warum", aber Sie hätten das (kumulative) "Was" der Änderungen.

---

Als Antwort auf die Kommentare in der Anfrage stellte Ólafur Waage klar, dass es aufgrund des Fehlens eines VCS zu Katastrophen gekommen sei.

Das macht das Leben normalerweise viel einfacher. Sie haben einen Fehler gemacht, den sie nicht mehr rückgängig machen konnten - sie hatten wahrscheinlich verärgerte Kunden und hätten sich eigentlich über sich selbst ärgern müssen. Ein VCS macht es viel einfacher, solche Fehler zu korrigieren. Natürlich braucht man für jede angepasste Seite ein (zentrales) Backup der "richtigen" oder "offiziellen" Version dieser Seite, die im VCS verfügbar ist. Ich würde mich wahrscheinlich für ein einziges Repository für alle Kunden entscheiden und ein VCS verwenden, das eine gute Unterstützung für Verzweigungen und Zusammenführungen bietet. Das mag anfangs schwieriger zu handhaben sein (während die Leute sich an die Benutzung eines VCS gewöhnen), führt aber langfristig wahrscheinlich zu besseren Ergebnissen. Ich würde ernsthaft in Erwägung ziehen, eines der modernen verteilten VCS zu verwenden (z.B., git ), obwohl viele Leute auch SVN benutzen (auch wenn es kein verteiltes VCS ist).

Answer 2

Sie können tortoise svn client verwenden, um ein Repository auf Ihrem lokalen Rechner unter einem anderen Dateipfad zu erstellen und damit zu arbeiten. Ihr Arbeitspfad ist dann....

Versuchen Sie vielleicht, das für sich selbst einzurichten und zu nutzen, und zeigen Sie ihnen nach einer Weile, was es für Sie tun kann. Eine andere coole Sache könnte die Installation von Trac ( http://trac.edgewall.org/ ) auf deinem server, wenn du zugang und privilegien dazu hast, oder vielleicht in einer virtuellen maschine auf deinem eigenen entwicklungsrechner. du kannst trac mit deinem svn verknüpfen und svn-änderungen im web-interface anzeigen, das du dem projektmanager zeigen kannst. vielleicht wird er darauf reinfallen, dass er in der lage ist, code-änderungen einfach über das web-interface zu sehen. natürlich kannst du das auch nur mit apache + svn-modul machen, aber das ist netter, da es einen pfad zu ticketing und roadmapping bietet (milestones und andere sachen, auf die manager abfahren könnten :o) )

trotzdem viel Glück :) . verwenden Sie es zumindest für Ihre Arbeit auf Ihrem lokalen Rechner, denn das bringt Ihnen nur Vorteile.

Answer 3

Für die Demo können Sie SVN auf Ihrem lokalen System installieren. Es gibt einige Tools zur Integration von Zend und Eclipse in SVN. Ich denke, Sie sollten nicht nur eine Demo von SVN machen, sondern ihnen auch einige der Vorteile vorstellen, die es mit sich bringt (wahrscheinlich während der Demo).

Unter diesem Link finden Sie einige Ideen: Brauche ich wirklich eine Versionskontrolle?

Answer 4

Hier ist ein Trick, den jeder lieben wird:

Ich baue dieses "Plugin" in die meisten meiner Produktionsseiten ein: Natürlich müssen Sie dafür zuerst ein Robot-Svn-Konto mit eingeschränkten Rechten erstellen und svn muss auf dem Server installiert sein.

    echo(' updating from svn<br>' );
    $username = Settings::Load()->Get('svn','username');
    $password = Settings::Load()->Get('svn','password');
    echo(" <pre>" );
    $repos = Settings::Load()->Get('svn' , 'repository');
    echo system ("svn export --username={$username} --password {$password} {$repos}includes/ ".dirname(__FILE__)."/../includes --force");
    echo system("svn export --username={$username} --password {$password} {$repos}plugins/ ".dirname(__FILE__)."/../plugins --force");

    die();

Stellen Sie sicher, dass Sie dies hinter einer .htpasswded-Site ablegen, und stellen Sie sicher, dass Sie die "Produktionseinstellungen" nicht über SVN aktualisieren. Et voila, Sie aktualisieren Ihre gesamte Codebasis mit einer HTTP-Abfrage an Ihre Website :) SVN überschreibt die Dateien automatisch, es bleiben keine versteckten Dateien oder Ordner zurück und es lässt sich leicht anpassen, um eine bestimmte Version zu aktualisieren oder zu ihr zurückzukehren. Jetzt muss Ihr Team nur noch in sein SVN-Repository übertragen, diesen Code in der Testumgebung ausführen, sicherstellen, dass alles funktioniert, und ihn dann in der Produktionsumgebung ausführen :)

Answer 5

Ólafur, du hast erwähnt, dass "das Studio ein CMS-System herstellt, das auf Hunderten von Websites gehostet wird". Dies könnte das Zuckerbrot sein, das Sie brauchen. Wenn das Team häufig Aktualisierungen für diese Hunderte von Websites bereitstellt, kann die Verwendung von Zweigen in einem Versionskontrollsystem diesen Prozess für alle viel einfacher machen. Das könnte eine enorme Zeitersparnis bedeuten und wäre somit ein Anreiz für die Mitarbeiter, das Versionskontrollsystem zu erlernen.

Es klingt, als ob diese Websites alle miteinander verbunden sind - angepasste Versionen desselben CMS. In diesem Fall sollten Sie alle Sites in dasselbe Repository legen, zusätzlich zu dem nicht angepassten CMS-Produkt. Dann können Sie sie alle als Zweige desselben zentralen Produkts konfigurieren. Wenn Sie getrennte Repositories verwenden, gibt es keine einfache Möglichkeit, Zweige zu erstellen, um die Anpassungen mit dem Hauptprodukt zu verknüpfen. (Ich denke, Sie puede mit Subversion und wahrscheinlich auch mit anderen, aber es ist kompliziert und unnötig, wenn alle Entwickler für dieselbe Organisation arbeiten).