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

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

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

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

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

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

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

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

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

Хорошо, другое материал:

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

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