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

9

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 ...

drush version-control staging Clive
źródło

Odpowiedzi:

3

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).

greg_1_anderson
źródło
Dzięki za punkt. Właśnie patrzyłem na opcje wykluczenia. To pomaga utrzymać porządek. Iiuc, muszę określić, z czym mam wykluczyć "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"w pliku .rc, chociaż nie jestem jeszcze pewien, czy potrzebuję tego zarówno w specyfikacji aliasu źródłowego i docelowego, czy tylko w jednym lub drugim.
.git powinien być domyślnie ignorowany. Uruchom 'drush --simulate rsync [opcje] @a @b', aby zobaczyć dokładne polecenie rsync, które uruchomi Drush. Użyj --include-vcs, jeśli chcesz, aby drush rsync zawierał pliki .git i inne powiązane pliki vcs.
greg_1_anderson
Muszę przeczytać bardziej szczegółowo; Nie zdawałem sobie sprawy, że .git został wykluczony. Dziękuję również za podpowiedź do symulacji. Re: OP, myślę, że będę trzymać się 'drush rsync', ponieważ jest on zaprojektowany jako metoda wdrażania dla drupala i działa. git może oczywiście działać, ale natknąłem się już na tyle komentarzy, że nie jest przeznaczony do wdrożenia ...
1

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.

Micheas Herman
źródło
1

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.

stefgosselin
źródło
1

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).

Danbohea
źródło