Verwendung von Git zur Verteilung nächtlicher Builds an ein Studio

Question

Kurzfassung

Sie müssen jeden Morgen die nächtlichen Builds an mehr als 70 Personen verteilen und würden gerne git Ich möchte die Übertragung ausbalancieren und wüsste gerne, ob es Tipps, Fallstricke oder Fehler bei dieser Idee gibt, bevor ich mit der Entwicklung des Systems beginne.

Lange Fassung

Jeden Morgen müssen wir unseren nächtlichen Build an das Studio mit mehr als 70 Mitarbeitern (Künstler, Tester, Programmierer, Produzenten usw.) verteilen. Bis jetzt haben wir den Build auf einen Server kopiert und ein . Programm, das es abruft (mit Robocopy darunter); selbst bei der Einrichtung von Spiegeln ist die Übertragungsgeschwindigkeit inakzeptabel langsam, da die Synchronisierung zu Spitzenzeiten bis zu einer Stunde oder länger dauert (außerhalb der Spitzenzeiten sind es etwa 15 Minuten), was auf einen Hardware-E/A-Engpass hindeutet.

Eine brillante (wenn auch definitiv nicht originelle) Idee, die ich hatte, war, die Last im ganzen Studio zu verteilen. Nachdem ich untersucht hatte, einen Client zu schreiben, der das berüchtigte Bit-Torrent-Protokoll verwendet, kam mir ein weiterer Gedanke: Ich könnte einfach das git da es uns die Verteilung des Build- und Revisionsmanagements ermöglicht, mit dem zusätzlichen Vorteil, dass es weniger Server benötigt.

Fragen

1. Wie fängt man an, Git zu benutzen? Ich habe Erfahrung mit zentral gelegenen Versionskontrollsystemen wie Perforce et SVN . Nach der Lektüre der Dokumentation scheint es, dass Sie nur Folgendes ausführen müssen git init path\\to\folder und führen Sie dann auf einem anderen Rechner git clone url ?

2. Woher bekomme ich die url für die oben genannten git clone Befehl? Kann ich das definieren? Ich finde das Konzept einer Url seltsam, da Git keinen zentralen Server hat - oder doch? z.B. ähnlich wie bei einem Bit-Torrent-Tracker?

3. Was wäre die bessere Option zur Identifizierung von Builds, die Verwendung von Änderungslistennummern oder Labels?

4. Ist es möglich, die Anzahl der gespeicherten Revisionen zu begrenzen? Dies wäre nützlich, da wir zusätzlich zu den nächtlichen Builds auch mehrere CI-Builds über den Tag verteilt haben, die wir verteilen wollen. Es macht jedoch keinen Sinn, eine unendliche Anzahl von Revisionen herumliegen zu haben. Unter Perforce können Sie die Überarbeitungen durch die Festlegung einer Eigenschaft einschränken.

Answer 1

Ich glaube nicht, dass git in Ihrer Situation wirklich hilfreich sein wird. Ja, es wird verteilt, aber nicht im Falle von "etwas an so viele Leute wie möglich verteilen". Es hilft Ihnen nicht, die Bandbreitenbelastung zu reduzieren, außerdem wird es eine zusätzliche Belastung geben, wenn Sie git über ssh verwenden. Vielleicht sollten Sie einen Schritt zurück machen und dem Bittorrent-Protokoll eine weitere Chance geben.

Answer 2

1. können Sie das Dateiprotokoll verwenden (" lokales Protokoll "), wenn alle Ihre Kunden einen gemeinsamen Zugang zu Ihrem Server haben.
2. Wenn Sie ein dir oder ls von Ihrem Client aus erstellen können, haben Sie die benötigte URL.
3. Tags: Sobald Sie ein Repository klonen, können Sie es mit einem bestimmten Tag auschecken.
4. nicht wirklich, Sie werden jeden Morgen die neuen Übertragungen abrufen, um einen vollständigen Verlauf zu erhalten.

Hinweis: Das Ablegen von Binärdateien in einem verteilten Repository ist keine Lösung, die wird mit der Zeit gut skalieren Der Rückkauf wird immer umfangreicher. (Sie haben alternative Git-Konfigurationen hier ).
Der Vorteil ist, dass das Delta durch das zentrale Git-Repository berechnet wird (was deutlich schneller ist als eine Robokopie) und dieses Delta als Antwort auf eine git fetch von einem nachgelagerten Repo durchgeführt.

Answer 3

1. Ja, das ist der Kern der Sache. Legen Sie irgendwo ein Repository an und klonen Sie es dann von einem anderen Ort.

2. Das Repository, das Sie in 1) initialisieren, muss von dem Rechner, auf den Sie klonen, zugänglich sein. Git ist serverlos, aber jedes Repository muss seine Daten von irgendwoher beziehen. Also müssen alle Ihre 70+ Rechner wissen, wo sie den neuen Build herbekommen sollen. Und wenn Sie die Last verteilen wollen, müssen Sie sich eine Strategie überlegen, wer sein Update von wem bekommt.

   Die URL kann ein Dateipfad, ein Netzwerkpfad, ein SSH-Host mit Pfad usw. sein.

3. Tags würden gut funktionieren.

4. Sie könnten vielleicht das Git-Repository neu erstellen, um alte Revisionen zu entfernen. Siehe Vollständiges Entfernen von (alten) Git-Commits aus der Historie

Ich glaube jedoch nicht, dass dies Ihr ursprüngliches Problem, nämlich die Verteilung der Last, lösen wird. Es sollten andere Möglichkeiten untersucht werden. Multicast-Kopieren zum Beispiel, vielleicht MQcast und MQcatch kann Ihnen helfen?