Как лучше всего обновлять ядро ​​Drupal, не нарушая Git-репозиторий и производственный веб-сайт?


13

У меня есть Git-репозиторий, в котором весь мой код находится в основной ветке, и ранее я просто игнорировал все файлы Drupal, так что я держал строгое разделение между кодом, который я написал (или изменил или мог изменить), и кодом это может быть сгенерировано с помощью Drush или чего-то еще.

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

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

Если я объединю drupal-7.15ветку с мастером, я потеряю разделение кода.

Вероятно, есть какой-то способ преобразовать ветку в подмодуль. Предполагая, что это возможно, это может быть лучшей стратегией. До того, как я это сделал, я знал, что подмодули были «правильным» решением, но, поскольку я не осознавал побочный эффект использования веток для ранее неотслеживаемых файлов, я решил срезать углы и пойти по этому пути. (Кроме того, все подходы, которые я видел к использованию подмодулей с Drupal, предполагают, что вы начинаете новый проект, и Drupal будет основной веткой. Мне нежелательно делать чужой код главной веткой, и у меня уже было репозиторий с мастер-веткой. Это выглядело так, как будто было бы слишком сложно просто выполнить обновление.)

Может быть какое-то другое решение, о котором я не думал.

Как я могу лучше всего оправиться от этого с наименьшим количеством возможных недостатков?

ОБНОВЛЕНИЕ : Это находится в разработке (на виртуальной машине Linux на моем ноутбуке), и еще не запущено в производство. К тому времени, когда мы перейдем к производству, я планирую все обернуть в функциональные модули, но это еще не сделано.

ОБНОВЛЕНИЕ 2 : Подмодули могут не работать. Согласно Pro Git , «Подмодули позволяют вам хранить Git-репозиторий как подкаталог другого Git-репозитория». Drupal не дает такого хорошего разделения. Вместо того, чтобы весь код Drupal находился в подкаталоге, отношения более или менее инвертированы, но чистого разделения по-прежнему нет, поскольку вы, возможно, редактируете свои .htaccess и robots.txt, поэтому ваш код и репозиторий Drupal смешаны вместе. Я ищу решение этой проблемы .


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

2
@ Летарион, я не согласен. Каждый пройдет этот процесс обновления своего сайта с текущей версии до новой. Использование git для обновления ядра довольно распространено, так как это широко используемый метод обновления модулей. Многие люди будут бороться с этой проблемой, как и раньше. В настоящее время в Интернете нет хорошей документации, посвященной этой проблеме, и я считаю, что это хорошее место для нее.
iStryker

Просто чтобы прояснить, я думаю, что вопрос о «Лучшей практике для обновления Drupal» был бы более подходящим, так как этот вопрос действительно «Как мне исправить ошибку git», которая, я думаю, не относится к этой теме. У меня нет сильных чувств по этой теме, поэтому я оставлю это на этом. :)
Летарион

Хорошо, достаточно справедливо. У Брэндона проблема довольно распространенная. Может быть, я должен создать новый вопрос или переписать этот (и переместить остальное в другой вопрос). Первые 2-3 абзаца являются общими. Вы создаете git-репозиторий 7.x-1.0 и хотите обновить его до 7.x-1.1. Проблемные файлы: .gitignore, .htaccess и robot.txt. Иногда вы хотите, чтобы они отслеживались, потому что они были модифицированы, иногда вы не хотите, чтобы они отслеживались, потому что они были изменены. При обновлении репо вы создаете новую ветку слияния или просто обновляете мастер. @ Летарион Предложение?
iStryker

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

Ответы:


10

Из приведенного выше обсуждения видно, что ваш вопрос не в исправлении вашего репозитория git, а в том, как поддерживать сайт Drupal в git и как это работает с обновлениями ядра.

Я думаю, что стандартная практика на самом деле хранит все файлы в вашем хранилище, включая ядро ​​Drupal. Отделение кода Drupal от пользовательского кода кажется хорошей идеей, но я не думаю, что это необходимо, и я не вижу, какие преимущества это дает вам. Также кажется, что вы никогда не захотите исправлять ядро ​​(или делать это как часть своего развертывания), что, хотя и не является наилучшей практикой, определенно является тем, что вы захотите сделать, если что-то сломается в производстве. Сохранение ваших коммитов красивыми и сфокусированными также помогает добиться такого разделения.

Решение, которое я использовал, заключается в том, чтобы хранить весь код в одном и том же хранилище, размещать как можно больше в компонентах или других видах экспорта / кода / конфигурации и поддерживать список исправлений, которые необходимо применить к внешним -box ядро ​​и вклад.

Когда вы обновите ядро, запустите его в своей среде разработки:

  • Убедитесь, что рабочий каталог чистый
  • Дамп последней базы данных ( drush sql-dump). Либо сделайте коммит с дампом, либо сохраните его где-нибудь в безопасности.
  • Обновить ядро ​​( drush up drupal)
  • Зафиксируйте все изменения.
  • Проверьте файл патчей. Если необходимо применить какие-либо исправления, примените их и сделайте еще один коммит
  • Запустите update.php при необходимости (уже сделано, если вы использовали drush для обновления)
  • Проверьте свой сайт разработчика. Если все в порядке, отправьте код в производство. Запустить 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, я бы сделал это, используя теги вместо веток . Как только вы закончите с вашим коммитом обновления до master , пометьте свой код как 7.x.


Если я правильно понимаю, вы также предлагаете мне хранить весь основной код Drupal в одном и том же хранилище. Это, кажется, консенсус. Я не хочу, но мне, возможно, придется сдаться и сделать это таким образом.
иконоборчество

Да, все в одном хранилище. У меня есть модули, профили и темы внутри основного / основного репозитория, которые представляют собой собственные репозитории git. Я не знаю, лучший ли это путь, но это лучший из известных мне способов.
iStryker

это решение не дает возможности вернуться назад. моя причина для голосования вниз.
Андре Баумайер

@Serpiente: Я не понимаю, почему отсутствие возможности вернуться назад должно стать причиной снижения голосов. Если это лучший подход, этого достаточно. Если вы не думаете, что это лучший подход, пожалуйста, укажите, почему нет.
иконоборчество

@iconoclast, в чем дело системы ревизий, если вы не можете вернуться в свой график? например, подумайте о неудачном обновлении - какой способ восстановления здесь? Поставляемая версия «любого» программного обеспечения должна иметь четкие зависимости, в особенности это касается ядра платформы. В противном случае вы можете просто оставить свой мерзавец и снова начать развертывание FTP. только мои 2 цента.
Андре Баумайер

0

Я запускаю установку с двумя ветвями, как OP: одна ветвь только с моим пользовательским кодом, а другая ветвь с моими пользовательскими и основными файлами. Я столкнулся с той же ситуацией: игнорируемые файлы ядра удаляются при переключении между ветками.

В итоге у меня было два идентичных каталога git: один - для работы с моим пользовательским кодом, файлы ядра присутствуют, но игнорируются, и я никогда не переключусь на «полную» ветвь в этом каталоге - один для выполнения слияний, чтобы я мог выполнить переключение и объединение ветвей только внутри этого каталога.

Причина, по которой я выбрал эту настройку с двумя ветвями, заключается в том, что я хочу легко отслеживать все локальные коммиты в файлах ядра, поэтому проще проверять и повторно применять моды ядра при обновлении файлов ядра.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.