Bereitstellungsstrategien für mehrere Server - Git auf Produktionsservern?

Hauptfrage: Ist die Bereitstellung mit Git auf Produktionsservern eine gute Strategie?

Viele, viele Bereitstellungsstrategien, die ich sehe, drehen sich darum, Git auf Ihren Servern zu haben (Entwickler, Staging und Produktion).

Die Vorzüge davon scheinen für den Einsatz auf der Bühne / Produktion offensichtlich zu sein:

• Fähigkeit, Änderungen schnell einzuziehen
• Einfachere Automatisierung
• Kann bei Bedarf die Verzweigung wechseln (Verzweigung pro Testserver möglicherweise)
• Kann sehen, ob Dateien auf einem Produktionsserver irgendwie geändert wurden

Ich sehe jedoch einige Nachteile:

• Sicherheit - Git scheint ein potenzieller Angriffsvektor zu sein, selbst wenn die Produktion schreibgeschützt ist
• git pull auf einem Produktionsserver kann ausfallen, wenn es irgendwie nicht bereitgestellte Änderungen in der Produktion gibt (obwohl mit -f überwindbar)

Deployment as a Service-Unternehmen (z. B. Beanstalkapp.com, deployhq.com) verwenden FTP, SFTP oder SSH. Insbesondere Beanstalkapp kann nur Dateien basierend auf dem Git-Verlauf ändern (anstatt jede Datei erneut bereitzustellen). Diese Dienste verlangen nicht, dass Sie Git auf Ihren Stage- / Produktionsservern haben (auch wenn Sie über SSH bereitstellen, ist es wahrscheinlich, dass Sie diese Strategie verwenden würden / könnten).

Ich habe festgestellt, dass ich gerne sftp benutze:

• Kann Skripte vor / nach der Bereitstellung noch ausführen
• Überschreibt, verschiebt, löscht Dateien unabhängig davon, was sich auf dem Produktionsserver befindet (das ist ein Plus für mich)
• Sie haben kein .git-Verzeichnis oder eine git-basierte Angriffsanfälligkeit in der Produktion

Lohnt sich die einfache Verwendung von Git auf einem Produktionsserver im Hinblick auf Best Practices und Sicherheit? Wenn nicht, wie kann die Bereitstellung erfolgen, während Tools für die kontinuierliche Integration übersprungen werden?

(Ich frage nur nach dem Überspringen von CI-Tools, da Zeit-, Budget- und Kundenbeschränkungen sie in meinem täglichen Gebrauch nicht zulassen.)

Beantwortung Ihrer Frage: Ja, die Bereitstellung mit Git (oder einer anderen Revisionskontrolle) ist der richtige Weg, insbesondere wenn Ihre Infrastruktur komplex / groß wird.

Antworte auf deine Bedenken

• Sicherheit muss in Schichten erfolgen, und selbst wenn Git ein wirklich besorgniserregender Angriffsvektor wäre, müsste jemand dennoch Zugriff auf die Server erhalten, um dies zu tun. Gute Serversicherheit, SSH-Schlüssel-basierte Authentifizierung und Zugriffskontrolle / Protokollierung, und Sie haben ein sehr geringes Risiko dafür.

• Wenn Sie ein Bereitstellungstool schreiben möchten, müssen Sie natürlich ein Rollback-Verfahren in Betracht ziehen, falls die Codeaktualisierung fehlschlägt. Das Gute ist, dass Tools wie Capistrano (mit denen ich besser vertraut bin) bereits alle diese Schritte eingebaut haben und Sie das Verhalten usw. ändern können.

Ich denke, das Beste ist, ein Bereitstellungstool wie capistrano oder Vlad the Deployer zu verwenden oder sogar Chef bereitzustellen, wenn Sie bereits Chef (oder ein anderes Konfigurationsverwaltungstool) haben.

Capistrano zum Beispiel richtet sich standardmäßig an Schienen, aber Sie können es so anpassen, dass es alles bereitstellt. Es stellt eine Verbindung zu Ihren Servern her, aktualisiert den Code (einige ältere Versionen bleiben erhalten, falls Sie ein Rollback auf eine frühere Version durchführen müssen), führt Aufgaben wie DB-Migrationen oder Bereinigungen aus und startet die Dienste bei Bedarf neu. Sie können dies für Ihre Umgebung anpassen und sogar unterschiedliche Umgebungen haben (ich habe mit der Produktion gearbeitet und + 3 andere angegeben).

Mit allen anderen Tools können Sie so etwas tun, und ich denke, dass es nur dann gültig ist, Zeit für das Schreiben eines Bereitstellungsskripts zu investieren, wenn sich Ihr System wirklich von den "üblichen" unterscheidet.