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

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

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

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