Описание архитектуры
Фактические зависимости, хранилища, сущности и используемые сценарии.
Перенос с самописного сайта на Ruby на 1С-Битрикс
Разберём архитектуру Ruby-приложения, перенесём нужные данные и проверим пользовательские действия в новой системе.
Расскажите о проекте и доступных исходниках. Уточним систему хранения, нужные функции и роль новой CMS.
Узнаёте свою ситуацию?
- Сайт написан на Ruby без типовой CMS и его устройство известно только прежнему разработчику.
- Нужно передать контент редакторам, сохранив отдельные полезные функции приложения.
- В проекте есть собственные структуры данных и требуется оценить безопасный способ извлечения.
Как поможем
Перенос самописного сайта на Ruby на 1С-Битрикс — исследование индивидуального приложения и перевод согласованных сущностей и сценариев в новую систему. Ruby — язык, а не единая структура базы и панели управления. Проект может использовать разные библиотеки, маршрутизацию и способы хранения, поэтому типовой импорт без обследования не описывает реальную работу.
Что входит в работу
Выясняем, как приложение хранит и меняет сведения
Собираем зависимости, точки входа, конфигурацию хранения и доступную документацию. Разбираем сущности по назначению: материалы, записи клиентов, файлы, справочники и состояния процессов. Проверяем, что формируется из базы, а что собирается в коде или приходит извне. Наличие знакомой библиотеки не позволяет автоматически применить к проекту правила другого Ruby-фреймворка.
Если фактически используется Rails, границы уточняются по отдельному сценарию Rails. Для собственных бинарных объектов учитываем ограничения Marshal и происхождение данных. При преобразовании предпочтительны явные значения и связи, которые можно проверить независимо от загрузки старых классов. Контрольная выборка включает нестандартные поля и вложенные структуры.
Выбираем, что реализовать в CMS, а что оставить сервисом
Для каждой функции описываем вход, результат, права и побочные действия. Контент и редакторские операции переводим в модель Битрикс, а самостоятельную полезную логику можно сохранить за интерфейсом API. Такое разделение требует определённого владельца сервиса и поведения при недоступности; оно не означает, что старая система больше не нуждается в сопровождении.
Проверяем маршруты, пользовательские состояния и операции, которые могут продолжиться после переключения. Подготавливаем карту адресов и приёмку реальных действий, включая ошибки и повтор. Стоимость зависит от архитектуры, документации, объёма собственной логики и истории. Лицензии, новый дизайн и переработку остающегося сервиса оцениваем отдельно. Согласуем способ входа пользователей после проверки авторизации, а для публичных маршрутов задаём контроль индексации после запуска.
Разберём архитектуру вашего Ruby-сайта
Расскажите о проекте и доступных исходниках. Уточним систему хранения, нужные функции и роль новой CMS.
Что вы получите
Правила преобразования
Сопоставление данных с целевой моделью и проверяемая выборка.
Карта функций
Новая реализация, остающиеся сервисы и явные исключения перехода.
Как проходит работа
-
Определить устройство
Проверяем, как построен Ruby-проект и где находятся важные данные.
-
Согласовать границы
Разделяем перенос в CMS, интеграцию и ненужные функции.
-
Проверить переход
Сверяем преобразованные сведения и пользовательские сценарии на новой системе.
Как проверить результат
Верная классификация
План основан на фактическом приложении, а не предположении о Rails.
Проверяемые данные
Значения и связи можно сопоставить с исходными записями.
Поддерживаемый контур
Для оставленного сервиса определены интерфейс, ответственный и реакция на отказ.
Связанные услуги
Вопросы об услуге
Чем эта услуга отличается от переноса с Rails?
Здесь нельзя заранее рассчитывать на структуру и соглашения Rails. Сначала определяем реальные библиотеки, модель данных и обработку запросов. Если обследование подтверждает Rails, используем соответствующие проверки. Само расширение файлов Ruby не доказывает наличие Active Record, стандартных связей или готовой административной панели.
Можно перенести сохранённые Ruby-объекты без изменения?
Сохранённые Ruby-объекты могут зависеть от классов и версии приложения, а обработка неизвестного Marshal небезопасна. Сначала исследуем происхождение и структуру, затем извлекаем согласованные значения в проверяемом формате; автоматическое исполнение старых объектов не является этапом импорта.
Останется ли необходимость в Ruby-разработчике?
Если часть приложения сохраняется как отдельный сервис, ей нужно сопровождение соответствующей компетенции. Это должно быть видно в архитектуре и оценке владения. Если цель — полностью отказаться от Ruby-контура, стоимость и риски пересборки всех нужных функций оцениваются отдельно, а не скрываются в переносе контента.
Обсудим задачу вашего проекта
Расскажите о сайте и о том, что хотите изменить. Уточним объём работ, обсудим сроки и подготовим предложение.
- Пришлите ссылку на сайт и опишите задачу
- На обсуждении уточним цели и ограничения
- После — предложение с составом работ и условиями
С чего начнём?
Опишите вашу ситуацию. Если сайт или CRM уже есть — добавьте ссылку и то, что хотите изменить.
На следующем шаге нужен только телефон. Остальное — по желанию.
Или напишите: info@iskariot.ru