Строительный гипермаркет «ДЕКОРАДО»

Обновить нельзя переделать

Изначально владелец продукта запросил создание нового сайта на базе Битрикс с оглядкой на текущий сайт, сделанный на Symfony + Next.js. Мы уточнили мотивацию и узнали, что дело не в том, что Битрикс решит какие-то функциональные задачи. Дело оказалось в том, что текущий проект стало невозможно развивать в адекватном темпе из-за накопившегося технического долга. Мы предложили два варианта: разработать сайт на Битрикс с нуля или же реанимировать текущий проект, обновив ему стек и снабдив всем нужным инструментарием для минимизации появления технического долга в будущем.

Оценка обстановки

Чтобы понять, какие усилия потребуются для обновления стека проекта, нам пришлось изучить всю кодовую базу и составить подробный план обновления. Здесь нас ждал первый сюрприз: оказалось, что стек проекта устарел ещё до начала разработки! Спросить у предыдущего подрядчика «как так вышло?» мы не могли, но вероятный ответ в том, что разработчики, начиная новый проект, просто скопировали ранее разработанный кем-то шаблон. Шаблоны — это хорошо, но плохо, когда их не обновляют перед тем, как приступить к реализации нового проекта на их основе.

Изначально нам казалось, что реанимировать проект будет существенно дешевле, чем делать его с нуля. Но, учитывая вводные, разница оказалась не так велика. Тем не менее заказчик принял решение в пользу нормализации текущего решения.

Что было сделано?

Обновлён инфраструктурный слой проекта (Docker) и добавлена поддержка запуска локальных окружений для нужд разработки

Первое, что нам предстояло сделать, — подготовить удобный плацдарм для ведения всех работ над проектом в локальных окружениях разработчиков. Он уже использовал Docker, но только в продуктиве. Мы обновили стек, связанный с инфраструктурой, и сделали так, чтобы он позволял разворачивать сайт не только на продуктиве, но и на машине разработчика. Окружения разворачиваются буквально в несколько тривиальных действий, что позволяет экономить время в каждом случае, когда на проект подключается новый разработчик. И что ещё более важно — теперь, если инфраструктура меняется, эти изменения легко распространять между разработчиками. А это периодически случается и без подобной подготовки доставляет массу неудобств и добавляет существенные трудозатраты.

Проверен существующий набор автоматических тестов

Не следующим, а параллельным шагом была проверка существующего набора автоматических тестов. Да, к чести предыдущего подрядчика, на проекте уже был скромный набор тестов. Здесь нас ждал первый приятный сюрприз: в изначальном прогнозе мы закладывались на то, что тесты могут оказаться в плохом состоянии и нужно будет приводить их в чувство. К счастью, обошлось косметическими правками, и тесты вскоре «завелись».

Настроен статический анализ

Основная причина, по которой многие проекты тонут в багах, — отсутствие статического анализа, который находит проблемы в коде ещё до того, как этот код запускают. Это очень выгодно, потому что обратная связь быстрая и автоматическая. Перед тем, как приступить к обновлению проекта, мы настроили инструментарий, который выявил множество существующих на проекте проблем. Часть из них мы сразу исправили, часть оставили на потом (явным образом отметив такие места через TODO), т. к. была вероятность, что они станут неактуальными после обновления стека. Это стало важным предусловием обновления, потому что оно затрагивает почти все файлы проекта и нам было важно оперативно видеть те ошибки, которые может отловить автоматика. Только так процесс обновления можно было сделать эффективным, ведь иначе нужно делать ручные проверки, а это всегда существенно дольше. Ручные проверки, конечно же, не отменяются, просто они делаются гораздо реже.

Хочется отметить один курьёзный случай, который выявил статический анализ: оказалось, что на проекте выполнялась задача, затронувшая способ вывода заголовков, но из-за недосмотра один из заголовков продолжил выводиться по-старому, хотя такой вариант использования вообще не предполагался. Автоматика выявила бы это моментально, если бы она на проекте была. Результат: около четырёх лет на каждой странице товара выводился пустой тег <h1>. Надеемся, что статью не читают SEO-шники, потому что их здесь, наверное, хватил бы удар.

Библиотеки обновлены до актуальных версий

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

Как мы выяснили ещё на стадии оценки работ, фундамент проекта устарел ещё до начала работ, но мы были к этому готовы. Планомерно обновляли версию за версией, благо наиболее крупные вендоры библиотек, использованных в фундаменте, имели довольно чёткие инструкции по обновлению. Без подводных камней не обошлось: некоторые более мелкие библиотеки не имели свежих версий, и пришлось искать им замену.

Налажен системный подход к сбору логов

Логи — это чёрный ящик системы. В проекте довольно редко фиксировались происходящие события, что существенно повышало риски: случись что на продуктиве — мы не смогли бы понять, что привело к проблеме. Мы не только добавили логи во все критичные места, но и настроили их централизованный сбор (Loki) и удобный доступ к ним (Grafana).

Сформулирован основной набор E2E-тест-кейсов и проведено тщательное тестирование

Маловероятно, что, свободно бродя по сайту, удастся найти все возможные ошибки. Для регулярной работы нужна система, и такой системой для нас служит набор тест-кейсов — конкретных сценариев проверки. Даже банальная регистрация может потребовать проработки десятков сценариев. На подобную детализацию у нас времени не было, но мы составили достаточный минимум тест-кейсов (~150 шт.) и делали предрелизные проверки по ним.

Автоматические E2E-тесты

Любому, кто составляет подробный набор тест-кейсов, быстро становится очевидно, что проверка всех сценариев — довольно затратное по времени занятие. В долгосрочной перспективе тест-кейсы надо автоматизировать, что мы и сделали (~50 шт.).

Что пошло не так?

Переработка архитектуры продуктивной инфраструктуры

Изначально мы ожидали, что лишь обновим стек по части инфраструктуры и адаптируем его для запуска в локальном окружении для нужд разработки. На практике потребовалось полностью переработать архитектуру, т. к. иначе пришлось бы поддерживать две разные копии конфигураций. Мы реализовали модульную архитектуру сборки compose.yaml-файлов, и всё собирается «по частям». Для каждого окружения есть свои предустановки, а с помощью override-файла можно добавить в конкретное окружение дополнительные части.

Административная часть

Она собиралась на react-admin, и казалось бы — нужно просто обновиться. Но изменения в новых версиях были очень существенные, а архитектура react-admin такова, что статический анализ далеко не всегда помогает. Работы по административной части заняли существенно больше времени, чем мы ожидали.
 

Результат

Стек проекта обновлён со всех сторон — и со стороны приложения и со стороны инфраструктуры. Настроен современный инструментарий, который позволяет в автоматическом режиме находить многие из проблем. Проект готов к новым внедрениям.