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

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

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

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

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

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

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

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

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

Хорошо, другое:

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

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