Со временем даже хорошо управляемые веб-приложения могут заметить, что их зависимости отстают. Сообщество JavaScript развивается быстро, и если вы не будете в курсе, вы можете получить package.json из каменного века (два месяца назад). Несколько недель назад моя команда обновила устаревшее приложение Ember 1.13 до Ember 2.10. Вот три совета, которые помогут сделать процесс обновления зависимостей более плавным, чем у нас.
Совет №1: делайте маленькие шаги
Столкнувшись со списком обновлений зависимостей длиной в милю, трудно понять, с чего начать. После обновления всего нашего дерева зависимостей список сломанных функций намного перевешивает список тех, которые все еще работают.
Мы попробовали несколько стратегий, прежде чем нашли ту, которая работала последовательно. Вместо того, чтобы сначала заняться самыми большими неисправными функциями и убрать их с дороги, мы сначала обновили простые части. Наши ранние коммиты были не такими драматичными, как могли бы быть, но их было легко понять. С каждой исправленной функцией мы создавали импульс, благодаря которому ремонт следующей становился немного проще.
В качестве дополнительного бонуса, когда мы, в конце концов, добрались до серьезных нарушений, таких как аутентификация (никогда не отставайте от своей библиотеки аутентификации 😖), стало меньше предупреждений об устаревании, загромождающих консоль.
Совет № 2: полагайтесь на свои тесты
Запуск набора тестов во время нашего обновления был унизительным опытом. Оказывается, радикальное изменение базовых фреймворков и библиотек приводит к серьезным сбоям в тестах. Кто знал? Но этот набор тестов стал нашим лучшим другом.
Поскольку у нас был надежный набор интеграционных тестов, основанный на Капибаре и Полтергейсте, было легко определить области приложения, которые действительно были неисправны, и сосредоточить на них наши усилия, а не гоняться за каждым предупреждением. Это также избавило нас от многочасового ручного тестирования. Ваш тестовый набор будет злиться на вас, когда вы обновите свои зависимости, но в конце концов он вам поможет.
Совет № 3: не бойтесь сломанных коммитов
«Коммитить только после прохождения тестов» — хорошее правило для большинства проектов, но оно плохо работает для больших обновлений зависимостей. При обновлении большого приложения ожидание прохождения всего набора тестов, скорее всего, ограничит вас несколькими гигантскими коммитами. Они никому хорошо не служат.
Они расстраивают вас, потому что трудно придумать достойное сообщение о коммите. Они также довольно ужасны для будущего вас. Копаясь в журнале коммитов, полном «Обновлено все!» сообщения, ищущие что-то конкретное, - это грубый способ провести день.
Вместо того, чтобы ждать, пока все будет в отличной форме, прежде чем совершать коммит, мы изменили тактику. Наше новое правило во время обновления заключалось в том, чтобы фиксировать каждый раз, когда мы были уверены в одном улучшении. Это могут быть небольшие вещи, такие как обновление контроллеров с синтаксиса foo: function() {…}.property('…') на синтаксис foo: Ember.computed('…', function () {…}), или более крупные изменения, такие как прохождение неудачного теста. Вместо того, чтобы ждать, пока все будет идеально, мы фиксировали, когда что-то становилось лучше. В результате журнал коммитов стало легче читать и легче копаться в нем при необходимости.
Дополнительный совет: обновляйте свои зависимости
Лучший способ справиться с серьезным обновлением зависимостей в вашем веб-приложении — это вообще избегать его. Гораздо проще тратить пару часов каждые несколько недель на исправление мелких проблем, возникающих при обновлении одной или двух зависимостей, чем ждать шесть месяцев и обнаруживать, что у вас полностью сломанное приложение.
Всегда есть причины избегать обновления. Ни один из них не является достаточно хорошим. Избавьте себя от неприятностей и оставайтесь на вершине этих обновлений!
Немного изменив способ нашей работы, мы смогли справиться с серьезным изменением зависимостей, не нарушая (большого) пота. Как вы поддерживаете свои приложения в отличной форме?
Первоначально опубликовано на spin.atomicobject.com 3 февраля 2017 г.
