Файл обновления .cfu для своей конфигурации: сборка, проверка, выпуск

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

Частое заблуждение — считать, что обновление это просто выгрузка .cf новой версии. Файл .cf у клиента заменит конфигурацию целиком и может снять её с поддержки. А .cfu знает, с каких версий он обновляет, и аккуратно сливает изменения поставщика с доработками клиента.

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

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

1. 🔢 Номер версии. Откройте свойства корня конфигурации (правый клик по корню дерева → Свойства) и увеличьте поле Версия. Формат обычно четырёхчастный: 1.0.3.7. Если номер не изменить, клиент получит «обновление» на ту же версию и платформа его не примет.
2. 🏷️ Поставщик и имя. Поля Поставщик и Имя в тех же свойствах должны совпадать с прошлыми выпусками. Сменили имя — для клиентских баз это уже другая конфигурация.
3. 🗂️ Архив прошлых поставок. Нужны файлы .cf каждой версии, с которой клиенты будут обновляться. Без них .cfu собрать не получится: платформе не с чем сравнивать.
4. 🔍 Список изменений. Сравните текущую конфигурацию с прошлой поставкой: Конфигурация → Сравнить конфигурации, слева — файл .cf прошлой версии, справа — основная конфигурация. Отчёт о сравнении пригодится для документации и тестов.
5. 💾 Копия базы разработки. Администрирование → Выгрузить информационную базу в файл .dt. Это страховка на случай, если при настройке поставки что-то пойдёт не так.

Ручная сборка или пакетный режим

Обновление можно собрать мышкой в Конфигураторе или командой из скрипта. Результат одинаковый, разница — в повторяемости.

Начинать стоит с ручной сборки. Когда процедура станет привычной — переносите её в скрипт без изменений.

Как создать обновление конфигурации в Конфигураторе

Ниже — полный цикл для конфигурации собственной разработки на платформе 8.3.

Шаг 1. Настройка поставки

Откройте Конфигурация → Поставка конфигурации → Настройка поставки. Здесь для объектов задают правила поставки:

• ✅ Изменения разрешены — клиент может дорабатывать объект без снятия с поддержки;
• ⚠️ Изменения не рекомендуются — доработать можно, но клиент получит предупреждение;
• ⛔ Изменения запрещены — объект закрыт для правки у клиента.

Настройка делается один раз и потом только дополняется для новых объектов. Слишком жёсткие запреты заставят клиентов снимать конфигурацию с поддержки — после этого ваши .cfu им уже не подойдут.

Шаг 2. Создание файлов поставки и обновления

1. Сохраните конфигурацию и запустите Конфигурация → Проверка конфигурации. Ошибки синтаксиса лучше поймать сейчас, а не у клиента после установки.
2. Откройте Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления.
3. Отметьте флажок создания файла поставки и укажите путь для .cf новой версии. Этот файл пойдёт в архив и станет базой для следующего обновления.
4. Отметьте флажок создания файла обновления и укажите путь для .cfu.
5. В списке поставок, для которых создаётся обновление, добавьте .cf всех прошлых версий, с которых клиент может прийти. Например, 1.0.3.5 и 1.0.3.6.
6. Нажмите Выполнить и дождитесь сообщения о завершении.

Если в списке нет ни одной прошлой поставки, получится только .cf. Это нормальная ситуация для первого выпуска.

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

Шаг 3. Сколько прошлых версий включать

Каждая добавленная версия увеличивает размер .cfu. Практичный подход:

• включать последние 2–3 версии, с которых реально обновляются клиенты;
• для отстающих клиентов выпускать цепочку: сначала до промежуточной версии, потом до текущей;
• в описании выпуска прямо писать, с каких версий обновление ставится.

Шаг 4. Обработчики обновления данных

Сам .cfu меняет только структуру и код. Если в новой версии нужно заполнить новый реквизит, перенести данные или пересчитать регистр — нужен обработчик обновления.

В конфигурациях на Библиотеке стандартных подсистем (БСП) обработчики регистрируют в общем модуле обновления информационной базы, в процедуре ПриДобавленииОбработчиковОбновления:

Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт

	Обработчик = Обработчики.Добавить();
	Обработчик.Версия = "1.0.3.7";
	Обработчик.Процедура = "Справочники.Договоры.ЗаполнитьВидДоговора";
	Обработчик.РежимВыполнения = "Монопольно";

КонецПроцедуры

Процедура выполнится один раз — при первом запуске базы после обновления до версии 1.0.3.7. Номер в Обработчик.Версия должен совпадать с номером в свойствах конфигурации, иначе обработчик не сработает или сработает не в той версии.

Без БСП механизма обработчиков нет. Тогда обновление данных пишут сами: сравнивают сохранённый в константе номер версии с Метаданные.Версия при запуске и выполняют нужные процедуры.

Проверка обновления на копии рабочей базы

Обновление тестируют не на базе разработки, а на копии реальной клиентской базы. Только там видны доработки клиента и реальный объём данных.

Порядок проверки:

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

Фиксация версии и документирование изменений

Выпущенное обновление нельзя потом «тихо» поправить: у части клиентов оно уже стоит. Поэтому версию фиксируют сразу после сборки.

В хранилище конфигурации

Если разработка ведётся через хранилище, после сборки поставьте метку на версию хранилища с номером выпуска. Окно истории хранилища открывается из Конфигурация → Хранилище конфигурации → История хранилища. По метке потом легко поднять исходники любого выпуска.

Если хранилища нет, минимум — сохранить .cf поставки в архив выпусков. Это и есть ваша точка отката.

Описание выпуска

Короткий документ к каждому .cfu экономит часы поддержки. В нём должно быть:

• 📌 номер версии и дата выпуска;
• 📌 с каких версий ставится обновление;
• 📌 минимальный номер платформы, если вы меняли режим совместимости;
• 📌 список изменений по разделам: новое, исправлено, изменено поведение;
• 📌 какие объекты менялись — чтобы клиент с доработками знал, где ждать конфликтов;
• 📌 что делают обработчики обновления и сколько они могут идти.

Установка обновления в рабочую базу

Когда тест на копии пройден, переходите к рабочей базе. Делайте это в согласованное окно, когда пользователи не работают.

1. Предупредите пользователей. Обновление структуры базы требует монопольного доступа — все сеансы будут завершены.
2. Сделайте резервную копию рабочей базы — выгрузку в .dt или бэкап средствами СУБД для клиент-серверного варианта.
3. Установите блокировку начала сеансов. В клиент-серверной базе — в свойствах информационной базы в консоли кластера; в конфигурациях на БСП — через раздел Администрирование в режиме «1С:Предприятие».
4. Откройте Конфигуратор, выполните Конфигурация → Поддержка → Обновить конфигурацию и выберите .cfu.
5. Разберите объединение так же, как на копии. Решения уже известны по тесту.
6. Выполните Обновить конфигурацию базы данных и примите изменения структуры.
7. Запустите базу в режиме «1С:Предприятие» под администратором, дождитесь обработчиков.
8. Снимите блокировку сеансов и проверьте пару типовых операций с пользователем.

Автоматизация сборки обновлений

Сборку .cfu можно запускать без открытия Конфигуратора — ключом пакетного режима /CreateDistributionFiles. Пример .bat-файла для файловой базы разработки:

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

mkdir %OUT%

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

Что здесь происходит:

• -cffile — путь для нового файла поставки;
• -cfufile — путь для файла обновления;
• каждый -f добавляет прошлую поставку, с которой будет работать обновление;
• /Out пишет лог — проверяйте его после каждой сборки.

Путь к 1cv8.exe замените на свою версию платформы. Для клиент-серверной базы разработки вместо /F используют /S"сервер\база".

Следующие шаги автоматизации:

• 🤖 загрузка свежей версии из хранилища перед сборкой (/ConfigurationRepositoryUpdateCfg с параметрами хранилища);
• 🤖 тестовое обновление копии базы в пакетном режиме ключами /UpdateCfg и /UpdateDBCfg;
• 🤖 запуск автотестов (например, Vanessa Automation) на обновлённой копии;
• 🤖 выкладка .cfu и описания в общую папку или на сервер обновлений.

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

Ещё две ошибки встречаются у разработчиков постоянно:

• ❌ Потерянный .cf прошлой версии. Восстановить его можно только выгрузкой конфигурации из клиентской базы той же версии, где она стоит без доработок. Дешевле хранить архив.
• ❌ Смена режима совместимости без предупреждения. Клиенты на старой платформе не смогут обновиться. Минимальный номер платформы пишите в описании выпуска.

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