Перейти к содержанию

Модули и версионирование

Модули

Модуль — это логическое объединение сущностей администрирования для удобного переноса и версионирования конфигурации.

Типовые объекты модуля:

  • разделы и категории;
  • дополнительные параметры;
  • статусы и подписи;
  • отчеты, порталы, виджеты;
  • автоматизации (смарт-пакеты, смарт-выражения, смарт-расписания).

Базовые операции

Создание модуля:

  1. Нажмите «Создать».
  2. Укажите название.
  3. Сохраните.

Редактирование:

  • выберите модуль в списке и измените данные.

Удаление:

  • удаление возможно только если в модуле нет связанных сущностей.

Назначение сущностей модулю:

  • в формах администрирования выбирается значение «Модуль»;
  • если модуль не выбран, объект относится к общему (глобальному) модулю.

Пример выбора модуля для категории:

Важно:

  • при создании ДП и смартов внутри категории обычно наследуется модуль категории;
  • система ограничивает смешивание сущностей разных модулей в ряде сценариев конфигурирования.

Что хранится в БД

  • Modules — карточка модуля (Id, Name, VersionConfigId).
  • VersionConfigs — версии конфигурации модуля (ConfigVersion, ConfigDate, Link, ModuleId).
  • RepoSettings — настройки активного репозитория (тип, источник, ключи доступа, локальный путь).

Версионирование модулей (RevisionRepository)

Версионирование работает через API, а не через отдельную UI-форму мастера:

  • POST /api/admin/revisionrepository/versionconfig — создать версию;
  • POST /api/admin/revisionrepository/versionconfig/changeversion — переключить модуль на существующую версию;
  • DELETE /api/admin/revisionrepository/versionconfig/{id} — удалить версию;
  • POST /api/admin/revisionrepository/reposettings/preparerepository — подготовить активный репозиторий.

Настройка репозитория

Перед созданием/переключением версий должен быть настроен активный RepoSettings:

  • POST /api/admin/revisionrepository/reposettings
  • GET /api/admin/revisionrepository/reposettings
  • POST /api/admin/revisionrepository/reposettings/{id}
  • DELETE /api/admin/revisionrepository/reposettings/{id}

Поддерживаются провайдеры:

  • FileSystem;
  • Git.

Поток «Создать версию»

  1. CreateConfigVersion(moduleId, version):
  2. нормализует имя версии;
  3. создает запись в VersionConfigs;

  4. обновляет Modules.VersionConfigId.

  5. BuildCurrentConfiguration(moduleId):

  6. собирает конфигурацию модуля через экспортный механизм переноса;

  7. формирует VersonConfigDto с тремя JSON-блоками.

  8. RevisionRepositoryService.Push(...):

  9. провайдер (FileSystem/Git) записывает файлы версии в хранилище.

Поток «Сменить версию»

  1. ChangeConfigVersion(moduleId, versionId):

  2. валидирует, что версия принадлежит модулю.

  3. RevisionRepositoryService.Pull(link):

  4. читает файлы версии из репозитория.

  5. SetVersionConfiguration(...):

  6. десериализует конфигурацию;

  7. вызывает импорт через MigrationImportService.Import(...).

  8. Импортный post-step:

  9. обновляет кеши;

  10. запускает денормализацию импортированных категорий/сводных.

  11. Если импорт завершился ошибкой:

  12. выполняется rollback привязки модуля на предыдущую версию.

Формат версии (текущее состояние)

В каталоге версии хранятся три файла:

  • data.json
  • additionalData.json
  • config.json

Link версии обычно имеет вид:

  • module{moduleId}/{version}.

Активная доработка: мультифайловый формат

В активном проекте утилиты переноса прорабатывается переход от единого data.json к раскладке на набор файлов по областям конфигурации (категории/глобальные сущности).

Цели:

  • уменьшить размер и конфликтность git-diff;
  • упростить частичную навигацию по конфигурации;
  • сохранить обратную совместимость со старым форматом.

Подробности: docs/projects/oac/multifile-export.md.

Диагностика проблем по версиям

Проверяйте по порядку:

  1. Активен ли нужный RepoSettings.
  2. Корректен ли Link и доступны ли файлы версии.
  3. Есть ли запись версии в VersionConfigs и привязка в Modules.VersionConfigId.
  4. Нет ли ошибок импорта/денормализации в логах migration-контуров.
  5. После changeversion — применились ли целевые сущности и кеши.

Связанные материалы