Групповая разработка в КД 3.0: Как не потерять код при синхронизации (Часть 1)

Групповая разработка в КД 3.0: Как не потерять код и не мешать коллегам (Часть 1)

Рабочий момент: Когда синхронизация идет не по плану

Представьте ситуацию: в команде работают два разработчика — Анна и Дмитрий.

• Анна ведет сложный проект. Ее правила захвачены в базе КД 3, работа в активной фазе, код еще не готов к релизу.

• Дмитрий решает устранить «техдолг» и синхронизирует базу КД 3 с актуальным модулем менеджера обмена из рабочей конфигурации (УТ 11).

При загрузке модуля система видит: в текстовом файле нет тех новых правил, которые Анна создала у себя в «захваченном» состоянии. Для КД 3.0 текстовый модуль — это «зеркало» правды. Если правила нет в коде, система помечает его в базе как лишнее (на удаление).

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

Предостережение от эксперта: Ловушка «ведущего» кода

Многие привыкли к логике КД 2.0, где база была первична. В КД 3.0 код модуля является ведущим.

Главный инсайт: Любой объект, не имеющий отражения в методах ЗаполнитьПравилаКонвертацииОбъектов (даже если он захвачен вами!), находится в зоне риска при массовой загрузке модуля другим участником.

Выход: Чтобы ваши правила «выжили» при чужой синхронизации, они должны быть либо зафиксированы в общем модуле (хотя бы в виде заглушек), либо вы должны временно выключить регламент очистки базы, чтобы иметь возможность восстановить помеченные объекты.

Магия захвата: Как работать параллельно?

Несмотря на риски при синхронизации, КД 3.0 обладает мощнейшим механизмом изоляции через захват объектов. Это снимает главный страх разработчика: «А не попадет ли мой сырой код в чужую выгрузку?»

Как это работает (Разбор на примере)

Допустим, у нас есть общее правило (ПВД) для Заказа клиента. Анне нужно внести в него масштабные изменения, которые пока не должны попасть в основной релиз.

1. Анна захватывает объект. Теперь она работает в своем «контексте».

2. Анна редактирует правило. Эти изменения сохраняются в базе КД под ее авторством.

3. Выгрузка модуля: * Когда модуль выгружает Анна, система берет ее «захваченную» версию. Она может спокойно отлаживать свой функционал.

   • Когда модуль выгружает Дмитрий или любой другой коллега, система берет старую (релизную) версию этого же правила.

Итог: Захват объекта создает «персональное зеркало». Вы не мешаете коллегам, а они не могут случайно отправить ваш «сырой» код в релиз, пока вы не «отпустите» захват.

FAQ: Нужно ли дергать галочки «Выключено»?

Часто возникает вопрос: «Нужно ли снимать галочки активности, чтобы правила не лезли в общий модуль?»

Ответ: Нет, если вы используете механизм захвата правильно.

• Галочка стоит (Выключено): Правило полностью игнорируется генератором кода. Это нужно для объектов, которые вообще не должны попадать в модуль (даже в ваш).

• Галочка снята (Активно): Правило выгружается. Но благодаря механизму захвата, оно будет выгружаться только у вас в новой версии, а у коллег — в старой.

Резюме: Регламент «выживания» в КД 3.0

1. Захватывайте объекты сразу: Это ваша гарантия, что в чужой модуль ваши правки не попадут.

2. Легализуйте код: Если работа над правилом долгая, поместите в общий модуль хотя бы пустую процедуру-заглушку с именем вашего правила. Это защитит объект от удаления при массовой синхронизации.

3. Отключите авто-очистку: В базе для групповой разработки пометка на удаление должна быть поводом для диалога, а не сигналом для робота-уборщика.

4. Синхронизируйтесь осознанно: Перед загрузкой модуля в КД 3 убедитесь, что никто из коллег не держит объекты «в захвате» без отражения в коде.

В следующей статье: Мы разберем особенности отладки захваченных правил и работу с XDTO-пакетами в условиях нескольких проектов.

А как вы решаете конфликты при обновлении метаданных в КД 3.0? Пишите в комментариях!