Ответ 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 "один шаг за шагом по обновлению", было бы очень сложно реализовать код обновления, который бы обнаруживал разные состояния перед обновлением и действовал соответственно.