Групповая разработка в КД 3.0: Как не потерять код и не мешать коллегам (Часть 1)
Рабочий момент: Когда синхронизация идет не по плану
Представьте ситуацию: в команде работают два разработчика — Анна и Дмитрий.
-
Анна ведет сложный проект. Ее правила захвачены в базе КД 3, работа в активной фазе, код еще не готов к релизу.
-
Дмитрий решает устранить «техдолг» и синхронизирует базу КД 3 с актуальным модулем менеджера обмена из рабочей конфигурации (УТ 11).
При загрузке модуля система видит: в текстовом файле нет тех новых правил, которые Анна создала у себя в «захваченном» состоянии. Для КД 3.0 текстовый модуль — это «зеркало» правды. Если правила нет в коде, система помечает его в базе как лишнее (на удаление).
Ситуация в нашем кейсе усугубилась регламентным заданием, которое автоматически очистило помеченные объекты. Утром Анна обнаружила, что ее наработок в базе больше нет.
Предостережение от эксперта: Ловушка «ведущего» кода
Многие привыкли к логике КД 2.0, где база была первична. В КД 3.0 код модуля является ведущим.
Главный инсайт: Любой объект, не имеющий отражения в методах
ЗаполнитьПравилаКонвертацииОбъектов(даже если он захвачен вами!), находится в зоне риска при массовой загрузке модуля другим участником.
Выход: Чтобы ваши правила «выжили» при чужой синхронизации, они должны быть либо зафиксированы в общем модуле (хотя бы в виде заглушек), либо вы должны временно выключить регламент очистки базы, чтобы иметь возможность восстановить помеченные объекты.
Магия захвата: Как работать параллельно?
Несмотря на риски при синхронизации, КД 3.0 обладает мощнейшим механизмом изоляции через захват объектов. Это снимает главный страх разработчика: «А не попадет ли мой сырой код в чужую выгрузку?»
Как это работает (Разбор на примере)
Допустим, у нас есть общее правило (ПВД) для Заказа клиента. Анне нужно внести в него масштабные изменения, которые пока не должны попасть в основной релиз.
-
Анна захватывает объект. Теперь она работает в своем «контексте».
-
Анна редактирует правило. Эти изменения сохраняются в базе КД под ее авторством.
-
Выгрузка модуля: * Когда модуль выгружает Анна, система берет ее «захваченную» версию. Она может спокойно отлаживать свой функционал.
-
Когда модуль выгружает Дмитрий или любой другой коллега, система берет старую (релизную) версию этого же правила.
-
Итог: Захват объекта создает «персональное зеркало». Вы не мешаете коллегам, а они не могут случайно отправить ваш «сырой» код в релиз, пока вы не «отпустите» захват.
FAQ: Нужно ли дергать галочки «Выключено»?
Часто возникает вопрос: «Нужно ли снимать галочки активности, чтобы правила не лезли в общий модуль?»
Ответ: Нет, если вы используете механизм захвата правильно.
-
Галочка стоит (Выключено): Правило полностью игнорируется генератором кода. Это нужно для объектов, которые вообще не должны попадать в модуль (даже в ваш).
-
Галочка снята (Активно): Правило выгружается. Но благодаря механизму захвата, оно будет выгружаться только у вас в новой версии, а у коллег — в старой.
Резюме: Регламент «выживания» в КД 3.0
-
Захватывайте объекты сразу: Это ваша гарантия, что в чужой модуль ваши правки не попадут.
-
Легализуйте код: Если работа над правилом долгая, поместите в общий модуль хотя бы пустую процедуру-заглушку с именем вашего правила. Это защитит объект от удаления при массовой синхронизации.
-
Отключите авто-очистку: В базе для групповой разработки пометка на удаление должна быть поводом для диалога, а не сигналом для робота-уборщика.
-
Синхронизируйтесь осознанно: Перед загрузкой модуля в КД 3 убедитесь, что никто из коллег не держит объекты «в захвате» без отражения в коде.
В следующей статье: Мы разберем особенности отладки захваченных правил и работу с XDTO-пакетами в условиях нескольких проектов.
А как вы решаете конфликты при обновлении метаданных в КД 3.0? Пишите в комментариях!
Вступайте в нашу телеграмм-группу Инфостарт