(dis) преимущества постановки dev-> production с использованием 'drush rsync' против 'git'?

9

Я создал сайт Drupal под контролем git для разработки.

Он был добавлен в мастер-репозиторий GIT, и по мере внесения изменений в мои различные клоны git, работающие над проектами, и отодвигается обратно к мастеру, ловушка после обновления немедленно отправляет изменения на один живой промежуточный веб-сайт (http: / /staging.loc.). Ничего особенного, работает как положено.

Я также добавил псевдоним на сайт "@STAGING". Иногда я хочу рекламировать свои изменения с промежуточного сайта на рабочий сервер.

На ум приходят два относительно простых метода:

(1) В тот момент, когда промежуточный сайт выглядит стабильным, создайте производственный сайт в качестве git checkout из главного репо,

(2) использовать drush rsync+ drush sql-syncот промежуточной площадки до производственной площадки.

Оба можно заставить работать. Кроме того факта, что (2) кажется более ориентированным на Drupal / осведомленным по своей природе - в конце концов, drush - это набор инструментов для Drupal - каковы относительные достоинства этих двух подходов?

Есть ли какая-то конкретная причина, по которой я должен рассмотреть (1) над (2)?

В любом случае «Все» находится как минимум под одним экземпляром контроля версий ...

drush version-control staging

— Клайв
источник

3

Я использовал обе техники. Оба могут быть использованы для гарантии того, что те же файлы, которые вы тестируете на @stage, попадут на @live. Преимущество rsync заключается в том, что на рабочем сервере у вас нет лишних файлов (например, «.git» и связанных с ними). Я имею тенденцию rsync к vps, и использую git на принадлежащей мне коробке (например, на сайтах интрасети).

— greg_1_anderson
источник

Спасибо за точку. Я просто смотрел на варианты исключения. Это помогает содержать вещи в чистоте. Июк, мне нужно указать, что исключать "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"в файле .rc, хотя я пока не уверен, нужно ли мне это в спецификациях как исходного, так и целевого псевдонима, или просто одного или другого.

.git должен игнорироваться по умолчанию. Запустите 'drush --simulate rsync [опции] @a @b', чтобы увидеть точную команду rsync, которую запустит Drush. Используйте --include-vcs, если вы хотите, чтобы drush rsync включал .git и другие файлы, связанные с vcs.

— greg_1_anderson

Мне нужно прочитать более подробно; Я не понял, что .git был исключен. Спасибо за подсказку симуляции тоже. Re: OP, я думаю, что я буду придерживаться 'drush rsync', так как он предназначен для развертывания drupal & works. git, конечно, может работать, но теперь я нашел достаточно комментариев, которые не предназначены для развертывания ...

1

Проблема с использованием drush rsync заключается в том, что если у вас есть несколько человек, отправляющих изменения на сервер.

Ваш пример показывает только один человек, толкающий изменения.

Если у вас есть разработчик A, который вносит свои изменения, а затем разработчик B, вносящий свои изменения, вы хотите, чтобы git убирал конфликты, или заставлял разработчика B уничтожать конфликты.

— Михей Герман
источник

1

Я на самом деле использую оба. svn / git и rsync служат двум различным целям. svn / git предназначен для управления исходным кодом, rsyncа также sql-syncдля эффективной синхронизации этапов и программ. drush rsync @staging @prodего очень трудно превзойти с точки зрения простоты, и его ужасно легко интегрировать практически в любую continuous Integrationсреду, если вы захотите еще глубже погрузиться в сумасшествие / методологии качества кода.

— stefgosselin
источник

1

Лично я использую Git для контроля версий, развертывания и синхронизации различных серверных кодовых баз, а затем rsync для перемещения / синхронизации пользовательских файлов (игнорируется путем добавления определенных путей к файлу .gitignore).

— danbohea
источник