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

Question

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

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

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

1. Не могли бы вы посоветовать начать переносить мои модули, как только у меня появится время для этого, и поддерживать параллельный D7 в течение некоторого времени (чтобы я был "готов" к D-day), или вы бы посоветовали скорее дождаться дня, в который порт будет фактически запущен неизбежный а затем обновить модули до D7 и отказаться от версии D6?
2. Только некоторые из моих модулей имеют полное тестовое покрытие.Не могли бы вы посоветовать завершить тестовое покрытие для версии D6, чтобы все тесты работали для проверки порта D7, или вы бы посоветовали написать мое руководство по тестированию во время переноса, чтобы протестировать версию D7?
3. Обнаружили ли вы, что раннее внедрение дает вам преимущество в плане новых функций и улучшенных API, или вы скорее сочли, что удобнее отложить конверсию, чтобы использовать большее количество легкодоступных модулей contrib?
4. Установили ли вы для себя стандарты качества / критерии оценки или просто установили планку "если это сработает, я счастлив"?Почему?Если вы установили определенные стандарты или цели, каковы они, где / какими они будут?Как они вам помогли?
5. Существуют ли распространенные ошибки, с которыми вы сталкивались в прошлом и которые, по вашему мнению, применимы к процессу переноса D6-D7?
6. Является ли перенос подходящим моментом для проведения некоторого рефакторинга или это просто усложнит все, что нужно собрать обратно?
7. ...

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

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

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

Answer 1

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

1. (когда начинать перенос)
   Это, безусловно, зависит от сложности переносимых модулей.Если есть действительно сложные / крупные проблемы, возможно, было бы полезно начать пораньше, чтобы найти сложные места, не испытывая при этом давления.Для небольших / стандартных я бы попытался позже найти больший временной интервал, куда я мог бы портировать многие из них подряд, чтобы быстро запомнить рутинный материал (и воспользоваться, возможно, улучшенной документацией).

2. (тестовый охват)
   Обычно я бы сказал, что, безусловно, было бы желательно иметь хорошее тестовое покрытие перед началом рефакторинга / переноса.Но учитывая, что Drupal-7 вносит серьезные изменения в платформу тестирования, перенося ее в core, я бы ожидал, что в любом случае потребуется переписать значительное количество тестов.Поэтому, если нет необходимости поддерживать версии Drupal-6 после переноса, я бы сэкономил время и проблемы и стремился к увеличению охвата после переноса.

3. (ранний последователь противподожди и увидишь)
   Используя Drupal начиная с версии 4.7, мы всегда ждали, по крайней мере, первого официального релиза новой основной версии, прежде чем даже думать о переносе.С Drupal 6 мы ждали появления модуля views, прежде чем портировать наш первый сайт, и у нас все еще есть несколько небольших проектов на Drupal-5, поскольку они работают просто отлично, и было бы трудно оправдать дополнительные счета для наших клиентов, пока для них все еще существуют исправления для обслуживания / безопасности.В сутках так много времени, и всегда есть накопившиеся ошибки, которые нужно исправить, добавить функции и т.д., Поэтому нет смысла играть с незаконченной технологией, пока есть более неотложные дела, которые немедленно принесут пользу нашим клиентам.Теперь это, безусловно, было бы по-другому, если бы нам пришлось поддерживать один или несколько "официальных" внесенных модулей, поскольку предложение раннего порта было бы хорошим решением.
   Здесь я немного в затруднительном положении - быть ранним пользователем, безусловно, приносит пользу сообществу, поскольку кто-то должен найти эти ошибки, прежде чем их можно будет исправить, но, с другой стороны, нет особого делового смысла час за часом бороться с ошибками, которые другие могли бы найти / исправить, если бы вы просто подождали немного дольше.До тех пор, пока мне приходится зарабатывать этим на жизнь, мне нужно следить за своими ресурсами, пытаясь найти приемлемый баланс между служением обществу и получением от него выгоды :-/

4. (стандарты качества)
   "Если это сработает, я счастлив" просто не подходит, потому что я хочу быть счастливым не только на мгновение, но и завтра.Итак, один из моих стандартов качества заключается в том, что мне нужно быть (в некоторой степени) уверенным в том, что я достаточно хорошо "грокнул" новые концепции, чтобы не просто заставить вещи работать, но и заставить их работать так, как они должны.Теперь это трудно определить более точно, поскольку, очевидно, невозможно узнать, "получил ли кто-то это" до того, как "получил это", так что это сводится к внутреннему ощущению / различию "да, это вроде как работает" против"да, это выглядит правильно", и человек должен смириться с тем, что он довольно регулярно будет ошибаться на этот счет.
   Тем не менее, один конкретный момент, на который я обращаю внимание, - это "вмешаться как можно раньше".Как новичок, я часто подправлял материал "постфактум" на этапе создания темы, в то время как было бы намного проще применить "исправление" ранее в цепочке обработки с помощью того или иного хука.Поэтому прямо сейчас, всякий раз, когда я собираюсь что-то "подкорректировать" в тематическом слое, я намеренно беру небольшой тайм-аут, чтобы проверить, нельзя ли это сделать более чисто / совместимо с помощью хука ранее.Поскольку я ожидаю, что Drupal-7 добавит еще больше опций подключения, этому я уделю особое внимание, поскольку это обычно уменьшает конфликты и внезапное "ломание материала" при добавлении новых модулей.

5. (распространенные подводные камни)
   Ну, в основном, портирование на early, выяснение впоследствии / в промежутке, что один или несколько необходимых модулей вообще недоступны для новой версии или только в состоянии dev / alpha / early beta.Поэтому я бы обязательно скомпилировал полный сначала список используемых / необходимых модулей с указанием состояния их переноса, а также краткая проверка очередей их выпуска.
   Кроме того, я до сих пор всегда был очень доволен новыми версиями и их улучшениями, и я с нетерпением жду выхода Drupal-7 снова.

6. (рефакторинг при переносе)
   Можно было бы сказать, что портирование само по себе является довольно крупным рефакторингом, поэтому нет необходимости усложнять процесс реструктуризацией материалов, не связанных с портированием.С другой стороны, если вам все равно уже приходится разбирать свои модули на части, почему бы не воспользоваться возможностью провести капитальный ремонт?Я бы попытался провести линию, основанную на сложности - для больших / сложных модулей я бы сделал порт как можно более прямым, а позже, при необходимости, провел бы дополнительный рефакторинг.Для небольших модулей это не должно иметь большого значения, так как вероятность появления незначительных ошибок должна быть довольно небольшой.

7. (другие вещи)
   ...нужно подумать об этом ...

---

Ладно, другие вещи:

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

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