Разработка правил в «1С:Конвертация данных» параллельно: как организовать командную работу без потери кода

Разработка правил обмена в конфигурации «1С:Конвертация данных 2.1» (КД 2.1) традиционно считается задачей для одного специалиста. Это обусловлено спецификой хранения правил: все настройки, обработчики событий и алгоритмы представляют собой единую монолитную структуру. При попытке выгрузить правила в XML-файл мы получаем огромный документ, совместное редактирование которого стандартными средствами контроля версий превращается в кошмар из-за конфликтов слияния.

Однако на крупных проектах внедрения (например, при переходе со старых кастомизированных систем на современные конфигурации уровня ERP) объем объектов исчисляется сотнями. В таких условиях один разработчик физически не успевает настроить все правила в жесткие проектные сроки. Возникает острая необходимость распараллелить процесс. Рассмотрим подробнее, как организовать командную разработку правил обмена, избежать затирания чужих изменений и автоматизировать сборку готового пакета правил.

Вариант 1. Совместная работа в единой базе «Конвертации данных»

Это самый очевидный и простой в реализации подход, который не требует внедрения сложных сторонних инструментов. Разработчики работают в одной информационной базе КД 2.1, развернутой на SQL-сервере.

Для успешной реализации этой схемы настроим и применим следующие правила:

1. Разграничение прав и пользователей. Каждому разработчику создаем отдельную учетную запись в базе КД. Платформа 1С использует механизм объектных блокировок. Когда один разработчик открывает для редактирования конкретное ПравилоКонвертацииОбъектов (ПКО) или ПравилоВыгрузкиДанных (ПВД), платформа автоматически блокирует этот элемент справочника для других пользователей. Это исключает риск одновременного изменения одного правила.
2. Группировка правил. Чтобы разработчики не мешали друг другу, распределим задачи по логическим блокам. В КД 2.1 создаем группы правил (например, «НСИ_Иванов», «Документы_Петров», «Производство_Сидоров»). Каждый разработчик создает новые ПКО и ПВД только внутри своей группы.
3. Включение версионирования объектов. Поскольку в КД нет встроенной кнопки «Отменить действие», любая критическая ошибка разработчика может повредить рабочее правило. Для защиты кода снимем конфигурацию КД с поддержки и включим стандартное платформенное версионирование объектов для справочников правил, алгоритмов и конвертаций. Это позволит в любой момент проанализировать историю изменений обработчика и вернуться к предыдущему стабильному состоянию.
4. Вынос общего кода в «Алгоритмы». Если нескольким разработчикам требуется схожая логика в обработчиках событий, запретим писать дублирующийся код непосредственно в ПКО. Весь общий код оформляем в виде элементов справочника «Алгоритмы» КД. Вызов такого кода в обработчиках будет выглядеть лаконично:

// Пример вызова общего алгоритма в обработчике ПКО
Выполнить(Алгоритмы.ЗаполнитьДополнительныеСвойстваНоменклатуры);

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

Вариант 2. Раздельные локальные базы и встроенное сравнение/объединение

Если работа в единой базе невозможна (например, разработчики находятся в разных сетях без быстрого доступа к общему серверу), применим схему с распределенными базами и последующим слиянием правил.

Для этого воспользуемся встроенной обработкой «Сравнение и объединение правил обмена», которая присутствует в КД начиная с версии 2.1.7.1. Разберем этот процесс по шагам:

1. Каждый разработчик разворачивает у себя локальную базу КД 2.1 и загружает в нее одинаковую исходную структуру метаданных.
2. Разработчики создают свои правила обмена локально. Один настраивает ПКО для справочников, другой — для документов закупки, третий — для документов продаж.
3. В конце рабочего дня (или спринта) разработчики выгружают свои правила в файлы XML и передают их ведущему разработчику (ответственному за интеграцию).
4. Ведущий разработчик открывает мастер-базу КД, запускает обработку «Сравнение и объединение правил» и поочередно загружает файлы коллег.
5. В интерфейсе сравнения визуально сопоставляются измененные ПКО, ПВД, алгоритмы и параметры. Интегратор выбирает нужные объекты, разрешает конфликты и объединяет изменения в мастер-базу.
6. После слияния актуальная версия правил выгружается из мастер-базы КД и рассылается всей команде как новая отправная точка для следующего этапа работы.

Вариант 3. Использование систем контроля версий (Git) и декомпозиция правил

Для продвинутых команд разработки наиболее эффективным решением является использование Git. Напрямую хранить и мержить гигантский XML-файл правил КД невозможно: платформа 1С при выгрузке может хаотично менять последовательность узлов, из-за чего Git будет показывать ложные конфликты на тысячи строк. Однако мы можем обойти это ограничение с помощью специализированных утилит.

Проанализируем процесс настройки профессиональной Git-разработки правил КД:

1. Используем консольную утилиту GitRules (на базе OneScript) или аналогичные внешние обработки для разборки XML.
2. Перед помещением изменений в репозиторий утилита автоматически «разбирает» один монолитный файл правил XML на структурированный каталог файлов на диске. Каждый объект КД (ПКО, ПКС, ПВД, алгоритм, параметр) сохраняется в свой отдельный небольшой XML-файл, а программный код обработчиков событий выносится в отдельные .bsl-файлы (чистый код 1С).
3. Разработчики ведут работу локально в своих базах КД, выгружают правила в XML, запускают декомпозицию и коммитят изменения в Git. Разберем пример команды декомпозиции:

// Пример команды декомпозиции файла правил на исходники
grules.os --decompile --rules "C:\KD\ExchangeRules.xml" --out "C:\GitProject\src"

Благодаря декомпозиции, если Разработчик А изменил только обработчик ПКО «Договоры контрагентов», изменения в репозитории затронут исключительно один файл ПКО_ДоговорыКонтрагентов_ПередВыгрузкой.bsl. Остальные файлы правил останутся нетронутыми. Git легко выполнит слияние (*merge*) таких изменений без конфликтов.

Перед тестированием или релизом выполняется обратная сборка единого XML-файла правил командой сборщика:

// Пример команды сборки единого XML-файла правил из исходников
grules.os --assemble --src "C:\GitProject\src" --out "C:\KD\ExchangeRules_Ready.xml"

Для предотвращения «нестабильности» XML (когда платформа меняет форматирование при выгрузке) рекомендуется использовать доработанную сообществом конфигурацию КД 2.1 — «Conversion plus». Она содержит патчи, гарантирующие идентичную структуру выгружаемых XML-файлов при неизменных данных.

Вариант 4. Переход на «Конвертацию данных 3.0»

Выясним, как обстоят дела с параллельной разработкой в современной редакции КД. Если вы проектируете интеграцию между конфигурациями, поддерживающими технологию EnterpriseData (универсальный формат обмена), настоятельно рекомендуем отказаться от КД 2.1 в пользу «Конвертации данных 3.0» (КД 3.0).

В КД 3.0 концепция полностью изменилась:

• Правила обмена больше не хранятся в виде настроек в XML-файле. Вместо этого они описываются в виде обычного программного кода 1С внутри модулей менеджера обмена конфигурации (модули МенеджерОбменаЧерезУниверсальныйФормат).
• Поскольку правила теперь представляют собой стандартные программные модули (текстовые файлы .bsl), задача параллельной разработки решается сама собой. Разработчики используют стандартную среду разработки 1C:EDT с интегрированным Git.
• Каждый разработчик создает свою ветку, реализует правила сопоставления объектов в коде функций, делает коммиты и отправляет Pull Request. Слияние и разрешение конфликтов происходят стандартными и привычными для всех программистов инструментами работы с кодом.

Резюме и рекомендации

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

• Для небольших команд (2–3 разработчика) на КД 2.1 оптимальным и быстрым решением будет работа в единой SQL-базе с включенным версионированием и жестким разделением объектов разработки по группам.
• Для распределенных команд, работающих над сложными правилами КД 2.1, лучшим выбором станет Git с декомпозицией XML-правил через утилиту GitRules.
• При наличии поддержки формата EnterpriseData в интегрируемых системах следует сразу переходить на КД 3.0, где командная разработка полностью бесшовна и поддерживается из коробки средствами 1C:EDT.