Выпуск релиза конфигурации 1С: от хранилища до рабочих баз

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

Типичная ситуация: доработки месяц копились в хранилище, кто-то правил прямо в рабочей базе, а в пятницу вечером «надо обновить всех». Без порядка такой выпуск заканчивается откатом. Описанный цикл одинаково работает и для одной базы клиента, и для тиражного решения на десятки установок.

Подготовка к выпуску: что решить до начала разработки

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

📌 Что определить заранее:

• Состав релиза. Список задач, которые в него входят. Всё, что не успели, уезжает в следующий, а не «докручивается в последний день».
• Ветка поставки. Одна эталонная конфигурация, из которой собираются файлы. Не рабочая база клиента и не чья-то личная копия.
• Поставщик и имя. В свойствах корня конфигурации заполните Поставщик и Имя. По ним база-получатель понимает, что обновление «родное».
• Окно обновления. Когда пользователи не работают и сколько времени займёт реструктуризация. Для больших баз на SQL это может быть час и больше.
• Ответственный за выкладку. Один человек нажимает «Обновить» и отвечает за откат.

Контроль версий: хранилище конфигурации или Git

Главная задача на этом этапе — чтобы ни одно изменение не жило только в чьей-то базе. Варианта два.

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

Классика для команд, которые работают в Конфигураторе.

1. Подключитесь: Конфигурация → Хранилище конфигурации → Подключиться к хранилищу.
2. Перед правкой объект захватывают. Пока он захвачен, другие его не изменят.
3. После правки — Поместить изменения в хранилище с внятным комментарием: номер задачи и что сделано.
4. Перед сборкой релиза ставят метку на версию хранилища, например Релиз 1.4.3. По метке всегда можно вернуться к точному состоянию поставки.

EDT и Git

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

Тестирование: как поймать ошибки до выкладки

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

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

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

Инструменты

• 🔍 Конфигурация → Проверка конфигурации — синтаксис, ссылки на несуществующие объекты, неиспользуемые процедуры. Включайте проверку для всех режимов запуска: тонкий клиент, веб-клиент, сервер.
• 🤖 Vanessa Automation — сценарные тесты на языке Gherkin, которые кликают по формам как пользователь. Набор сценариев один раз пишется и гоняется на каждом релизе.
• 🧪 Модульные тесты (например, фреймворк Vanessa ADD) — проверяют расчётные процедуры без интерфейса.
• 📋 1С:АПК — автоматическая проверка на соответствие стандартам разработки.

Версионирование: как нумеровать релизы

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

Типовые конфигурации используют четыре числа, например 3.0.150.28. Для своих решений удобна та же схема:

Правила простые:

• номер только растёт, повторно один и тот же не используют;
• каждый выпущенный .cf сохраняют в архив с номером в имени файла;
• номер в свойстве Версия, метка в хранилище и запись в журнале изменений совпадают.

Журнал изменений

Ведите CHANGELOG в простом формате: версия, дата, что добавлено и исправлено. Пример записи:

## [1.4.3] - 2026-05-20
### Добавлено
- Отчёт «Остатки по ячейкам» с отбором по складу.
### Исправлено
- Задвоение строк при копировании заказа с услугами.
### Требует действий
- После обновления заполнить новую константу «Склад по умолчанию».

Раздел «Требует действий» — самый ценный для того, кто обновляет базу. Без него новые настройки остаются пустыми, и пользователи узнают об этом из ошибок.

Сборка релиза: файлы поставки .cf и .cfu

Сборку делают из эталонной конфигурации, обновлённой до метки релиза.

Пошагово

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

Комплект поставки для тиражных решений

Если решение ставят многим клиентам, удобнее комплект поставки с программой установки. Он раскладывает файлы в каталог шаблонов, обычно %APPDATA%\1C\1cv8\tmplts, и затем база создаётся из шаблона прямо в окне запуска. Описание комплекта (какие файлы, куда копировать) собирается в той же группе меню Поставка конфигурации.

Обновление рабочих баз: пошаговая инструкция

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

Ручное обновление через Конфигуратор

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

Параметры подключения для пакетного режима

Когда баз много, обновление запускают командной строкой. Основные параметры 1cv8.exe:

Пример для серверной базы — резервная копия, затем обновление конфигурации и структуры:

set V8="C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe"
set IB=/S"srv1c\trade" /N"Админ" /P"***" /UC"REL143"

%V8% DESIGNER %IB% /DisableStartupDialogs /DumpIB "D:\backup\trade_before_1.4.3.dt" /Out "D:\logs\dump.log"
%V8% DESIGNER %IB% /DisableStartupDialogs /UpdateCfg "D:\release\1.4.3.cfu" /UpdateDBCfg /Out "D:\logs\update.log"

Путь к 1cv8.exe подставьте под свою версию платформы. После каждого шага смотрите журнал из /Out: при ошибке объединения или реструктуризации там будет текст причины.

Запуск в режиме обновления

Изменение структуры — ещё не конец. В конфигурациях на БСП данные под новую версию переводят обработчики обновления, и они выполняются при первом запуске в режиме 1С:Предприятие. В пакетном режиме этот запуск делают так:

%V8% ENTERPRISE %IB% /DisableStartupDialogs /C"ЗапуститьОбновлениеИнформационнойБазы;ЗавершитьРаботуСистемы" /Out "D:\logs\handlers.log"

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

Типичные ошибки при выпуске релиза

• ❌ Собрали .cfu без всех прошлых версий. Клиент на версии 1.4.0 получает сообщение, что файл обновления не подходит к его конфигурации. Лечится пересборкой с нужным .cf в списке.
• ❌ Не подняли номер версии. Обработчики обновления, привязанные к новому номеру, не выполняются, новые поля остаются пустыми.
• ❌ Потеряли .cf прошлого релиза. Без него нельзя собрать обновление с этой версии. Достать его можно из хранилища по метке, если метку ставили.
• ❌ Сняли объекты с поддержки у клиента «чтобы быстро поправить». Следующий релиз придётся объединять вручную по каждому такому объекту.
• ❌ Не замерили время реструктуризации. На копии с урезанными данными обновление заняло 5 минут, на рабочей базе — 2 часа, а окно было до 9 утра.
• ❌ Обработчик обновления падает на реальных данных. Например, ожидает заполненный реквизит, который в старых документах пустой. Отсюда правило тестировать на полной копии.

Документация и обратная связь по релизу

Код без описания — половина релиза. Для каждого выпуска готовьте три вещи.

1. Журнал изменений для администратора: что поменялось и что сделать после обновления.
2. Инструкция для пользователей: короткая, с упором на новые кнопки и изменившиеся формы. Пользователю не нужен список исправленных процедур.
3. Канал обратной связи: куда писать об ошибках после выкладки и в какой срок ждать ответа.

Первые два-три дня после релиза держите в приоритете обращения по новой версии. Ошибки, найденные в это время, собирайте в исправительную сборку: 1.4.3 → 1.4.4, без нового функционала.

Частые вопросы о выпуске релизов