...

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

Тема в разделе "Вопросы по платформе", создана пользователем 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/
  4. sunidea

    sunidea Участник

    Здравствуйте!
    Например есть Dev → Prod контура. МЫ ведем разработку в dev в одном разделе. Затем мы экспортируем этот раздел на prod.
    Но при экспорте раздела не импортируются данные в приложениях, дополнительных параметрах раздела. Как быть с этим? Как производить обновления без потери данных или их необходимо переносить отдельно (тода есть ли какие то варианты кроме как ручного эскпорт/импорт каждого приложения?)
  5. semenova

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

    Добрый день!
    При экспорте и импорте раздела в ELMA365 переносятся только структура (настройки, бизнес-процессы, формы, статусы и т.д.), но данные приложений (записи, элементы) не экспортируются и не импортируются автоматически. Это является стандартным поведением системы.
    Если вам нужно перенести не только структуру, но и данные (например, справочники, тестовые данные, шаблоны), это делается отдельно.
    Возможные варианты:
    1. Ручной экспорт/импорт данных
      В каждом приложении можно воспользоваться функцией экспорта данных в Excel/CSV и последующего импорта на нужную среду. Это делается через интерфейс приложения. Подробнее в справке: https://elma365.com/ru/help/platform/360009264480.html https://elma365.com/ru/help/platform/360009354059.html
    2. Использование интеграций или скриптов
      Для автоматизации можно использовать Web API, сценарии или интеграционные модули, чтобы выгружать и загружать данные программно. Доступные методы API: https://api.elma365.com/ru/
  6. sunidea

    sunidea Участник

    Здравствуйте!
    Можете тогда ещё ответить на вопрос, чтобы внести ясность.
    Например, приложение работает в Production контуре с реальным набором данных, появляются задачи, ведется активная работа.
    Далее мы внесли изменения в dev контуре.
    Как наше решение перенести с dev на production?
    Делаем экспорт/импорт раздела, при этом есть следующие проблемы:
    1. Перенос данных и сохранение ссылок на них (необходимо сохранить ID шники элементов). Через api, насколько мне известно, нельзя присвоить значение свойству __ID элемента приложение, так как оно readonly. Остается только ручной экспорт данных каждого приложения (с включенной опцией "Экспортировать системную информацию"). Но и при ручном экспорте станут невалидными задачи, к которым привязаны элементы приложения.
    2. Также поменяется ссылка на раздел (даже если удалить старый раздел, нельзя создать раздел с такой же ссылкой). Поэтому если у кого-то сохранена прямая ссылка на какой-то элемент, она станет невалидной.
    Как быть в этом случае?
    Последнее редактирование: 22 дек 2025 в 04:31
  7. semenova

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

    Добрый день!
    При переносе раздела доступна возможность обновления раздела. В таком случае раздел не создается снова, а обновляется уже имеющийся раздел, поэтому перенос данных также не нужен. Подробнее: https://elma365.com/ru/help/platform/section_update.html
    Также рекомендуем переносить раздел в составе решения. При корректном переносе решения также не создается новый раздел, что не требует переноса данных.

    Экспорт/импорт данных приложения не подразумевает перенос связанных задач, только данных из самих элементов.