← На главную

Обновление конфигураций 1С, в которые были внесены доработки, — одна из самых частых и трудоемких задач для программиста. Возникает закономерный вопрос: как выстроить этот процесс, чтобы он был предсказуемым, надежным и по возможности автоматизированным? Хочется найти одну методику, отточить ее, подобрать инструменты и довести до автоматизма. Давайте разберем, какие подходы существуют, начиная от базовых ручных методов и заканчивая современными практиками.

Подготовительный этап: Ключевые принципы

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

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

2. Последовательность обновлений. Очень важный момент, на который часто не обращают внимания. Не перепрыгивайте через релизы. Если ваша текущая версия 2.4.5, а актуальная — 2.4.7, обновляйтесь поэтапно: 2.4.5 -> 2.4.6 -> 2.4.7. Почему это так критично?

В каждом промежуточном релизе могут содержаться специальные обработчики обновления, которые корректируют структуру данных. Например, разработчик мог переименовать реквизит или перенести данные из одного регистра в другой. Если пропустить такой релиз, обработчики не выполнятся, и вы можете столкнуться с трудноуловимыми ошибками в данных или в коде. Классический пример из практики — реквизиты, которым вендор присваивает префикс Удалить. В одном из обновлений реквизит Количество мог быть переименован в УдалитьКоличество, а в следующем — окончательно удален, а его данные перенесены. Пропустив промежуточное обновление, вы рискуете получить неработающие запросы или процедуры, которые обращаются к уже несуществующему полю, как это и произошло в обсуждаемой на форуме ситуации.

Основной метод: Сравнение и объединение в Конфигураторе

Это классический, базовый способ, с которого начинают все разработчики. Разберем его по шагам.

1. Откройте конфигуратор вашей рабочей базы.
2. В меню выберите «Конфигурация» -> «Поддержка» -> «Обновить конфигурацию».
3. Выберите файл обновления (.cfu или .cf) новой версии.
4. После анализа платформа предложит окно сравнения и объединения. Здесь и начинается основная работа.

Ключевой инструмент в этом окне — настройка фильтра. Обратите особое внимание на опцию «Показывать дважды измененные свойства». Именно она подсвечивает самые проблемные места — объекты, которые изменили и вы (или другой разработчик), и поставщик в новом релизе. Это и есть точки конфликтов, которые требуют ручного анализа и переноса изменений.

Ваша задача — внимательно пройти по всем таким объектам (модулям, формам, ролям) и аккуратно перенести свои доработки в новую версию объекта от поставщика. Нельзя просто оставлять свой старый объект, так как в нем будет отсутствовать новый функционал от вендора.

Работа с кодом и формами: Применение внешних инструментов

Стандартное окно сравнения модулей в Конфигураторе не всегда удобно. Оно не очень наглядно показывает различия в больших блоках кода. Здесь на помощь приходят внешние программы для сравнения текстов (diff-утилиты).

Как это работает?

В настройках Конфигуратора (Сервис -> Параметры -> Закладка «Тексты» -> «Внешние программы») можно указать путь к такой утилите. Популярные варианты: KDiff3, Araxis Merge, WinMerge, Beyond Compare или встроенные инструменты сравнения в редакторах кода вроде VS Code.

Когда вы в окне сравнения конфигураций дважды щелкнете по измененному модулю, 1С автоматически выгрузит три версии текста (старая версия поставщика, ваша версия, новая версия поставщика) и откроет их во внешней программе. Трехстороннее сравнение гораздо нагляднее и позволяет:

• Четко видеть, какой код был добавлен/удален поставщиком.
• Видеть, какой код добавили вы.
• Осознанно объединять эти изменения в итоговый текст модуля.

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

Современные подходы: Упрощение и автоматизация

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

1. Максимальное использование расширений

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

Преимущества:

• Простое обновление: Основная конфигурация обновляется стандартно, в несколько кликов, так как в ней нет изменений.
• Минимум конфликтов: Вам остается только адаптировать расширение к новой версии, если поставщик изменил те объекты, которые вы "заимствовали" или расширили. Объем работы несоизмеримо меньше.
• Изоляция доработок: Легко включать, отключать и анализировать кастомный функционал.

Этот подход требует пересмотра архитектуры доработок, но в долгосрочной перспективе он окупается многократно.

2. Системы контроля версий (Git)

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

Базовый процесс выглядит так:

1. Выгрузка в исходные тексты. Конфигурация (и ее обновления) выгружается в набор текстовых файлов с помощью специальных утилит, например, 1C:Enterprise Development Tools (EDT), gcomp или скриптов на OneScript.
2. Создание веток. В Git-репозитории создаются отдельные ветки: одна для "чистых" релизов поставщика (например, `vendor`), другая для ваших доработок (`develop`).
3. Слияние (Merge). Когда выходит новый релиз, вы обновляете ветку `vendor`, а затем сливаете эти изменения в свою ветку `develop`. Git автоматически объединяет изменения и показывает конфликты только там, где один и тот же участок кода был изменен и в релизе поставщика, и в вашей доработке.
4. Разрешение конфликтов. Конфликты решаются в удобном редакторе кода (например, VS Code), который предоставляет мощные инструменты для слияния.
5. Сборка конфигурации. Из результирующих текстовых файлов обратно собирается файл .cf для загрузки в базу.

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

3. Автоматизация (CI/CD) и рефакторинг

Вершиной мастерства является полная автоматизация процесса обновления с использованием принципов CI/CD (непрерывная интеграция и доставка).

• Скрипты автоматизации. С помощью инструментов вроде OneScript и Vanessa-Automation можно написать скрипты, которые будут автоматически скачивать новый релиз, выполнять слияние в Git, собирать конфигурацию, загружать ее в тестовую базу, запускать обработчики обновления и выполнять набор дымовых тестов для проверки работоспособности.
• EDT. Среда разработки 1C:Enterprise Development Tools предоставляет более продвинутые инструменты для анализа кода, рефакторинга и сравнения объектов, чем классический Конфигуратор.
• Рефакторинг при обновлении. Каждое обновление — это повод не просто перенести старые доработки, а провести их ревизию. Проверьте, не появился ли в новом релизе типовой механизм, который решает вашу задачу. Если да, то лучше отказаться от своей доработки в пользу типового функционала. Это позволяет постепенно уменьшать объем нетипового кода, приближая конфигурацию к стандартной и упрощая будущие обновления.

В итоге, выбор методики зависит от масштаба доработок и квалификации команды. Можно начать с отладки надежного ручного процесса с использованием внешних diff-утилит и строгого соблюдения последовательности релизов, а по мере роста сложности — переходить на использование расширений, Git и средств автоматизации.