Как обновлять конфигурацию на поддержке при разработке в 1C:EDT?

При переходе на современный стек разработки с использованием 1C:Enterprise Development Tools (EDT) и Git многие специалисты сталкиваются с неочевидным вопросом: как правильно устанавливать новые релизы типовых конфигураций (например, УТ 11, ERP или БП 3.0), если конфигурация находится на поддержке с возможностью изменения? В традиционном Конфигураторе этот процесс автоматизирован, но в EDT механизмы работы с конфигурацией поставщика реализованы иначе. Разберем детально, как выстроить процесс обновления и не потерять свои доработки.

Метод 1: Гибридная схема (Официальная рекомендация)

На текущий момент самым надежным и проверенным способом остается совместное использование EDT и классического Конфигуратора. Поскольку EDT не содержит встроенного мастера «Сравнение/Объединение с конфигурацией поставщика», нам необходимо делегировать эту задачу платформе.

Рассмотрим пошаговый алгоритм совместной работы:

1. Подготовка базы: Перед началом обновления убедимся, что все текущие изменения из проекта EDT успешно экспортированы в информационную базу (ИБ). Состояние проекта и базы должно быть идентичным.
2. Обновление в Конфигураторе: Запускаем привычный Конфигуратор. Переходим в меню Конфигурация — Поддержка — Обновить конфигурацию. Выбираем файл обновления (.cf или .cfu) и выполняем стандартную процедуру сравнения и объединения. На этом этапе мы разрешаем конфликты, расставляем правила объединения и следим за тем, чтобы наши доработки не были затерты кодом поставщика.
3. Принятие изменений: После завершения объединения выполняем Обновить конфигурацию базы данных (F7). Это критически важно, так как EDT считывает данные именно из состояния ИБ.
4. Синхронизация с EDT: Возвращаемся в EDT. В панели «Приложения» или «Навигатор» нажимаем правой кнопкой мыши на наш проект и выбираем команду Обновить проект из ИБ... (в новых версиях — «Импортировать изменения из информационной базы»).
5. Фиксация в Git: После того как EDT подтянет обновленные XML-файлы исходников, мы увидим массу изменений в панели Git Staging. Нам остается проверить их и зафиксировать (commit) новый релиз в истории версий.

Метод 2: Использование стратегии «Веток поставщика» (Vendor Branches)

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

Суть метода заключается в хранении «чистых» исходников поставщика в отдельной ветке. Разберем этот процесс подробнее:

1. Создаем в репозитории ветку vendor (или upstream), в которой никогда не бывает наших доработок — только код от 1С.
2. При выходе нового релиза мы конвертируем файл .cf в формат исходников EDT (это можно сделать через командную строку утилитой ring или просто создав временный проект в EDT и импортировав туда .cf).
3. Загружаем эти файлы в ветку vendor.
4. В основной ветке разработки (master или develop) выполняем git merge vendor.

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

Проблема потери статуса поддержки («замков»)

Выясним причину, по которой иногда «слетает» поддержка при работе через EDT. Как отмечают пользователи, в ранних версиях среды (например, 1.8) при записи проекта в базу данных могли затираться метаданные о конфигурации поставщика. Это происходило потому, что EDT оперирует файлами, а информация о поддержке хранится в специальных таблицах базы данных 1С.

Чтобы избежать повреждения поддержки, придерживайтесь правил:

• Никогда не редактируйте вручную файлы метаданных в папке .settings проекта, если не понимаете их структуру.
• При импорте обновлений из ИБ следите за тем, чтобы в диалоге импорта были выбраны все объекты, включая корень конфигурации.
• Используйте актуальные версии EDT (2023.x и выше), где механизмы сопоставления объектов и сохранения «замков» были значительно доработаны.

Автоматизация через EDT CLI

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

// Пример логики автоматизации обновления
// 1. Экспорт конфигурации поставщика в XML
ring edt@current workspace-export --project MyProject --configuration-file vendor_new.cf
// 2. Импорт обновленных файлов в проект
ring edt@current project-import --project MyProject --source-path ./src

Это позволяет интегрировать процесс обновления в CI/CD пайплайны, обеспечивая чистоту кода и прозрачность истории изменений.

Использование расширений как способ упростить обновление

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

В такой архитектуре обновление происходит максимально просто:

1. Вы заменяете основную конфигурацию на новую версию поставщика простым «Загрузить конфигурацию из файла».
2. Ваш проект EDT с основной конфигурацией просто обновляется из ИБ.
3. Ваш основной проект EDT с расширением проходит проверку на применимость к новой версии. Если в расширении возникли ошибки из-за удаления или переименования методов в основной конфигурации, EDT сразу подсветит их в списке ошибок проекта.

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