...

Правильная организация цикла разработки

Тема в разделе "Вопросы по платформе", создана пользователем sergey.a, 23 окт 2025.

  1. sergey.a

    sergey.a Новичок

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

    Исходно:
    Пустая, как барабан ELMA 365 on-premises Enterprise
    Единственное активированное системное решение ELMA365 ECM
    Как рекомендовано, развёрнуто три контура (Dev, Test и Prod).
    Начинаем цикл разработки. Допустим нам необходимы следующие разделы:
    Системные справочники. В нём приложения:
    - Сотрудники
    - Мои Юрлица
    CRM. В нем приложения:
    - Контрагенты
    - Сделки
    Корреспонденция
    - Письма входящие
    - Письма исходящие
    Товары и услуги
    - Товары (иерархический справочник)
    - Номенклатура
    - Характеристики номенклатуры
    Договоры
    - Договоры входящие
    - Договоры исходящие
    - Приложение к договору
    - Акт
    - Дополнительное соглашение
    Между разделами существуют связи:
    В сделке - сотрудники и мои юрлица (из Системных справочников, Договоры, Товары и услуги, Письма).
    В контрагенте (сотрудники, договоры, письма)
    И т. д.
    Разработка ведётся несколькими специалистами одновременно.
    Каким образом правильно обеспечить разработку на Dev и дальнейший перенос на следующие стадии, с учётом того что разработка будет вестись непрерывно.
    Пока я вижу только вариант с оформлением каждого раздела в отдельное решение и обмен на уровне решений.
    Второй вопрос: получается что любое, самое минимальное изменение (например коррекция формы просмотра приложения) в таком даже в таком варианте ведет к необходимости экспорта/импорта всего Решения. Т.е. необходимо накапливать какое-то количество доработок и только после этого переносить их в тестовую среду (с переносом в прод это приемлемо). "Квант времени" доработки при этом существенно увеличивается (по сравнению с монолитом)/
    Заранее благодарю за помощь.
  2. sergey.a

    sergey.a Новичок

    Как мне ответили старшие товарищи, если кратко
    1. Да, один раздел, одно решение
    2. Решения формируют древовидную структуру от одного (нескольких) корневых разделов, не содержащих внешних зависимостей
    3. Никаких перекрёстных и обратных зависимостей
    4. Ci/Cd - не применяем
    5. Обновляем решения файлами
    6. С версионностью и регламентом обновления решений - разбираемся сами по мере сил и фантазии
  3. semenova

    semenova Техническая поддержка

    Добрый день!
    1. Как правильно организовать разработку и перенос изменений между контурами (Dev → Test → Prod) при командной работе и наличии связанных разделов?
    Для удобства разработки и управления изменениями рекомендуется оформлять каждый логически самостоятельный раздел (например, "Системные справочники", "CRM", "Договоры" и т.д.) в отдельное решение. Это облегчает перенос, версионирование и тестирование, а также снижает риск конфликтов между командами.
    Если между приложениями разных решений есть связи, их нужно проектировать заранее. При экспорте/импорте решения ELMA365 учитывает внешние связи, но если связанное решение ещё не установлено в целевом контуре, могут возникнуть ошибки. Поэтому переносить решения лучше в определённой последовательности (например, сначала "Системные справочники", затем "CRM" и т.д.).
    Для командной работы и непрерывной разработки рекомендуется использовать отдельные Dev-окружения для каждой команды или даже для каждого разработчика. После завершения доработок изменения сливаются в общую Dev-ветку, затем переносятся на Test, а после тестирования — на Prod.
    Для автоматизации экспорта/импорта решений и минимизации ручных операций используйте утилиты для CI/CD, которые поддерживает ELMA365. Это позволяет выстроить процесс по принципу DevOps: изменения автоматически выгружаются из Dev, импортируются в Test, а затем — в Prod после одобрения.

    2. Необходимость экспорта/импорта всего решения даже при минимальных изменениях
    Да, в текущей архитектуре ELMA365 любое изменение в приложении (например, изменение формы просмотра, добавление поля, изменение бизнес-процесса) требует экспорта/импорта всего решения, в котором это приложение находится.
    Накапливать изменения и переносить их пакетно — это рекомендуемая практика, чтобы минимизировать количество релизов и упростить откат в случае ошибок..
    Обходных путей или более "гранулярного" экспорта/импорта (например, только одной формы или одного бизнес-процесса) в ELMA365 не предусмотрено.
    Рекомендуемые статьи:
    https://community.elma365.com/ru/threads/1784/
    https://community.elma365.com/ru/threads/2146/
    https://community.elma365.com/ru/threads/3114/