Яка найкраща практика для модернізації ядра Drupal, не порушуючи репортажу Git та виробничого веб-сайту


13

У мене є сховище Git, в якому весь мій код знаходиться у головній гілці, і я раніше просто ігнорував усі файли Drupal, так що я зберігав суворе розділення між кодом, який я написав (або змінив або міг змінити), і кодом що може бути породжене Друшем чи чим завгодно.

Це здавалося гарною стратегією, поки мені не довелося модернізувати Drupal. Я зрозумів, що хочу мати змогу відкотитись, якщо справи пішли погано, і який кращий інструмент використовувати, ніж Git для цього. Я думав, що це буде ідеальною ситуацією для гілки функцій, тому я створив drupal-7.14гілку, дав їй своє .gitignoreігнорувати всі мої файли коду та налаштувань і звертати увагу лише на файли, що входять до інсталяції Drupal, які я б не хотів ' не торкатися. Я здійснив оновлення вручну (скачати, скасувати, untar, скопіювати), сортуючи прикордонні випадки, такі як robots.txt та .htaccess, і замінив .gitignore Drupal на мій власний. Я виправив деякі налаштування, які працювали з 7.14, але не з 7.15, щоб відновити помилку 500, і тоді все здавалося ідеальним. Я перейменував гілку на drupal-7.15та збирався йти щасливим шляхом.

Поки я не зрозумів, що я зробив ненавмисно: файли, які раніше не відслідковувались моїм головним відділенням, але залишалися в робочому каталозі, тепер видалялися з робочого каталогу, коли я перевіряв майстер, оскільки вони вже не були відхиленими файлами! D'oh!

Якщо я об'єднаю drupal-7.15гілку з master, я втрачу розділення коду.

Можливо, є якийсь спосіб перетворити гілку на підмодуль. Якщо припустити, що це можливо, це може бути найкращою стратегією. До того, як я це зробив, я знав, що підмодулі - це «правильне» рішення, але оскільки я не усвідомлював побічний ефект від використання гілок для раніше не відстежуваних файлів, вирішив вирізати кути і піти цим маршрутом. (Крім того, всі підходи, які я бачив до використання підмодулів з Drupal, припускають, що ви починаєте новий проект, і Drupal буде головним відділенням. Мені небажано робити чийсь код основним відділенням, і я вже мав репо з головним відділенням. Це виглядало так, що це було б зайво складним, просто зробити оновлення.)

Можливо, є якесь інше рішення, про яке я не думав.

Як мені найкраще оговтатися від цього за допомогою найменших можливих недоліків?

ОНОВЛЕННЯ : Цей процес розробляється (в VM Linux на моєму ноутбуці), і він ще не перейшов до виробництва. До моменту, коли ми переходимо до виробництва, я планую все, що буде загорнуто у функціональні модулі, але це ще не на місці.

ОНОВЛЕННЯ 2 : Підмодулі можуть не працювати. За словами Pro Git , "Підмодулі дозволяють зберігати сховище Git як підкаталог іншого сховища Git". Drupal не забезпечує такого гарного розлуки. Замість того, щоб увесь код Drupal знаходився у підкаталозі, відносини більш-менш перевернуті, але все ще немає чистого розмежування, оскільки ви можете редагувати свої .htaccess і robots.txt, тому ваш код та repo Drupal змішуються разом. Я шукаю вирішення цієї проблеми .


Ваше запитання справді стосується git. Я думаю, ви отримаєте кращі відповіді, перемістивши їх на сайт, який не є специфічним для Drupal. Про оновлення: я завжди роблю оновлення, будуючи файл make в новому каталозі, а потім оновлюю симпосилання зі старого до нового загальнодоступного каталогу, що робить відкат коду тривіальним.
Летаріон

2
@ Летаріон Я не згоден. Усі пройдуть цей процес оновлення свого веб-сайту зі своєї поточної версії до нової. Використання git для оновлення ядра досить поширене, оскільки це широко застосовуваний метод оновлення модулів. Дуже багато людей боротимуться з цією проблемою, як я мав раніше. Наразі в Інтернеті немає гарної документації, яка б вирішувала це питання, і я вважаю, що це хороше місце для цього.
iStryker

Просто для уточнення, я думаю, що питання про "Найкращі спостереження за оновленням Drupal" було б тоді більш підходящим, оскільки це питання справді "Як мені виправити помилку в git", і я не думаю, що тут належу. Не майте жодних сильних почуттів щодо цієї теми, тому я залишу це на цьому. :)
Летаріон

Добре справедливо. Проблема, яку має Брендон, досить поширена. Можливо, я повинен створити нове запитання або переписати це (а решту перенести на інше питання). Перші 2-3 абзаци є загальними. Ви створюєте git repo 7.x-1.0 і хочете оновити до 7.x-1.1. Файли проблем: .gitignore, .htaccess та robot.txt. Іноді ви хочете, щоб вони відстежували, тому що вони модифіковані, а іноді ви не хочете, щоб їх відстежували, тому що вони модифіковані. Під час оновлення репо ви створюєте нову гілку злиття або просто оновлюєте мастер. @Letharion Пропозиція?
iStryker

@Letharion: Я думав над тим, чи ставити це на StackOverflow як питання Git або тут як питання про Drupal. Якби я помістив це, всі скаржилися б і говорили, що це справді стосується Drupal, і я думаю, що вони дійсно мали б рацію. Навіть незважаючи на те, що Git може бути інструментом, який використовується для виправлення ситуації, напрямок залежить від знання Drupal. Кожен користувач Drupal використовує Git (або він повинен, якщо цього немає), але лише невелика частина користувачів Git використовує Drupal. Люди, які відповідають на запитання про Git, не збираються розуміти фон компанії Drupal.
іконоборство

Відповіді:


10

З вищезгаданого обговорення виходить, що ваше питання стосується не виправлення вашого git repo, а щодо підтримки сайту Drupal в git та того, як це працює з основними оновленнями.

Я думаю, що стандартна практика насправді зберігає всі файли у вашому сховищі, включаючи ядро ​​Drupal. Відокремлення коду Drupal від користувацького коду здається приємною ідеєю, але я не думаю, що це потрібно, і я не бачу, які переваги він дає вам. Також, здається, припускається, що ви ніколи не захочете виправити ядро ​​(або робити це потрібно як частину свого розгортання), що, хоча це не найкраща практика, безумовно, те, що ви хочете зробити, якщо щось зламається у виробництві. Дотримуйтесь прихильності та зосередженості ваших зобов’язань також допомагає отримати такий спосіб розлуки.

Я використовував рішення - зберігати весь код у одному сховищі, розміщувати якомога більше у функціях чи інших видах експорту / коду / конфігурації та підтримувати список патчів, які потрібно застосувати до поза -box ядро ​​та contrib.

Коли ви оновлюєте ядро, почніть в середовищі розробників:

  • Переконайтесь, що робочий каталог чистий
  • Вивантажте останню базу даних ( drush sql-dump). Або взяти на себе звалище або зберегти його десь у безпеці.
  • Оновити core ( drush up drupal)
  • Здійснити всі зміни.
  • Перевірте файл виправлень. Якщо потрібні будь-які виправлення, застосуйте їх та зробіть ще один виправлення
  • Запустіть update.php, якщо необхідно (вже зроблено, якщо для оновлення ви використовували ударну машину)
  • Перевірте свій розробник. Якщо все в порядку, наведіть код на виробництво. Запуск drush updbна виробництві.
  • Якщо є проблема, і вам потрібно повернути або відновити або скинути репо ( git reset --hard HEAD~2якщо це потрібно зробити), або повернути два комітети, якщо ви хочете зберегти історію. Замініть свою базу даних на дамп.

Дамп для бази даних необхідний, оскільки в іншому випадку ви не можете скасувати зміни, внесені до бази даних за допомогою оновлень. Ви також можете зробити оновлення у гілці, і в такому випадку повернення просто означає перевірку майстра. Це трохи недоцільно, якщо ви працюєте на одному веб-сайті розробників, оскільки ви не можете реально перейти назад до майстра і продовжувати працювати паралельно через базу даних.

Використання цього більш простого документообігу git дозволить вам використовувати повну потужність git, коли вам це потрібно без ускладнень підмодулів тощо. Якщо це не здається адекватним, чи можете ви пояснити, чому вам потрібно подальше розділення коду?


0

З моїх коментарів вище, це питання у вас стосується підтримки файлів сайту Drupal за допомогою git та того, як це працює з основними оновленнями. Ви нічого не згадували про створення резервної копії та оновлення бази даних. Я постараюся нічого не копіювати з відповіді горона.

Я створив публікацію в блозі про цю проблему Оновлення ядра Drupal на вашому веб-сайті за допомогою Git

Альтернативні методи

  1. Запустіть команду Drush drush up drupal
  2. Застосуйте виправлення відмінностей між версіями. Дивіться http://drupal.org/node/359234 & http://fuerstnet.de/en/drupal-upgrade-easier

Ви цього не заявляли, але якщо вам цікаво відстежувати зміни між версіями Drupal, я б це зробив, використовуючи теги замість гілок . Після того, як ви закінчите з оновленням зобов’язання провести майстер , позначте свій код як 7.x.


Якщо я правильно розумію, ви також пропонуєте мені зберігати весь основний код Drupal в одному сховищі. Це, мабуть, є консенсусом. Я неохоче, але, можливо, мені доведеться поступатися і робити це саме так.
іконоборство

Так, все в одному сховищі. У мене є модулі, профілі та теми всередині основного / основного сховища, які є їх власними git repos. Я не знаю, чи найкращий спосіб, але це найкращий спосіб, про який я знаю.
iStryker

це рішення не забезпечує можливості повернутися назад. моя причина для голосування.
Andre Baumeier

@Serpiente: Я не розумію, чому відсутність способу повернутися назад може стати причиною зниження події. Якщо це найкращий підхід, цього достатньо. Якщо ви не вважаєте, що це найкращий підхід, вкажіть, чому б ні.
іконоборство

@iconoclast У чому полягає ревізійна система, якщо ви не можете повернутися на свою часову шкалу? наприклад, подумайте про невдале оновлення - який би спосіб було відновити тут? Поставлена ​​версія програмного забезпечення "що завгодно" має мати чіткі залежності, зокрема, до основних ядер. В іншому випадку ви можете просто кинути свою гру і знову почати робити розсилки FTP. тільки мої 2 копійки.
Андре Баум'є

0

Я запускаю налаштування з двома гілками, як і в ОП: одна гілка з моїм власним кодом і одна гілка, яка має і мої власні, і основні файли. Я зіткнувся з тією ж ситуацією: ігноровані основні файли видаляються при перемиканні між гілками.

У мене з'явилися два однакові каталоги git: - один для роботи над моїм власним кодом, з основними файлами, присутніми, але проігнорованими, і я ніколи не переходив би до "повної" гілки в цьому каталозі - один для виконання об'єднань, так що я б виконувати перемикання гілок та злиття лише всередині цього каталогу.

Причиною того, що я вибираю цю установку з двох гілок, є те, що я хочу легко відслідковувати всі локальні зобов’язання до основних файлів, простіше вивчити та повторно застосувати основні моди під час оновлення основних файлів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.