Практический подход к обновлению jQuery?

на самом деле ответить на ваши три вопроса, вот некоторые вещи, которые я сделал или, по крайней мере, рекомендую:

лучшие практики для плавного обновления

• тесты. Это могут быть модульные тесты для ваших тестов JS и/или браузера. Они должны охватывать, по крайней мере, наиболее типичные и сложные функции, используемые в ваших проектах. Если у вас нет тестов, напишите их. Если не хочешь писать тесты, подумай еще раз. Если вы reeeeally не хотите писать тесты, по крайней мере, есть список вариантов использования, которые кто-то сможет выполнить вручную.
• убедитесь, что все ваши тесты проходят перед обновлением.
• прочитайте примечания к выпуску для (основная) версия между версией, которую вы используете сейчас, и самой последней версией. См. также удалены и устаревший категории В документах API. Если какой-либо из ваших кодов использует jQuery UI, также посмотрите эти заметки о выпуске и руководство по обновлению для интерстициальных версий. При этом обратите внимание на то, что вам, вероятно, придется изменить в своей кодовой базе (возможно, интенсивно используя grep).
• если текущая версия jQuery вашего проекта >= 1.6.4, также рассмотрите возможность использования в jQuery перенести плагин для дальнейшей оценки требуемых работ.
• решите, на какой версии вы хотите быть вашей целью обновления, на основе работы, необходимой для получите там, использует ли ваш проект какие-либо сторонние библиотеки, требующие определенной версии jQuery, другие факторы, которые только вы можете рассмотреть и т. д.
• встретиться с вашей командой, чтобы перейти по списку изменений, которые должны быть сделаны в вашей кодовой базе, и разделить/назначить работу соответственно. Может быть, написать несколько сценариев или другие инструменты, чтобы помочь. Если у вас есть один, руководство по стилю кодирования вашей команды / документ лучших практик также может потребоваться обновить. Решите однократное (рекомендуемое) или скользящее обновление релизы, если это возможно+желательно. Придумайте подходящую стратегию выпуска. (Я рекомендую не выпускать обновление как часть другого несвязанного большого изменения в вашей кодовой базе, поэтому легко откатить, если вам нужно.)
• на протяжении всего процесса обновления, постоянно выполнять тесты. При тестировании вручную всегда контролируйте консоль браузера на наличие новых ошибок. Напишите новые тесты, которые охватывают непредвиденные ошибки.
• когда все тесты проходят, решите, как вы хотите ролл out--если это сайт, Все пользователи сразу или процент за раз и т. д. Для библиотеки или другого проекта, возможно, вы выпустили бы бета-версию/bleeding edge, которую вы можете позволить своим более амбициозным пользователям тестировать для вас в дикой природе.
• документировать все, что вы только что сделали, так что в следующий раз будет проще.
• [получить прибыль.]

как интегрировать обновления в обычный рабочий процесс

• опять же, тесты. Убедитесь, что они у вас есть. Убедитесь, что они хороши, поддерживаются и охватывают большую часть вашей кодовой базы и вариантов использования. Настоятельно рекомендуется установка непрерывной интеграции для автоматизации выполнения этих тестов.
• подумайте о том, чтобы ваша команда создала и согласилась следовать руководству по стилю кодирования или стандарту. Это облегчит в будущем поиск устаревших вызовов функций или конструкций, поскольку все будут следовать аналогичным шаблонам кодирования. Такие инструменты, как скрипты, крючки фиксации, статические анализ utils, etc. для обеспечения хорошего или вынюхивания плохого стиля кодирования может быть полезно (в зависимости от команды).
• исследовать и, возможно, решить использовать менеджер пакетов, как NPM или беседке для управления версиями jQuery и другими сторонними библиотеками вы можете использовать зависящие от него. (Вам все равно нужно будет поддерживать свой собственный код JS и проходить почти тот же процесс, что и выше.)
• опять же, как только вы прошли версию 1.6.4, убедитесь, что Migrate plugin является частью рабочего процесса обновления.
• оцените, что работало от начального большого процесса обновления, что не сработало, и извлеките общий процесс из этого, который лучше всего работает с вашим текущим рабочим процессом. Независимо от того, планируете ли вы обновлять каждый раз, когда есть новая версия, будут текущие задачи обслуживания и привычки, которые вы, вероятно, захотите сохранить как общие рекомендации по разработке.

разумный апгрейд расписание

это, по сути, вопрос управления рисками/CBA. Вам придется взвесить некоторые вещи:

• здесь должны не нарушайте изменения API в одной и той же основной версии, поэтому вы, как правило, сможете перейти на самую последнюю минорную версию с минимальными усилиями, без необходимости рефакторинга. Это предполагает, что у вас есть и поддерживают хорошие тесты, которые вы можете запустить на своих проектах, прежде чем решить, что все достаточно хорошо для откачка.
• новые версии требуют больше исследований, больше рефакторинга и тестирования. После этапа исследования необходимо провести анализ затрат и выгод модернизации.
• это может не иметь большого значения, но если какой-либо из ваших проектов является веб-сайтом, на котором много пользователей, какова будет стоимость того, чтобы все ваши пользователи должны были загрузить по существу все измененные файлы JS на вашем сайте при следующем посещении (вместо того, чтобы придерживаться старых версий, которые вероятно, все еще кэшируются в своих браузерах)?
• решение об обновлении всегда должно быть субъективным. Минор или майор, вам все равно придется каждый раз оправдывать, стоит ли какое-либо обновление. всегда читайте заметки о выпуске. это исправить уязвимость системы безопасности или ошибка, связанная с проблемами, которые вы или ваши пользователи в настоящее время испытывают? Будет ли это значительно улучшить производительность вашего проекта (обязательно иметь ориентиры для его проверки позже)? Значительно ли это упрощает шаблон кодирования, который вы используете, позволяя вашему коду быть написанным более чисто и легко? Есть ли сторонняя библиотека, которую вы хотите использовать, которая зависит от этой новой версии? Есть сторонние библиотеки, которые вы уже используете, которые зависят от старше версия? (Если да, то эти библиотеки, вероятно, будут обновлены в ближайшее время для работы с более новой версией?) Вы настолько уверены в своих тестах и процессе QA, что обновление займет разумный объем ресурсов развития и не вызывает серьезных регрессий? Вы думали в конечном итоге переключить jQuery на что-то еще? Так далее.

конечно, это только мой совет. В нем есть несколько повторяющихся тем, и я надеюсь, что они ясны. В любом случае, я надеюсь, что кто-то найдет это полезным!