Уроки, извлеченные из масштабной миграции программного обеспечения и сокращения технического долга

Уроки, извлеченные из масштабной миграции программного обеспечения и сокращения технического долга

Как мы успешно перенесли наше приложение, ничего не сломав

Крупные миграции в области разработки программного обеспечения могут быть непростыми. Я участвовал в миграции приложения Angular 4, которому более двух лет, и которое ежедневно используется многими крупными компаниями, на последнюю версию Angular 7. Во-первых, я расскажу о довольно общих шагах, которые вы должны предпринять, которые не относятся только к проектам миграции Angular. Затем я более подробно расскажу, как мы выполняли эти шаги.

Но каковы причины этих миграций. А как насчет «Никогда не менять работающую систему»? Хотя это не соответствует действительности, я считаю, что работающей системы может быть недостаточно. Приложение может по-прежнему работать, и существующие пользователи продолжают за него платить. С другой стороны, есть несколько причин не стоять на месте:

• Ваши конкуренты не спят: они станут лучше, а потенциальные клиенты, скорее всего, предпочтут продукт, который все еще развивается.
• Наем новых талантов необходим для любой амбициозной компании. Устаревший стек технологий может оттолкнуть кандидатов.
• ИТ-безопасность - популярная тема. Многие инциденты безопасности происходят из-за известных уязвимостей в сторонних библиотеках. Благодаря сообществу разработчиков ПО с открытым исходным кодом известные уязвимости системы безопасности часто устраняются за считанные дни.
• Может стать сложнее двигаться быстро и ломать вещи. Хотя вы не должны что-то ломать, идея состоит в том, что если ваш стек технологий не работает, это может замедлить вашу работу. Например, устаревший технический стек может помешать вам двигаться так же быстро, как ваши конкуренты.
• Устаревший стек технологий усложняет жизнь разработчикам. Для популярных сторонних библиотек или важных исправлений ошибок могут потребоваться современные фреймворки. Кроме того, если ваша версия фреймворка сильно устарела, разработчикам станет лень пробовать новые вещи: «Эй, Angular Universal может значительно улучшить нашу производительность! Что ж, очень плохо, мы все еще используем AngularJS и не можем его использовать ».

Вы можете спросить себя: «Ну, а насколько сложным может быть обновление? Просто запустите npm update или что-то в этом роде, и все будет хорошо, не так ли? ». Реальность такова, что многие технологические миграции (не ограничиваясь технологией) терпят неудачу или занимают гораздо больше времени, чем ожидалось. Некоторые возможные причины, по которым миграция может быть сложной:

• Технология радикально изменилась, и вам нужно изменить множество вещей, таких как тесты, зависимости и т. Д.
• Отсутствие руководств по миграции или недостаточное количество журналов изменений затрудняют понимание того, что было изменено и какие действия необходимо предпринять для обновления.
• Цель не ясна. Если вы создаете новые строительные площадки во время миграции, этот процесс займет больше времени и станет более сложным в управлении.
• Отсутствие информации об используемом техническом стеке усложняет обновление.

Каковы общие шаги по миграции?

• Для фреймворков часто есть руководства по обновлению, если выпуск содержит критические изменения.
• Инструменты сборки, такие как Gradle для проектов Java или менеджеры пакетов, такие как NPM для проектов JavaScript, упрощают разработчикам управление зависимостями. Запустите npm outdated, чтобы узнать, какие зависимости можно обновить. В частности, сторонние библиотеки могли быть обновлены для поддержки последней версии фреймворка. Перед обновлением я рекомендую проверить ваши сторонние библиотеки, чтобы узнать, действительно ли они поддерживают версию, до которой вы хотите выполнить обновление.
• Проверьте журнал изменений на предмет критических изменений. Критические изменения обычно выделяются автором библиотеки, чтобы пользователям библиотеки было легче их обнаружить.
• Автоматическое тестирование и непрерывная интеграция может помочь вам выявить проблемы перед выпуском. Это включает в себя выполнение полной сборки AOT, готовой к производству, а также выполнение как модульных, так и сквозных тестов. Это снижает потребность в ручном тестировании и позволяет с большей уверенностью отправлять код.
• Ручное тестирование по-прежнему необходимо проводить, хотя автоматическое тестирование должно снизить потребность в нем. Некоторые изменения, такие как непроверенная функциональность или различия в стилях, могут не быть обнаружены путем сборки или автоматического тестирования. Ручное тестирование должно выполняться не только разработчиками, но и сторонними людьми (например, людьми из QA), потому что они могут выявлять проблемы, которые разработчики могут пропустить. Ручное тестирование следует проводить только после прохождения автоматического тестирования.
• Сравнение приложения до обновления и приложения после обновления позволяет определить поведение, которое изменяется в процессе обновления.
• Улучшенные инструменты и более развитая экосистема упрощают обновление. Мощные интерфейсы командной строки, официальная документация, обучающие материалы и активная база пользователей улучшают процесс адаптации разработчиков и удобство работы.
• Крупные обновления могут быть проблематичными. Вместо этого вы можете сделать всплеск: потратьте один-два дня на работу, чтобы оценить, сколько усилий потребуется.
• Не позволяйте ветви миграции лежать слишком долго. Поскольку другие люди, вероятно, также изменят код, тем труднее будет разрешать конфликты слияния, чем дольше длится миграция.
• Не смешивайте другие задачи с задачей переноса. Сосредоточьтесь на завершении миграции, прежде чем выполнять другие несвязанные задачи.
• Обзор возможностей вашего приложения упрощает тестирование. Вам не нужно создавать большой документ: хорошее тестовое покрытие очень помогает выявить особенности вашего приложения.

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

Как мы выполнили эти шаги для перехода?

• Руководство по обновлению Angular действительно очень помогает. Он показывает вам общие шаги, которые необходимо выполнить, чтобы обновить Angular. Мы следовали инструкциям в руководстве по обновлению Angular, которое включает в себя основные шаги, а также упоминает критические изменения.
• Мы создали диаграмму, на которой более подробно показан путь обновления. Вместо масштабного обновления мы попытались выполнить постепенное обновление.
• Просматривая журналы изменений наших сторонних библиотек, мы заранее выявили некоторые критические изменения, которые потребовали от нас адаптации нашего кода. Примером может служить Rx JS, в котором в версии 6 были внесены критические изменения API.
• Просмотр того, какие зависимости устарели или вообще не нужны (больше), позволило нам увидеть, что нет зависимостей, которые не работали бы в Angular 7. В частности, сторонние библиотеки Angular (например, ngx-bootstrap) могли быть обновлены для поддержки более поздних версий Angular. К счастью, не было зависимостей, которые не работали бы в будущих версиях Angular. Необходимо обновить некоторые сторонние библиотеки. Это также была возможность удалить сторонние библиотеки, которые вообще не использовались, или заменить их более современными библиотеками.
• У нас есть хорошее покрытие модульным тестированием и сквозным тестированием, которое очень помогло нам гарантировать, что мы не нарушим функциональность. .
• Что касается ручного тестирования, мы попросили других разработчиков, а также сотрудников службы поддержки принять участие в нашем «Дне контроля качества». В течение нескольких часов мы просили участников просмотреть имеющиеся у нас функции и найти проблемы. Таким образом, мы выявили несколько мелких ошибок, которые быстро исправили.
• После некоторых серьезных изменений мы сравнили нашу текущую версию со старой версией, чтобы убедиться, что поведение не изменилось. Кроме того, сравнение старого и нового выявило более мелкие проблемы стиля, которые было легко разрешить.
• С новейшим интерфейсом командной строки Angular процесс обновления стал проще за счет использования ng update. Начиная с Angular CLI v6, существует довольно удобная команда CLI под названием ng update, которую можно использовать для обновления вашего приложения и его зависимостей. Переход с Angular 6 на Angular 7 был сделан за несколько минут. по сравнению с переходом с Angular 5 на Angular 6. Кроме того, Angular теперь поддерживает пользовательские конфигурации webpack, так что мы можем избавиться от обходных путей.
• Во время обновления Angular мы заметили некоторые улучшения, которые были полезны, но не обязательны. Вместо того, чтобы создавать еще больше строительных площадок, мы собрали их и сосредоточились на аккуратном завершении миграции. После обновления мы могли без проблем заняться этими улучшениями, поскольку основная задача была уже решена, и эти улучшения были больше похожи на лед на торте.
• Проще проверить, если вы знаете, что именно тестировать. Благодаря хорошему покрытию тестами, матрице характеристик продукта и глубокому знанию продукта всеми участниками процесса тестирования, мы были уверены, что не пропустили ни одной функции нашего приложения.

Вывод

Спасибо, что прочитали эту статью. Крупные миграции в разработке программного обеспечения могут быть сложными, особенно в зрелых проектах программного обеспечения. Однако бояться таких изменений не стоит. Проведение некоторых исследований и планирования перед началом миграции во многом помогает снизить риск сбоя. Расскажите в комментариях о своем опыте.