Стоит ли отказываться от хранилища конфигурации 1С в пользу Git

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Сравнение моделей работы: централизованная блокировка против ветвления

Штатное хранилище конфигурации 1С реализует централизованную модель с пессимистической блокировкой (захватом) объектов. Это означает, что разработчик перед внесением правок монопольно захватывает объект метаданных, что исключает одновременное изменение одного и того же элемента несколькими участниками команды.

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

  1. Конфликты в XML-структурах и формах. Исходные коды управляемых форм и метаданных выгружаются в виде набора XML-файлов. Git воспринимает XML как обычный плоский текст. Если два разработчика параллельно изменяют состав или взаимное расположение элементов на одной форме, текстовое слияние веток приведет к конфликту или внедрению меток слияния (<<<<<<<, =======, >>>>>>>), что нарушает валидность XML-документа и делает невозможной обратную загрузку в Конфигуратор.
  2. Коллизии уникальных идентификаторов (UUID). При параллельном создании новых реквизитов, табличных частей или элементов управления платформа генерирует для них новые UUID. При слиянии веток текстовыми утилитами легко нарушить внутренние перекрестные ссылки между модулями, реквизитами и визуальными элементами формы.
  3. Обычные формы и бинарный формат. В конфигурациях на базе обычных форм (например, УПП 1.3) формы и макеты выгружаются в нечитаемый бинарный формат. Построчное сравнение и разрешение конфликтов средствами Git для таких объектов технически невозможно.
  4. Окончания строк и строковые литералы. При выгрузке исходников и передаче их между различными операционными системами изменение символов перевода строк (CRLF / LF) может приводить к ложным диффам в модулях или некорректной работе динамически собираемых запросов, использующих конструкции вида Символы.ПС.

Устранение сбоев штатного хранилища без перехода на Git

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

  1. Очистка локального кэша хранилища. Большинство ошибок синхронизации связано с повреждением локального кэша на рабочей станции разработчика. Очистим временные файлы профиля пользователя в каталогах данных приложений ОС.
  2. Оптимизация и проверка целостности. Выполним процедуру обслуживания базы хранилища через пункт меню Конфигуратора: Хранилище — Администрирование хранилища — Оптимизация.
  3. Пересоздание хранилища. При критическом повреждении внутренней базы данных хранилища (1cv8ddb.1CD) снимем конфигурацию с поддержки хранилища, сохраним актуальное состояние конфигурации в файл .cf и создадим новое чистое хранилище для продолжения разработки.

Штатные механизмы пакетной выгрузки конфигурации в файлы

Для организации версионирования исходников платформа 1С предоставляет специальные параметры запуска Конфигуратора в пакетном режиме. Рассмотрим основные команды, используемые для автоматизации:

  1. Полная выгрузка и загрузка конфигурации:

    Команды -DumpConfigToFiles и -LoadConfigFromFiles выполняют полную выгрузку или загрузку метаданных в иерархическую структуру каталогов и XML-файлов.

  2. Инкрементальная выгрузка:

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

  3. Работа с расширениями конфигурации:

    Команды -DumpExtensionToFiles и -LoadExtensionToFiles предназначены для выгрузки и загрузки исходных кодов расширений. Отметим, что в современных версиях платформы для расширений также поддерживается штатный механизм хранилища конфигурации.

Гибридный подход: совместное использование Хранилища 1С и Git

Наиболее надежной практикой в корпоративной разработке 1С является гибридная схема, объединяющая достоинства обоих инструментов:

  1. Разработка через хранилище 1С. Программисты продолжают вносить изменения внутри Конфигуратора, используя штатное хранилище с механизмом блокировок. Это гарантирует целостность метаданных, корректность визуальных форм и отсутствие бинарных конфликтов.
  2. Автоматический экспорт в Git. На сервере настраивается регламентный скрипт непрерывной интеграции (CI), который опрашивает хранилище 1С, получает свежие версии и выгружает их в каталог файлов с помощью параметров пакетного режима Конфигуратора.
  3. Код-ревью и аудит. Полученные коммиты отправляются в репозиторий Git. Это позволяет всей команде просматривать диффы изменений через современные веб-интерфейсы, проводить аудит кода, настраивать статический анализ и запускать автоматические тесты.

Если же команда выбирает полноценную разработку в ветках Git без хранилища, слияние конфликтующих веток необходимо производить не текстовыми командами git merge, а исключительно через механизм трехстороннего сравнения и объединения в Конфигураторе 1С с последующей повторной выгрузкой результата в исходные файлы.

← На главную