5.2. Как выбрать уровень изоляции. Как сохранить изоляцию. Обновление решений

Выбирая какой уровень изоляции использовать для решения, опирайтесь:

• на размер команды, которая будет разрабатывать и развивать решение;
• на количество контуров, которые будут изменяться параллельно;
• на зависимость контуров друг от друга.

Чаще всего используется уровень изоляции на уровне разделов, модулей и решений.

Рекомендации по выбору уровня изоляции в зависимости от размера команды описаны в главе «Разработка решения командами разного размера».

Как сохранить изоляцию

Чтобы иметь возможность использовать оргструктуру и элементы платформы из других разделов, но при этом сохранить изоляцию, следуйте следующим рекомендациям.

Зависимости

При разработке решений вам может потребоваться приложение или бизнес-процесс из другого раздела, но это нарушит изоляцию на уровне раздела. Чтобы сохранить изоляцию, но использовать приложение, создайте два решения и добавьте в него по одному разделу.

Изоляция на уровне решений поддерживает зависимости от других решений. Это значит, что вы можете сослаться на приложение из другого раздела, не входящего в это решение. При этом другой раздел должен быть включён в другое решение. Тогда при экспорте будет возможность установить зависимость одного решения от другого.

Важно

Необходимо разработать функционал для HR-отдела: от подбора персонала и найма до адаптации, обучения и увольнения. Запуск контуров будет последовательный, но сроки сжатые, поэтому требуется вести разработку параллельно.

Разбейте решение на контуры семантически:

1. Подбор персонала — вакансии, кандидаты, собеседования, офферы, переход из кандидата в сотрудника;
2. Найм и увольнение — сотрудники, кадровые документы, штатное расписание;
3. Адаптация и обучение — сотрудники, курсы обучения, аттестации, опросы и т. д.

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

Очевидно, что в каждом контуре нужны сотрудники и некоторые связанные с ними справочники, например, категории сотрудников и т. п.

Чтобы не нарушать изоляцию каждого контура, используйте раздел Системные справочники, в котором создайте все общие приложения. Затем создайте решение, в составе которого будет только раздел Системные справочники.

Каждый контур следует реализовать решением: это позволит ссылаться на приложения и бизнес-процессы из раздела Системные справочники. При экспорте такого решения будет установлена зависимость от решения Системные справочники. А при его импорте система проверит наличие решений, от которых оно зависит.

Использование оргструктуры

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

Чтобы сохранить изоляцию, используйте группы и роли в зонах ответственности бизнес-процессов и на уровне приложений и разделов для разграничения прав доступа. Должности из оргструктуры добавляйте в группы и роли после импорта разделов и решений в продакшн-среду. Это позволит вам сохранить изоляцию и права доступа при перемещении сотрудников с должности на должность.

Интерфейс создания элементов приложений из других разделов

Если вам необходимо создать единый интерфейс для пользователя, в котором в составе разных решений будет организовано взаимодействие с приложениями, используйте виджет Код.

В нём с помощью HTML-разметки можно отрисовать кнопки. Или, например, в тег <a> вставить относительную ссылку на создание элемента приложения:

Код:

<a href="./(p:item/kedo/letter_of_resignation)">Оформить</a>

где:

• kedo — код раздела;
• letter_of_resignation — код приложения.

Такая реализация позволит нарисовать кнопку или ссылку Оформить в интерфейсе. При нажатии на неё откроется форма создания элемента приложения. В таком случае изоляция не нарушается, так как нет явной связи между разделами.

Важно

При использовании этого приёма вам придётся самостоятельно контролировать наличие необходимых решений для их корректной работы.

Обновление решений

Обновление решения осуществляется с помощью механизма экспорта из исходной среды и импорта в целевую. Обновлять можно разделы, модули, решения и конфигурацию. Механизм работает одинаково на всех уровнях изоляции. Мы рассмотрим его на примере решения.

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

Конфликт может быть двух типов:

1. уведомление с возможностью перезаписать конфликтующие элементы конфигурации;
2. необратимый конфликт, который не позволит обновить решение.

Первый возникает, если вы внесли изменения на продакшн в существующие элементы платформы в составе решения. Второй — если вы добавили элемент платформы в решение вручную в среду разработки и также вручную на продакшн.

Важно

При разработке рекомендуется вносить изменения в решения только в среду разработки и доставлять эти изменения в другие среды только с помощью процедуры импорта/экспорта или утилиты для CI/CD.

Спойлер: Пример

Вы создали решение Управление договорами в среде разработки и перенесли его в продакшн. В обеих средах есть идентичные решения.

Разберём пример решения со следующим составом:

• раздел Договоры:
  • приложение Договор;
  • приложение ДС к договору;
  • бизнес-процесс Согласование договорных документов;
• модуль Интеграция с ЮЗДО:
  • действие в БП Отправка документа;
  • действие в БП Получение документа;
  • бизнес-процесс Синхронизация статусов.

Рассмотрим разные варианты изменений и результат обновления со среды разработки на продакшн:

• На продакшн добавили приложение Вид договора, в среду разработки — приложение Тип договора.

Результат: при обновлении конфликта не возникнет, на продакшне будут оба приложения.​

• На продакшн добавили приложение Вид договора, в среду разработки — приложение Вид договора.

Результат: если их коды совпадают, то обновиться не получится; если коды отличаются, то на продакшне будут оба приложения.​

• На продакшне изменили форму приложения Договор.

Результат: при обновлении возникнет конфликт, и вы сможете:

• отменить обновление;
• перезаписать конфликтующие элементы.

Во втором случае форма приложения на продакшне заменится формой из среды разработки, изменения будут утеряны.​

• На продакшне создали новую форму для приложения Договор.

Результат: при обновлении возникнет конфликт, и вы сможете:

• отменить обновление;
• перезаписать конфликтующие элементы.

Во втором случае форма приложения на продакшне заменится формой из среды разработки, но созданная форма сохранится и будет доступна для выбора в настройках приложения.​

• На продакшне изменили бизнес-процесс Согласование договорных документов.

Результат: при обновлении возникнет конфликт, и вы сможете:

• отменить обновление;
• перезаписать конфликтующие элементы.

Во втором случае бизнес-процесс на продакшне заменится, изменения будут доступны в предыдущей версии бизнес-процесса.​

Если решение не обновляется

Если ваше решение не обновляется, воспользуйтесь следующими рекомендациями:

• С организационной точки зрения: измените процедуру разработки и больше не допускайте ситуаций, когда ваше решение изменяется где-то, кроме среды разработки.
• С технической: разверните новую среду разработки и перенесите туда решение с продакшна, после чего внесите недостающие изменения вручную.