Файл обновления .cfu и полный .cf: сборка в Конфигураторе 1С 8.3

Файл обновления конфигурации 1С создают в Конфигураторе через меню Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления конфигурации. На выходе получается файл .cfu: в нём только изменения между вашими прошлыми релизами и текущим. Если нужен полный файл конфигурации, хватит команды Конфигурация → Сохранить конфигурацию в файл — она даёт .cf.

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

Какой файл нужен: .cf или .cfu

Сначала решите, что именно вы передаёте. От этого зависит и способ сборки, и способ установки у получателя.

Когда выбирать .cfu:

• 📦 вы выпускаете релизы для нескольких баз или клиентов;
• 🔁 в базах получателей конфигурация стоит на поддержке вашей поставки;
• 📉 нужен компактный файл, в котором только изменения.

Когда хватит .cf:

• 🏢 база одна, и вы переносите доработки из копии в рабочую;
• 🧩 у получателя конфигурация снята с поддержки или сильно доработана;
• 🗂️ нужна резервная копия конфигурации без данных.

Подготовка конфигурации к созданию файла поставки и обновления

Перед сборкой проверьте четыре вещи.

1. Свойства «Поставщик» и «Версия»

Откройте свойства корня конфигурации (правый клик по корню дерева → «Свойства»). Заполните «Поставщик» и «Версия». Именно по этим полям платформа у получателя понимает, от кого обновление и на какую версию.

Версию пишут в формате из четырёх чисел: 1.0.3.15. Перед каждой сборкой увеличивайте номер. Если собрать файл с той же версией, что уже стоит у клиента, обновление либо не предложится, либо запутает историю релизов.

2. Архив прошлых релизов

Файл обновления строится как разница между текущей конфигурацией и полными .cf прошлых версий. Поэтому каждый выпущенный релиз сохраняйте отдельным .cf:

D:\Releases\MyConf\
  1.0.1.1\1Cv8.cf
  1.0.2.4\1Cv8.cf
  1.0.3.15\1Cv8.cf
  1.0.3.15\1Cv8.cfu

Потеряли .cf старой версии — клиенты на этой версии не смогут обновиться через ваш .cfu. Им придётся ставить полный файл поставки.

3. Правила поддержки

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

Для внутренней разработки обычно ставят «разрешены» на всё. Для тиражного продукта — запрещают правку ключевых модулей, чтобы обновления ложились без ручного объединения.

4. Проверка конфигурации

Запустите Конфигурация → Проверка конфигурации с проверкой логической целостности и поиском ссылок на несуществующие объекты. Ошибки в модулях лучше поймать до сборки, а не у клиента.

Способы получить файл конфигурации: сравнение

Отдельный случай — доработанная типовая. Здесь «файл обновления» обычно означает перенос своих правок из тестовой базы в рабочую. Для этого сохраняют .cf из тестовой базы и в рабочей выполняют Конфигурация → Сравнить, объединить с конфигурацией из файла. Только отмеченные объекты попадут в рабочую конфигурацию.

Пошаговая инструкция: создание файла обновления .cfu в Конфигураторе

Шаг 1. Откройте основную конфигурацию разработки

Запустите базу в режиме Конфигуратора и откройте дерево конфигурации (Конфигурация → Открыть конфигурацию). Если изменения ещё не сохранены, сохраните их.

Шаг 2. Поднимите версию

В свойствах корня конфигурации увеличьте «Версию», например с 1.0.2.4 на 1.0.3.15. Сохраните конфигурацию.

Шаг 3. Откройте окно создания файлов

Выберите Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления конфигурации. Откроется окно с двумя флажками: создание файла поставки и создание файла обновления.

Шаг 4. Укажите пути

• Файл поставки: D:\Releases\MyConf\1.0.3.15\1Cv8.cf.
• Файл обновления: D:\Releases\MyConf\1.0.3.15\1Cv8.cfu.

Полный .cf создавайте всегда, даже если клиентам отдаёте только .cfu. Он станет базой для следующего обновления.

Шаг 5. Добавьте прошлые дистрибутивы

В списке предыдущих версий для файла обновления добавьте .cf тех релизов, с которых разрешаете обновляться. Например, 1.0.1.1 и 1.0.2.4.

Чем больше версий в списке, тем больше файл, но тем меньше клиентов застрянет на старом релизе. Разумный вариант — последние 2–4 релиза.

Шаг 6. Соберите и проверьте

Нажмите «Выполнить». После сборки убедитесь, что в папке появились оба файла и .cfu не нулевого размера. Обычно он заметно меньше полного .cf.

Конфликты при обновлении и объединение изменений

Конфликт возникает у получателя, когда он менял те же объекты, что и вы. При обновлении через .cfu платформа сравнивает три конфигурации: старую поставщика, новую поставщика и текущую конфигурацию базы.

Что видит получатель:

1. Окно сравнения со списком изменённых объектов.
2. Объекты, где изменения есть с обеих сторон, помечены отдельно.
3. Для таких объектов выбирают режим: взять объект целиком из новой поставки или объединить с приоритетом одной из сторон.

Как уменьшить число конфликтов на стороне разработчика:

• 🧱 выносите клиентские доработки в расширения, а не в основную конфигурацию;
• 🔒 запрещайте правилами поддержки изменение модулей, которые часто меняете сами;
• 🧾 сопровождайте релиз списком изменённых объектов: администратору клиента проще проверить объединение.

Если конфигурация у получателя снята с поддержки, .cfu применить нельзя. Тогда используйте полный .cf и режим Сравнить, объединить с конфигурацией из файла. Снимать базу с поддержки ради одного обновления не стоит: потом каждый релиз придётся объединять вручную.

Проверка файла обновления перед выпуском

Не отправляйте .cfu клиентам, пока не проверите его сами. Схема простая:

1. Возьмите копию базы , где стоит прошлая версия, например 1.0.2.4. Подойдёт и пустая база, загруженная из архивного .cf этой версии.
2. В Конфигураторе: Конфигурация → Поддержка → Обновить конфигурацию, укажите новый .cfu.
3. Пройдите окно сравнения и нажмите «Выполнить».
4. Обновите конфигурацию базы данных: Конфигурация → Обновить конфигурацию базы данных (F7). Для изменения структуры обычно нужно, чтобы в базе никто не работал.
5. Запустите базу в пользовательском режиме и пройдите обработчики обновления, если они есть.
6. Сравните результат с эталоном: Конфигурация → Сравнить конфигурации, слева основная конфигурация, справа ваш полный .cf новой версии. Отличий быть не должно.

Повторите проверку для каждой версии из списка прошлых дистрибутивов. Ошибка в одной ветке обновления не видна при проверке другой.

Как передать файл получателю

Проверенный релиз передают одним архивом. Внутрь кладут:

• 📦 1Cv8.cfu — для баз на поддержке вашей поставки;
• 🗃️ 1Cv8.cf — для новых баз и для тех, где поддержка снята;
• 📝 текстовый файл с номером версии, списком версий, с которых можно обновиться, и перечнем изменений.

В имени архива указывайте номер версии: MyConf_1.0.3.15.zip. Так администратор клиента сразу видит, какой релиз у него на руках. Если клиент пропустил несколько релизов и его версии нет в списке, отправьте ему полный .cf или промежуточный .cfu из архива. Обновлять базу лучше последовательно, релиз за релизом, если в промежуточных версиях есть обработчики обновления данных.

Командная строка и 1С:EDT

Сборка из командной строки

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

@echo off
set V8="C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe"
set BASE=D:\Bases\MyConf_Dev
set OUT=D:\Releases\MyConf\1.0.3.15

%V8% DESIGNER /F "%BASE%" /N "Admin" /P "" ^
  /CreateDistributionFiles -cffile "%OUT%\1Cv8.cf" ^
  -cfufile "%OUT%\1Cv8.cfu" ^
  -f "D:\Releases\MyConf\1.0.2.4\1Cv8.cf" ^
  -f "D:\Releases\MyConf\1.0.1.1\1Cv8.cf" ^
  /DisableStartupDialogs /Out "%OUT%\build.log"

Что здесь важно:

• 📁 путь к 1cv8.exe укажите для своей версии платформы;
• 🔁 параметр -f повторяют для каждой прошлой версии;
• 📝 /Out пишет лог: при ошибке ищите причину в нём, окно Конфигуратора в пакетном режиме не откроется;
• 🔑 пароль в bat-файле лучше не хранить открыто: передавайте его из переменной окружения или используйте отдельного пользователя только для сборки.

Для клиент-серверной базы вместо /F указывают /S "сервер\имя_базы". Остальные параметры те же. Полный .cf без поставки выгружает команда /DumpCfg "путь\файл.cf".

Если разработка идёт в 1С:EDT

EDT работает с исходниками проекта, а файлы поставки — механизм платформы. Обычная схема такая:

1. Проект в EDT связан с информационной базой.
2. Перед релизом изменения из проекта загружаются в эту базу.
3. Файлы .cf и .cfu собирают из этой базы в Конфигураторе или командой /CreateDistributionFiles.

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

Ошибки при создании и установке файла обновления

Частые вопросы