Разработка и Конфигурация · 12 мин
Как сделать релиз 1С: подробная инструкция для разработчика
Как подготовить и выпустить релиз конфигурации 1С: нумерация версий, поставка обновления, файл 1cv8.cfu, тестирование и типичные ошибки при выпуске.
Релиз конфигурации 1С — это зафиксированная версия прикладного решения, которую можно передать клиентам или установить на рабочие базы. В отличие от простого сохранения конфигурации, релиз оформляется в виде файлов поставки и обновления, содержит номер версии и историю изменений. Именно релиз позволяет обновлять базы пользователей штатными средствами, без ручного переноса объектов.
Процедура выпуска релиза одинакова по логике для большинства конфигураций на платформе «1С:Предприятие 8.3»: разработчик дорабатывает конфигурацию, присваивает номер версии, проверяет работоспособность, формирует файл поставки (CF) и файл обновления (CFU). Ошибки на любом из этапов приводят к тому, что обновление у клиента не устанавливается или устанавливается с потерей данных.
Материал рассчитан на разработчиков и внедренцев, которые дорабатывают типовую или собственную конфигурацию и хотят организовать правильный цикл выпуска версий. Рассмотрим подготовку, нумерацию, формирование файлов поставки, тестирование и типичные ошибки.
Что такое релиз и какие файлы в него входят
В терминологии 1С релиз — это поставка конфигурации определённой версии. Платформа различает два основных файла: CF (1cv8.cf) — полный файл конфигурации, который можно развернуть «с нуля» или загрузить целиком, и CFU (1cv8.cfu) — файл обновления, который содержит только изменения относительно предыдущих версий и применяется через режим «Обновление конфигураций».
Файл обновления строится от одной или нескольких предыдущих версий. Это принципиальный момент: если клиент пропустил несколько релизов, а вы сформировали CFU только от последней версии, обновление на его базу не встанет штатным путём. Поэтому при выпуске нужно знать, с каких версий ваши пользователи будут обновляться.
Подготовка конфигурации к выпуску
Перед выпуском релиза все доработки должны быть завершены и проверены. Откройте конфигуратор, загрузите актуальную конфигурацию из хранилища (если используется командная разработка) и выполните полную проверку: Конфигурация → Проверка конфигурации. Устраните все критичные ошибки — предупреждения допустимы, но ошибки компиляции модулей делают релиз неработоспособным.
Если конфигурация находится на поддержке и вы дорабатываете типовое решение, убедитесь, что изменения выполнены с соблюдением правил поддержки: объекты не сняты с поддержки без необходимости, иначе клиенты потеряют возможность штатного обновления типовой части. Для собственных конфигураций проверьте, что все добавленные объекты включены в подсистемы и права доступа.
Обязательно сделайте резервную копию рабочей базы разработки и зафиксируйте текущее состояние конфигурации — сохраните CF-файл предыдущего релиза в отдельный каталог версий. Он понадобится для формирования файла обновления и для отката, если новый релиз придётся отозвать.
Нумерация версий и свойства конфигурации
Номер версии задаётся в свойствах корневого узла конфигурации: правый клик по имени конфигурации → Свойства → Версия. Принята четырёхкомпонентная нумерация вида 1.2.3.4, где первые разряды означают редакцию и подредакцию, третий — номер релиза, четвёртый — номер обновления (патча). Например, переход с 2.1.5.10 на 2.1.5.11 означает исправление ошибок, а на 2.1.6.1 — выпуск нового функционального релиза.
Номер версии важен не только для учёта: механизм обновления сравнивает версии, и файл CFU применяется только к тем версиям, для которых он сформирован. Также номер версии отображается в информации о программе и используется в процедурах обновления информационной базы — подсистема обновления (в решениях на БСП) выполняет обработчики перехода именно по номеру версии.
Если в конфигурации есть обработчики обновления данных (перенос данных в новые реквизиты, заполнение новых регистров), проверьте, что они зарегистрированы на правильный номер версии. Обработчик, привязанный к несуществующей или неверной версии, просто не выполнится, и данные останутся в старом формате.
Формирование файлов поставки и обновления
Основная команда выпуска релиза находится в меню Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления конфигурации. В диалоге укажите каталог, куда будут сохранены файлы, и отметьте, какие файлы формировать: файл поставки (CF) и файл обновления (CFU).
Для формирования CFU нажмите кнопку выбора версий обновления и укажите CF-файлы предыдущих релизов, с которых клиенты будут обновляться. Платформа сравнит текущую конфигурацию с указанными версиями и включит в файл обновления только различия. Чем больше предыдущих версий указано, тем больше размер CFU, но тем шире охват клиентских баз.
Дополнительно через пункт Комплект поставки можно настроить состав поставки: включить демонстрационную базу, описание изменений, файлы справки. Для внутренних корпоративных релизов это обычно не требуется, достаточно CF и CFU.
- 1Завершите доработки и выполните полную проверку конфигурации (Конфигурация → Проверка конфигурации)
- 2Сделайте резервную копию базы разработки и сохраните CF предыдущего релиза
- 3Укажите новый номер версии в свойствах конфигурации
- 4Откройте Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления
- 5Укажите каталог поставки и предыдущие версии для файла обновления
- 6Сформируйте файлы и протестируйте обновление на копии рабочей базы
- 7Проверьте выполнение обработчиков обновления и корректность данных
- 8Передайте файлы клиентам с инструкцией по установке
Тестирование релиза перед рассылкой
Тестирование — обязательный этап, который нельзя пропускать даже при небольших изменениях. Создайте копию реальной рабочей базы (клиентской или максимально близкую к ней по объёму данных) и выполните на ней обновление сформированным CFU-файлом: Конфигурация → Поддержка → Обновить конфигурацию, выбрав файл обновления.
Обратите внимание на этап реструктуризации: если менялась структура метаданных (добавлены измерения регистров, изменены типы реквизитов), обновление базы данных может занять значительное время на больших объёмах. Зафиксируйте длительность — это важно для планирования обновления у клиента, особенно если база работает в круглосуточном режиме.
После обновления запустите базу в режиме предприятия и проверьте ключевые сценарии: проведение документов, формирование отчётов, выполнение регламентных заданий. Если используются обработчики обновления данных, убедитесь, что они отработали — в решениях на БСП ход обновления отображается в специальной форме, а ошибки записываются в журнал регистрации.
Как проверить результат
CFU применяется без ошибок, реструктуризация завершается успешно
Ошибка «файл не содержит обновления для данной версии» или сбой реструктуризации
В информации о программе отображается новый номер версии
Версия не изменилась — обновление не применилось
Все обработчики выполнены, данные перенесены в новую структуру
Обработчики пропущены или завершились с ошибками в журнале регистрации
Документы проводятся, отчёты формируются без ошибок
Ошибки компиляции, падение отчётов, недоступность новых функций
Особые сценарии и ограничения
Обновление через несколько версий
Если клиент пропустил несколько релизов, есть два пути: сформировать CFU с указанием всех промежуточных версий либо последовательно установить все пропущенные обновления. Первый вариант удобнее для клиента, но требует хранить CF-файлы всех выпущенных релизов. Второй надёжнее при сложных обработчиках обновления, которые рассчитаны на последовательный переход.
Релиз для базы на поддержке типовой конфигурации
Если клиентская база — типовая конфигурация с вашими доработками, простая рассылка CFU не подойдёт: обновление затронет и типовую часть. В этом случае доработки обычно оформляют в виде расширения конфигурации (файл CFE), которое накладывается поверх типовой без изменения режима поддержки. Расширения — предпочтительный способ передачи небольших доработок.
Автоматизация выпуска
В зрелых командах сборку релиза автоматизируют через пакетный режим конфигуратора: выгрузка конфигурации из хранилища, формирование файлов поставки и тестовое обновление выполняются скриптами. Это исключает человеческий фактор — например, забытый номер версии или не тот файл предыдущего релиза.
Сравнение вариантов поставки
Подходит для первоначального развёртывания и полной замены конфигурации. Ограничение: при загрузке целиком теряются отличия текущей базы, не применяется как обновление
Штатный способ обновления баз клиентов с предыдущих версий. Ограничение: работает только для версий, указанных при формировании
Лучший вариант для доработок типовых конфигураций без снятия с поддержки. Ограничение: не все изменения возможны через расширение (например, изменение структуры типовых объектов ограничено)
Типичные ошибки при выпуске релиза
Самая частая ошибка — формирование CFU не от тех версий. Если разработчик указал только предыдущий релиз, а часть клиентов обновляется с более раннего, они получат сообщение о невозможности обновления. Лечится хранением архива всех CF-файлов и формированием CFU от нескольких последних версий.
Вторая группа ошибок связана с данными: забытые обработчики обновления, неверный номер версии в обработчике, изменение типа реквизита без переноса данных. Такие дефекты проявляются уже у клиента и требуют экстренного патча. Третья типичная проблема — выпуск релиза без тестового обновления на копии с реальным объёмом данных, из-за чего реструктуризация в рабочей базе занимает часы вместо ожидаемых минут.
Что важно запомнить
Релиз 1С — это версия конфигурации, оформленная файлами поставки (CF) и обновления (CFU). Правильный цикл: проверка конфигурации, новый номер версии, формирование файлов с указанием предыдущих версий, обязательное тестовое обновление на копии базы, архивирование каждого релиза. Для доработок типовых конфигураций предпочтительны расширения.
Частые вопросы о выпуске релизов 1С
Чем отличается файл CF от CFU?
CF — полный файл конфигурации, из него можно создать новую базу или загрузить конфигурацию целиком. CFU — файл обновления, содержащий только изменения относительно указанных предыдущих версий; он применяется через «Обновить конфигурацию» и сохраняет данные базы.
Можно ли обновить базу, если клиент пропустил несколько релизов?
Да, если при формировании CFU были указаны все версии, с которых возможен переход, — тогда обновление ставится за один шаг. Альтернатива — последовательно установить все пропущенные обновления в порядке выпуска.
Что делать, если реструктуризация при обновлении зависает?
На больших базах реструктуризация может идти долго — это нормально при изменении структуры крупных таблиц. Если процесс явно завис (нет активности на диске и в СУБД часами), прервите обновление, восстановите базу из резервной копии и проанализируйте, какие изменения метаданных вызвали проблему. Никогда не обновляйте рабочую базу без свежей резервной копии.
Нужно ли снимать конфигурацию с поддержки для выпуска своего релиза?
Для собственной (нетиповой) конфигурации вопрос поддержки не стоит — вы сами являетесь поставщиком. Для доработок типовой конфигурации снимать её с поддержки нежелательно: используйте расширения или режим поддержки с изменениями, чтобы клиент мог обновлять типовую часть.
Как откатить неудачный релиз у клиента?
Штатного «отката» обновления в платформе нет. Восстановление выполняется из резервной копии базы, сделанной перед обновлением. Поэтому инструкция по установке релиза всегда должна начинаться с требования создать backup.
Можно ли собирать релиз автоматически, без ручных действий в конфигураторе?
Да, конфигуратор поддерживает пакетный режим запуска с параметрами командной строки: можно выгружать конфигурацию из хранилища, создавать файлы поставки и запускать тестовое обновление скриптами. Это стандартная практика для команд с регулярными выпусками.