Устаревшее |
|---|
Режим dev-test-prod (разработка-тестирование-эксплуатация) предполагает, что разработка и тестирование новых процессов ведутся не в рабочем приложении (где работают обычные бизнес-пользователи), а в отдельных приложениях. В рабочее приложение переносятся только проверенные, протестированные процессы. Режим dev-test-prod увеличивает стабильность системы и удобство разработки.
Если разработка небольшая, ее можно вести в одном dev-приложении. В этом случае тестовое приложение разворачивается не всегда, и разработка ведется в режиме dev-prod.
Если разработка ведется несколькими независимыми командами, для каждой команды может быть развернут отдельное dev-приложение.
Способы организации разработки.
Во всех этих случаях (dev-test-prod и dev-prod) нужно настроить миграционные ключи.
Миграционный ключ
При создании новой категории, ДП или других сущностей им присваивается уникальный идентификатор. В общем случае это следующий порядковый номер (например, если у существующих категорий максимальный ID 100, следующая новая категория получит ID 101). Но когда разработка ведется в нескольких dev-приложениях, в каждом из них создаются свои категории и ДП, и единый "сквозной" порядок нумерации не соблюдается. При объединении этих изменений в общем test-приложении скорее всего возникнут ошибки и накладки. Чтобы избежать этого, настраиваются миграционные ключи. С их помощью обеспечивается уникальность идентификаторов создаваемых конфигурационных объектов.
Значение миграционного ключа прописывается в Общих настройках приложения. Ключ может принимать значения от 0 до 9 (что означает, что всего можно использовать не более 10 dev- и test-экземпляров системы). При создании нового конфигурационного объекта (см. список ниже) его ID формируется таким образом, что остаток деления значения ID на 10 равняется значению миграционного ключа. Таким образом, на сервере с ключом равным 1 идентификаторы формируются в последовательности 41, 51, 61 и т.д., а на сервере с ключом 2 — 42, 52, 62. При переносе с dev- на test- и prod-приложения в режиме сохранения ключа объекты сохраняют свои ID вместе с миграционным ключом.
Конфигурационные объекты, получающие ID с учетом миграционного ключа
•ДП (таблица ExtParams)
•Разделы (таблица Categories)
•Категории (таблица Subcategories)
•Колонки ДП "Таблица" (таблица ExtParamTableSettings)
•Статусы (таблица States)
•Подписи (таблица Signatures)
•Переходы (таблица StatesRoutesInSubcat)
•Группы (таблица Groups)
•Шаблоны дизайна категорий (таблица SubcategoryTemplates)
•Контейнеры и шаблоны мобильного приложения (таблицы APIContainer, APITemplate)
•Шаблоны задач (таблица TaskUniversalTemplates)
•Источники данных задач (таблица TaskDataSource)
•Смарт-выражения (таблица SmartExpressions)
•Отчеты (таблица Reports)
•Фильтры (таблица Filters — на неё есть ключи в таблицах PortalGridBlocksFilters — виджеты, ReportFilterLinks — отчеты и FilterParams — параметры фильтра)
Организация работ и настроек экземпляров системы
Требования при работе по схеме dev-prod
•Запрещено вносить изменения в prod-приложении, кроме заведения пользователей, групп и элементов орг.структуры.
•Необходимо активировать миграционный ключ в приложениях dev и prod.
•Импорт с dev- на prod-приложение должен осуществляться в режиме сохранения Id.
Требования при работе по схеме dev-test-prod
•Запрещено вносить изменения в приложениях test и prod, кроме заведения пользователей, групп и элементов орг.структуры.
•Необходимо активировать миграционный ключ во всех dev-, test- и prod-приложениях.
•Импорт с dev- на test-приложение и с test- на prod-приложение должен осуществляться в режиме сохранения Id.
