Первичная техническая инвентаризация legacy-сайта

Получена первичная документация по текущей реализации bizneshelper.ru.

Подтверждённый стек

• Ruby on Rails 3.2.21 — legacy-версия фреймворка.
• Ruby явно не зафиксирован; для проекта предполагается совместимый диапазон старых версий Ruby, ориентировочно 1.9.3–2.2.x. Для локального воспроизведения разумной стартовой точкой выглядит Ruby 2.2.10, но совместимость нужно подтвердить фактическим запуском.
• MySQL через mysql2 ~> 0.3.11.
• Bundler 1.15.4.
• Отдельный Solr-контур используется для полнотекстового поиска через sunspot_rails / sunspot_solr.

Существенные зависимости

• devise — аутентификация, включая административный доступ.
• ckeditor — редактирование контента.
• paperclip ~> 3.0 — работа с загружаемыми файлами и изображениями.
• friendly_id ~> 4.0.9 — человекочитаемые URL; критично для анализа текущих маршрутов и сохранения URL при миграции.
• sunspot_rails, sunspot_solr — поиск; для полного воспроизведения legacy-поведения потребуется Solr.
• omniauth и провайдеры социальных сетей — исторические OAuth-сценарии, актуальность каждого провайдера нужно проверять отдельно.
• will_paginate, simple_form — пагинация и формы.

Структура данных и файлов

• db/ содержит 77 миграций, schema.rb и seeds.rb; это важный источник для восстановления фактической модели данных и истории её развития.
• files/ содержит около 1320 элементов; этот каталог нужно отдельно сопоставить с Paperclip-моделями и публичными URL медиа.
• public_html/ содержит статические ресурсы, которые необходимо отличить от генерируемых Rails-страниц при подготовке карты миграции.
• solr/ содержит конфигурацию поиска и должен быть учтён при инвентаризации поисковой функциональности.

Публичные особенности

• Административный интерфейс доступен по /admin и использует Devise.
• Локаль по умолчанию — русская (config.i18n.default_locale = :ru).

Основные технические риски

1. Стек существенно устарел, поэтому локальный запуск на современной системе может потребовать отдельного legacy-окружения или контейнеризации.
2. therubyracer / libv8 потенциально проблемны при сборке на современных ОС.
3. mysql2 ~> 0.3.11 может быть несовместим с актуальными клиентскими библиотеками MySQL без дополнительных мер.
4. Полноценное воспроизведение поиска потребует Solr; без него сайт может запускаться, но один из пользовательских сценариев будет неполным.
5. friendly_id необходимо исследовать до проектирования маршрутов haih-cms, так как текущие slug-и и правила URL могут быть частью накопленного SEO-актива.
6. Paperclip и каталог files/ требуют отдельной сверки: нужно понять схему путей, привязки к моделям и долю реально используемых файлов.
7. OAuth-провайдеры относятся к legacy-интеграциям; часть из них может быть неработоспособна или не нужна в новой версии, поэтому их нельзя автоматически переносить как обязательную функциональность.

Что проверить следующим шагом

• Фактическую версию Ruby по lock/config/deploy-файлам или успешному локальному запуску.
• Gemfile.lock и точные версии всех гемов.
• schema.rb и модели Rails: состав сущностей, связей и attachment-полей Paperclip.
• routes.rb: реальные публичные маршруты, /admin, friendly_id и legacy-редиректы.
• Контроллеры и views: фактические типы публичных страниц.
• Связь файлов из files/ с записями БД.
• Использование Solr в пользовательских сценариях.
• Реальную актуальность OAuth и иных внешних интеграций.

Вывод

Проект представляет собой классический Rails 3.2 legacy-монолит с отдельными подсистемами хранения файлов и Solr-поиска. Для миграции на haih-cms критично сначала воспроизвести текущую модель данных, маршруты и media-связи, а затем переносить контент и функциональность. Попытка трактовать сайт только как набор HTML-страниц приведёт к потере существенной части логики legacy-системы.

Уточнение по результатам локального запуска

Локальное развёртывание legacy-сайта завершено успешно, что позволило подтвердить часть ранее предположительных данных.

Подтверждено

• Исходная серверная среда использовала Ruby 2.2.5 через Passenger.
• Rails 3.2.21 совместим с запуском в контейнере на Ruby 2.2.10.
• Legacy-приложение использует MySQL по сетевому подключению при явном указании host.
• Более новая ветка ckeditor несовместима с Rails 3.2; рабочий вариант требует фиксации совместимой версии 4.0.x.
• В проекте присутствуют каталоги и файлы, характерные для Rails 5 (app/channels, app/jobs), хотя основное приложение остаётся Rails 3.2. Это важно учитывать при анализе структуры исходников: не все файлы в дереве проекта являются частью реально работающего legacy-runtime.

Вывод для инвентаризации

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

Следующий приоритет — пройти по публичным маршрутам, проверить media-связи, поиск, формы и административную часть, сопоставляя наблюдаемое поведение с routes.rb, моделями и схемой БД.

Корректировка границ инвентаризации

Полный reverse engineering Ruby-приложения больше не является целью. Инвентаризация должна отвечать на практический вопрос: какие сущности, поля, медиа, URL и пользовательские сценарии действительно нужны для нового сайта и миграции данных.

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

Вывод по внутреннему качеству legacy-сайта

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

Характерный пример: основной контент обычной страницы хранится в поле description, тогда как контент главной страницы находится уже в системных настройках сайта. Такая структура неочевидна без изучения исходников и фактического поведения приложения.

Почему это важно

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

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

Вывод для новой реализации

Удобная и предсказуемая механика управления контентом — не декоративное улучшение CMS, а обязательная часть жизнеспособности сайта. Новая реализация должна снижать стоимость повседневных изменений и делать структуру данных понятной без необходимости каждый раз исследовать внутренности системы.

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