(dis) переваги інсценізації розробки> використання "drush rsync" vs "git"?

9

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

Це створено в майстер, оголеному GIT-репо, і коли зміни вносяться в мої різні клони проектних робіт і відштовхуються назад до майстра, гачок після оновлення негайно підштовхує зміни до єдиного веб-сайту Staging (http: / /staging.loc.). Нічого особливого, працює як очікувалося.

Я також друкував сайт "@STAGING". Іноді я хочу просувати свої зміни від сайту Staging до виробничого сервера.

Приходять до уваги два досить прості методи:

(1) У той момент, коли сайт "Постановка" здається стабільним, створіть виробничий сайт у вигляді git checkout від головного репо,

(2) використання drush rsync+ drush sql-syncвід місця постановки до місця виробництва.

І те й інше можна змусити працювати. За винятком того, що (2) здається більш орієнтованим на Друпала / усвідомлює природу - друш, зрештою, специфічний для Друпала набір інструментів - які відносні достоїнства двох підходів?

Чи є якась конкретна причина, яку я повинен розглянути (1) над (2)?

У будь-якому випадку "Все" знаходиться під принаймні одним примірником контролю ревізії ...

drush version-control staging

— Клайв
джерело

3

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

— greg_1_anderson
джерело

Дякую за точку. Я просто розглядав варіанти виключення. Це допомагає підтримувати чистоту. Iiuc, мені потрібно вказати, що потрібно виключити "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"у файлі .rc, хоча я ще не впевнений, чи потрібно мені це як у специфікаціях вихідного, так і в цільовому псевдонімі або лише в одному чи іншому.

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

— greg_1_anderson

Мені потрібно прочитати докладніше; Я не усвідомлював, що .git виключений. Дякуємо також за підказку для імітації. Re: ОП, я думаю, я буду дотримуватися "drush rsync", оскільки він розроблений як метод розгортання для drupal & works. git, звичайно, може працювати, але зараз я натрапив на достатню кількість коментарів, що він не призначений для розгортання ...

1

Проблема використання rsync drush полягає в тому, що якщо у вас є кілька людей, які натискають зміни на сервер.

У вашому прикладі показано лише одну людину, яка натискає на зміни.

Якщо у вас є розробник A, який підштовхує її зміни, а потім розробник B підштовхує його зміни, ви хочете, щоб git прибирав конфлікти, або змушував розробника B прибирати конфлікти.

— Мікес Герман
джерело

1

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

— стефгоселін
джерело

1

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

— данбохея
джерело