(dis) zalety inscenizacji dev-> produkcji przy użyciu „drush rsync” vs „git”?

Założyłem witrynę Drupal pod kontrolą git do prac programistycznych.

Jest nadrzędny w nadrzędnym, czystym repozytorium GIT, a ponieważ zmiany są wprowadzane w moich różnych klonach git do pracy nad projektami i wypychane z powrotem do elementu nadrzędnego, hak po aktualizacji natychmiast wypycha zmiany do pojedynczej strony internetowej na żywo (http: / /staging.loc.). Nic specjalnego, działa zgodnie z oczekiwaniami.

Drash-aliasy strony „@STAGING”. Czasami chcę promować moje zmiany z witryny przejściowej na serwer produkcyjny.

Przychodzą mi na myśl dwie stosunkowo proste metody:

(1) W momencie, gdy witryna przejściowa wydaje się stabilna, utwórz witrynę produkcyjną jako kasę git z głównego repozytorium,

(2) użyj drush rsync+ drush sql-syncz miejsca postoju do miejsca produkcji.

Oba można sprawić, by działały. Poza tym, że (2) z natury wydaje się bardziej skoncentrowany na Drupalu / świadomy - drush jest w końcu zestawem narzędzi charakterystycznych dla Drupala - jakie są względne zalety obu podejść?

Czy jest jakiś konkretny powód, dla którego powinienem rozważyć (1) ponad (2)?

W obu przypadkach „Wszystko” podlega przynajmniej jednej kontroli wersji ...

Użyłem obu technik. Oba mogą służyć do zagwarantowania, że ​​te same pliki, które testujesz na @stage, kończą się na @live. Zaletą rsync jest brak dodatkowych plików (np. „.Git” i powiązanych) na serwerze produkcyjnym. Mam tendencję do rsynchronizacji z vps i używam git na własnym urządzeniu (np. Stronach intranetowych).

Problem z używaniem drush rsync polega na tym, że jeśli wiele osób wypycha zmiany na serwerze.

Twój przykład pokazuje tylko jedną osobę wprowadzającą zmiany.

Jeśli masz programistę A, który popycha jej zmiany, a następnie programistę B, popychając jego zmiany, chcesz, aby git usunął konflikty lub zmusił programistę B do usunięcia konfliktów.

Właściwie używam obu. svn / git i rsync służą dwóm różnym celom. svn / git służy do kontroli źródła rsynci sql-syncsłuży do wydajnej synchronizacji pomostowania i produkcji. drush rsync @staging @prodjest bardzo trudny do pokonania pod względem prostoty i jest strasznie łatwy do zintegrowania w większości continuous Integrationśrodowisk, jeśli chcesz nurkować jeszcze głębiej w szaleństwie / metodologii jakości kodu.

Osobiście używam Gita do kontroli wersji, wdrażania i synchronizacji różnych baz kodu serwera, a następnie rsync do przenoszenia / synchronizacji plików użytkowników (ignorowane przez dodanie określonych ścieżek do pliku .gitignore).