← На главную

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

Поведение Git и платформы 1С при удалении метаданных

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

1. Удаление файлов объекта: При штатной выгрузке конфигурации в файлы каталог удаленного объекта (включая XML-описание, формы, модули и макеты) полностью стирается из локального каталога исходников.
2. Модификация манифеста конфигурации: В корневом файле Configuration.xml (или проектном файле) платформа удаляет ссылку на объект из секции ChildObjects.
3. Фиксация в Git: В индексе системы контроля версий удаление отображается как набор удаленных файлов и одна строковая модификация в родительском манифесте метаданных.

Важно помнить об идентификаторах (UUID): Каждый объект метаданных в 1С однозначно идентифицируется внутренним уникальным идентификатором. Если вы удалите справочник или документ, а затем создадите его заново с точно таким же именем, платформа сгенерирует новый UUID. Для СУБД это будет совершенно новая таблица, а вся предыдущая информация и связи окажутся утерянными.

Двухэтапная схема удаления для тиражных и продуктивных решений

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

1. Этап 1: Перевод в статус устаревшего (Депрекация)

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

2. Этап 2: Физическое удаление

   Физическое удаление объекта из конфигурации и репозитория Git выполняется только в следующем релизе. К этому моменту все рабочие базы гарантированно прошли миграцию данных на первом этапе, и удаление пустых таблиц из СУБД проходит без риска потери бизнес-информации.

Когда допустимо немедленное физическое удаление

Выясним, в каких случаях можно удалять объекты сразу без предварительного переименования:

1. Объекты без данных: Вспомогательные формы, служебные макеты, общие модули или внешние обработки, которые не создают таблиц в базе данных и не хранят пользовательские данные.
2. Изолированные ветки разработки: Экспериментальные объекты, созданные в рамках локальной ветки задачи (feature-branch) и еще не попавшие в релизную ветку или на продуктивный контур.
3. Проекты с полной перезаливкой тестовых данных: Небольшие заказные разработки на этапе первичного проектирования до ввода в промышленную эксплуатацию.

Риски и конфликты при слиянии веток в Git

Разберем основные сложности, возникающие в коллективной разработке при удалении объектов метаданных:

1. Конфликт изменения и удаления (Modify/Delete conflict): Возникает, если в одной ветке разработчик удалил объект, а в параллельной ветке коллега внес правки в его модуль или форму. При слиянии веток Git потребует вручную решить: удалить ли доработанный объект целиком или восстановить его с внесенными изменениями.
2. Конфликты в корневом файле Configuration.xml: Если один разработчик удаляет один объект, а второй в параллельной ветке добавляет другой, строки в секции ChildObjects могут пересечься. Ручное разрешение таких конфликтов требует предельной аккуратности, чтобы не нарушить валидность XML-структуры, иначе платформа не сможет собрать конфигурацию из исходников.
3. Битые ссылки и нарушение целостности: Удаление объекта метаданных не очищает автоматически ссылки на него в других элементах конфигурации. Необходимо вручную проверить и удалить упоминания в:

   — составах подсистем и планов обмена;

   — ролях и правах доступа;

   — типах реквизитов других объектов, схемах компоновки данных (СКД) и динамических списках.

Практические рекомендации по организации процесса

Для стабильной работы команды придерживайтесь следующих правил:

1. Используйте автоматическую проверку (CI/CD): Настройте пайплайн непрерывной интеграции, который при каждом пул-реквесте выполняет синтаксический контроль и валидацию конфигурации через выгрузку/загрузку в тестовую базу. Это позволит выявить битые ссылки до слияния изменений в основную ветку.
2. Фиксируйте удаление отдельным коммитом: Не смешивайте в одном коммите массовое удаление старых метаданных и сложную бизнес-логику нового функционала. Это упростит аудит истории и поиск ошибок при слияниях.
3. Очищайте ссылки перед удалением: Перед физическим удалением объекта в конфигураторе используйте поиск ссылок на объект, чтобы предварительно убрать его из всех ролей, подсистем и составных типов данных.