Обновление с Drupal 6 до Drupal 7: лучшие практики программистов?

Хотя я использую drupal с D4-серии, я только начал профессионально развиваться для него с D6, поэтому - несмотря на то, что я делал различные обновления сайта - мне никогда не приходилось сталкиваться с задачей переносить мой собственный код в новую версию.

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

Однако то, что я ищу с моим вопросом, больше в линии стратегического мышления, или, другими словами, Я ищу материалы и советы о том, как планировать/внедрять/проверять процесс портирования собственных кода, в свете того, что разработчики коллег узнали по предыдущему опыту. Пример:

Вы бы посоветовали начать переносить мои модули, как только у меня есть время для этого, и поддерживать некоторое время D7 в течение некоторого времени (так что я "готов" к D-day), или вы бы посоветовали скорее дождитесь дня, когда порт будет на самом деле неизбежен, а затем обновите модули до D7 и опустите версию D6?
Только некоторые из моих модулей имеют полный охват тестирования. Вы бы посоветовали заполнить тестовое покрытие для версии D6, чтобы все тесты работали над проверкой порта D7, или вы бы посоветовали написать мое тестовое руководство во время портирования, чтобы протестировать версию D7?
Вы обнаружили, что, будучи ранним усыновителем, вы получаете преимущество в отношении новых функций и улучшенного API, или вы скорее обнаружили, что более удобно откладывать преобразование, чтобы использовать большее количество доступных модулей Contrib?
Вы установили для себя стандарты качества/критерии оценки, или вы просто установили планку "если это работает, я счастлив"? Зачем? Если вы устанавливаете определенные стандарты или цели, что они там, где они будут? Как они вам помогли?
Есть ли распространенные ошибки, которые вы испытали в прошлом и которые, по вашему мнению, применимы к процессу переноса D6-D7?
Портирует хороший момент, чтобы сделать какой-то рефакторинг, или просто собирается сделать все более сложным, чтобы его снова объединить?
...

Эти вопросы не являются исчерпывающим списком, но я надеюсь, что они дадут представление о том, какую информацию я ищу. Я бы сказал: все, что вы считаете релевантным, и я не перечислял выше, получает "плюс"!:)

Если я не смог выразить себя достаточно ясно, напишите комментарий с информацией, которую, по вашему мнению, я должен добавить в вопрос. Заранее благодарю вас за ваше время!

PS: Да, я знаю... D7 еще не вышел, и потребуется несколько месяцев, прежде чем важные модули будут обновлены... но никогда не начинать думать!:)

Ответ 1

Хорошие вопросы, поэтому давайте посмотрим:

(когда начать портирование)
Это, безусловно, зависит от сложности модулей к порту. Если есть действительно сложные/большие, может быть полезно начать рано, чтобы найти хитрые пятна, не находясь под давлением. Для более мелких/стандартных я попытался найти более крупный временной интервал позже, где я смогу перенести многие из них подряд, чтобы быстро занести в заставку рутину (и извлечь выгоду из, вероятно, улучшенной документации).
(тестовое покрытие)
Обычно я бы сказал, что наличие хорошего тестового покрытия до начала рефакторинга/портирования, безусловно, было бы целесообразным. Но учитывая, что Drupal-7 вносит существенные изменения в структуру тестирования, переместив его в ядро, я бы ожидал, что в любом случае потребуется переписать значительное количество тестов. Поэтому, если после переноса нет необходимости поддерживать версии Drupal-6, я бы сэкономил время/проблемы и постарался увеличить охват после портирования.
(раннее усыновление против ожидания и просмотра)
Используя Drupal с версии 4.7, мы всегда ждали, по крайней мере, первого официального выпуска новой крупной версии, прежде чем даже подумывать о портировании. С Drupal 6 мы дождались модуля views перед переносом нашего первого сайта, и у нас все еще есть небольшие проекты на Drupal-5, так как они работают очень хорошо, и было бы сложно оправдать дополнительный счет для наших клиентов, пока для него все еще существуют исправления по техническому обслуживанию/безопасности. Просто так много времени в день, и всегда есть это отставание от ошибок для исправления, добавление функций и т.д., Поэтому не нужно играть с незавершенными технологиями, в то время как есть более неотложные вещи, которые могут сделать это, это принесет пользу нашим клиентам. Теперь это было бы иначе, если бы нам пришлось поддерживать один или несколько "официальных" модулей, поскольку предлагать ранний порт было бы неплохо.
Я немного привязан к этому месту - раннее усыновление, безусловно, приносит пользу сообществу, так как кто-то должен найти эти ошибки до того, как они могут быть исправлены, но, с другой стороны, это не имеет большого смысла для ведения бизнеса с каждым часом с ошибками другие могли бы найти/исправлены, если бы вы просто ждали немного дольше. Пока я должен делать это ради жизни, мне нужно следить за моими ресурсами, пытаясь найти приемлемый баланс между служением обществу и выгодой от него: -/
(стандарты качества)
"Если это сработает, я счастлив", это просто не режет, так как я не хочу быть счастливым только на мгновение, но и завтра. Поэтому один из моих стандартов качества - это то, что мне нужно (в некоторой степени) уверенно, что я достаточно хорошо разбираюсь в новых концепциях, чтобы не просто заставить вещи работать, а заставить их работать так, как должны. Теперь это трудно определить более точно, поскольку, очевидно, невозможно узнать, "если он" получил его до "получения", поэтому он сводится к ощущению/различию кишки "да, это вроде работает" против "yup", это выглядит правильно ", и нужно признать, что он будет регулярно ошибаться. Тем не менее, один конкретный момент, который я ищу, - "вмешаться как можно раньше". Будучи новичком, я часто настраивал материал "после факта" во время тематической стадии, в то время как было бы гораздо проще применить "исправление" ранее в цепочке обработки с помощью одного крючка или другого. Так что прямо сейчас, когда я собираюсь "настроить" что-то в слое темы, я намеренно занимаю небольшой промежуток времени, чтобы проверить, нельзя ли это сделать более чистым/совместимым в начале ранее. Поскольку я ожидаю, что Drupal-7 добавит еще больше вариантов подключения, я буду уделять дополнительное внимание, поскольку это обычно уменьшает конфликты и внезапное "переполнение" при добавлении новых модулей.
(распространенные ошибки)
Хорошо - в основном портирование на ранний срок, выяснение впоследствии/между тем, что один или несколько необходимых модулей были недоступны для новой версии вообще или только в состоянии dev/alpha/early beta. Поэтому я должен сначала составить полный список используемых/необходимых модулей, указав их состояние переноса, а также быстро проверить их очереди на выпуск.
Кроме того, я до сих пор всегда был очень доволен новыми версиями и их улучшениями, и я снова жду Drupal-7.
(рефакторинг при портировании)
Можно сказать, что портирование - это довольно большой рефакторинг сам по себе, поэтому нет необходимости добавлять к сложности путем реструктуризации, не перенося связанные вещи. С другой стороны, если вам все равно придется клонировать ваши модули на части, почему бы не использовать эту возможность, чтобы сделать ее капитальным ремонтом? Я бы попытался нарисовать линию, основанную на сложности - для больших/сложных модулей я бы сделал порт как можно более прямым, и рефакторинг позже, если понадобится. Для небольших модулей это не имеет большого значения, так как вероятность введения тонких ошибок должна быть довольно небольшой.
(прочее)
... нужно подумать об этом...

Хорошо, другие вещи:

Потребности в ресурсах - учитывая некоторые из потоков Drupal-7, похоже, что они, вероятно, будут повышаться, поэтому это нужно оценить перед переносом небольших сайтов, которые размещаются на общей/ограниченной учетной записи хостинга.
Последние версии в первую очередь - это довольно очевидно и всегда подчеркивается в руководствах по обновлению, но, тем не менее, стоит упомянуть: обновить основное ядро и все модули до их последней текущей версии, прежде чем выполнять крупное обновление, поскольку код обновления вероятно, будут зависеть от того, что последние таблицы/структуры данных будут работать правильно. Учитывая "поэтапное" Drupals "один шаг за шагом по обновлению", было бы очень сложно реализовать код обновления, который бы обнаруживал разные состояния перед обновлением и действовал соответственно.