(dis) vorteile der inszenierung von dev-> produktion mit 'drush rsync' vs 'git'?


9

Ich habe eine Drupal-Site unter Git-Kontrolle für die Entwicklungsarbeit eingerichtet.

Es ist in einem Master-Bare-GIT-Repo übergeordnet, und da Änderungen an meinen verschiedenen Projektarbeits-Git-Klonen vorgenommen und an den Master zurückgesendet werden, werden die Änderungen durch einen Post-Update-Hook sofort auf eine einzelne Live-Staging-Website (http: /) übertragen /staging.loc.). Nichts besonderes, funktioniert wie erwartet.

Ich habe auch die Seite "@STAGING" mit einem Drush-Alias ​​versehen. Gelegentlich möchte ich meine Änderungen von der Staging-Site auf einen Produktionsserver übertragen.

Zwei relativ einfache Methoden kommen in den Sinn:

(1) Erstellen Sie zu einem Zeitpunkt, an dem die Staging-Site stabil erscheint, die Produktions-Site als Git-Checkout aus dem Master-Repo.

(2) Verwenden Sie drush rsync+ drush sql-syncvon der Bereitstellungsstelle zur Produktionsstätte.

Beides kann zum Arbeiten gebracht werden. Abgesehen von der Tatsache, dass (2) von Natur aus Drupal-zentrierter / bewusster zu sein scheint - Drush ist schließlich ein Drupal-spezifischer Satz von Werkzeugen -, was sind die relativen Vorzüge der beiden Ansätze?

Gibt es einen bestimmten Grund, warum ich (1) über (2) nachdenken sollte?

In beiden Fällen unterliegt "Everything" mindestens einer Revisionskontrolle ...

Antworten:


3

Ich habe beide Techniken verwendet. Beide können verwendet werden, um sicherzustellen, dass dieselben Dateien, die Sie auf @stage testen, auf @live landen. Der Vorteil von rsync besteht darin, dass Sie keine zusätzlichen Dateien (z. B. ".git" und zugehörige) auf Ihrem Produktionsserver haben. Ich neige dazu, mit einem vps zu synchronisieren und git auf einer Box zu verwenden, die ich besitze (z. B. Intranetseiten).


Danke für den Punkt. Ich habe mir nur die Ausschlussoptionen angesehen. Das hilft, die Dinge sauber zu halten. Iiuc, ich muss angeben, "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"womit in der .rc-Datei ausgeschlossen werden soll, obwohl ich noch nicht sicher bin, ob ich das sowohl in den Spezifikationen des Quell- als auch des Zielalias oder nur in der einen oder anderen benötige.

.git sollte standardmäßig ignoriert werden. Führen Sie 'drush --simulate rsync [options] @a @b' aus, um den genauen rsync-Befehl anzuzeigen, den Drush ausführen wird. Verwenden Sie --include-vcs, wenn drush rsync .git und andere vcs-bezogene Dateien enthalten soll.
Greg_1_anderson

Ich muss genauer nachlesen. Ich wusste nicht, dass .git ausgeschlossen war. Danke auch für den Simulationshinweis. Betreff: Das OP, ich denke, ich bleibe beim 'drush rsync', da es als Bereitstellungsmethode für drupal & works konzipiert ist. Git kann natürlich funktionieren, aber ich habe jetzt genug Kommentare gefunden, dass es nicht für die Bereitstellung ausgelegt ist ...

1

Das Problem bei der Verwendung von drush rsync besteht darin, dass mehrere Personen Änderungen auf den Server übertragen.

Ihr Beispiel zeigt nur eine Person, die Änderungen vorantreibt.

Wenn Entwickler A ihre Änderungen vorantreibt und Entwickler B seine Änderungen vorantreibt, soll git die Konflikte abwischen oder Entwickler B die Konflikte abwischen lassen.


1

Ich benutze eigentlich beide. svn / git und rsync dienen zwei unterschiedlichen Zwecken. svn / git dient zur Quellcodeverwaltung rsyncund sql-synczur effizienten Synchronisierung von Staging und Prod. drush rsync @staging @prodist in Bezug auf Einfachheit sehr schwer zu übertreffen und lässt sich schrecklich einfach in die meisten continuous IntegrationUmgebungen integrieren, wenn Sie noch tiefer in die Verrücktheit / Methodik der Codequalität eintauchen möchten.


1

Persönlich verwende ich Git zur Versionskontrolle, Bereitstellung und Synchronisierung verschiedener Server-Codebasen und dann rsync zum Verschieben / Synchronisieren von Benutzerdateien (ignoriert durch Hinzufügen bestimmter Pfade zur Gitignore-Datei).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.