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

Некоторые из проектов, над которыми мы работаем, имеют сильные корни в jQuery 1.4.2 или ранее, а где-то между отсутствием предела производительности (или синтаксического сахара) последних выпусков, унижением использования устаревших методов и дискомфорт при развертывании 3+-летней версии активно поддерживаемой библиотеки, обновление теперь неизбежно.

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

Ответ 1

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

Рекомендации по плавному развертыванию обновлений

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

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

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

Разумное расписание обновлений

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

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

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

Ответ 2

Вы всегда будете устаревшими. После того, как вы закончите обновление до последней версии, более новая версия появится через несколько месяцев.

Если вы не хотите указывать часы/дни/недели разработки, тестирования и исправления ошибок, с возможностью нарушения функциональности, ориентированной на пользователя, вы не должны обновлять, чтобы использовать новейший способ объявления обработчиков событий. Это не повредит вам. И обычно это рискованно. Это приводит к затратам команды разработчиков. Вы уже это знаете. Рефакторинг, особенно когда нет очевидного риска для проекта, в целом трудно оправдать для менеджеров. И вы должны дважды проверить свои мысли, чтобы убедиться, что если новый jQuery в уже работающем коде будет иметь значение.

Теперь, если вы работаете над созданием новых страниц на существующем сайте, вы можете включить новую версию в эти области. Но это будет иметь последствия: предположим, что вы и ваша команда, помимо разработки новой части сайта, также должны поддерживать часть, использующую старую. Все должны знать конкретную версию jQuery, с которой они пишут свой код.

Итак, чтобы закрыть, я бы сказал что-то вроде этого. Если существует реальный обоснованный риск для проекта, который задерживается или будет технически заблокирован из-за более старой версии jQuery, у вас возникнут проблемы с взломом чего-то, что уже работает, и вам нужно будет добавить дополнительные часы, чтобы сделать все так же как и раньше.

Во всяком случае, этот подход не означает, что вы можете начать разделять "новые разделы" со старыми и использовать новейшие библиотеки в новых областях.

Ответ 3

Это стоит посмотреть на: https://github.com/jquery/jquery-migrate/#readme

Этот плагин может использоваться для обнаружения и восстановления API или функций, которые устарели в jQuery и удалены с версии 1.9. См. страница предупреждений для получения дополнительной информации о сообщениях плагина генерирует. Для получения дополнительной информации об изменениях, внесенных в jQuery 1.9, см. руководство по обновлению и сообщение в блоге.

Ответ 4

Ребята из Twitter решили эту проблему довольно хорошо.

http://github.com/twitter/bower

Он делает то, что он говорит о жесте - это менеджер пакетов для Интернета (и это включает в себя сохранение JS файлов, таких как JQuery)

Ответ 5

Чтобы быть в курсе развития вашего дерева разработки, я рекомендую использовать src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" (полную версию без ограничений, которая позволяет упростить отладку)

Затем, когда вы переходите к публикации, просто замените его на определенную мини-версию, которая находится в комментарии к заголовку (в настоящее время http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js). имеет бонус, позволяющий лучше кэшировать клиентскую сторону и использовать другую пропускную способность.

Если кеширование вызывает меньшую озабоченность, чем обеспечение того, что оно автоматически получит исправления для этой версии небольшой версии, вы можете использовать только основную и второстепенную версию, например: http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js (Примечание: у google еще нет версии 1.9, однако серия 1.8 до 1,8.3). Поскольку эти обновления периодически обновляются для исправлений ошибок, они не кэшируются, как версии для версии

Ответ 6

В эту эпоху мы не можем быть предсказуемыми относительно стабильности любых версий программного обеспечения. Несколько лет до выпуска версий программного обеспечения и услуг через год или два года. Но в это время версии служб обновляются быстро и часто.

Поэтому, если вы используете какой-либо сервис с вашим сервисом, вам нужно использовать Agile Development. Благодаря этому методу разработки вы можете легко вносить изменения в новые требования и изменять необходимые вам методы.

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

Например: например, у вас есть имя метода update_var();, он вызывает другой метод другой службы, например $a = newlib::check_update();. Затем, создавая библиотеки, вы должны изменить основную библиотеку функции вашей и основной библиотеки задействованного сервиса.