Ворклог по задаче "Инвентаризация текущего Ruby-сайта"

Первичная техническая инвентаризация 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-системы.