Как развернуть релиз 1С: практическое руководство

Развертывание релиза 1С — это установка новой версии конфигурации поставщика в рабочую информационную базу. Процедура кажется простой, пока не возникает первая проблема: несовместимость версий платформы, повреждённые доработки или база, которая после обновления не запускается. Поэтому развертывание релиза — это всегда сценарий с подготовкой, резервной копией и проверкой результата, а не одна кнопка «Обновить».

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

Материал ориентирован на администраторов и внедренцев, работающих с конфигурациями на управляемых формах (УТ, ERP, БП, ЗУП) в клиент-серверном или файловом варианте. Для сервисов 1С:Фреш логика обновления другая — там релизы разворачивает поставщик облака.

Подготовка: что проверить до развертывания релиза

Первое действие — зафиксировать текущее состояние. Откройте «О программе» и запишите версию конфигурации, версию платформы и режим совместимости. Затем посмотрите в описании нового релиза (файл поставки или страница на портале 1С), с какой версии возможен переход: многие релизы обновляются только с определённых предыдущих версий, и пропуск промежуточных релизов приводит к ошибкам обновления данных.

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

Третье — оцените степень доработки конфигурации. Откройте «Конфигурация — Поддержка — Настройка поддержки»: если конфигурация снята с поддержки или включено «возможность изменения», типовое автоматическое обновление может затереть доработки. В этом случае потребуется сравнение и объединение с ручным контролем.

Резервная копия: обязательный шаг без исключений

Ни одно развертывание релиза не начинается без резервной копии. Для файловой базы минимальный вариант — выгрузка в dt через «Администрирование — Выгрузить информационную базу» в конфигураторе. Для клиент-серверной базы корректнее делать backup средствами СУБД (MS SQL, PostgreSQL), потому что выгрузка dt большой базы занимает часы и не всегда завершается успешно.

Проверьте копию на работоспособность: загрузите dt в пустую базу или восстановите backup на тестовом сервере. Резервная копия, которая не восстанавливается, равна её отсутствию. На практике именно эта проверка чаще всего пропускается — и именно она спасает, когда обновление ломает базу.

Дополнительно полезно сохранить копию конфигурации в cf-файл («Конфигурация — Сохранить конфигурацию в файл»). Это позволит быстро вернуть только конфигурацию без отката данных, если проблема обнаружится уже после обновления данных ИБ.

Способы развертывания релиза

Существует три основных пути, выбор зависит от статуса поддержки и источника дистрибутива.

Автоматическое обновление через поддержку

Для типовой конфигурации на полной поддержке: «Конфигурация — Поддержка — Обновить конфигурацию». Конфигуратор предложит поиск обновлений в сети (потребуется учётная запись портала 1С) или в указанном каталоге. Дальше процесс идёт автоматически: сравнение, объединение, обновление конфигурации базы данных.

Развертывание из дистрибутива (setup.exe)

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

Обновление из cf-файла поставки

Если есть файл поставки нового релиза (.cf), используйте «Конфигурация — Загрузить конфигурацию из файла» только для пустых или полностью типовых баз. Для рабочей базы с данными правильный путь — «Поддержка — Обновить конфигурацию — Выбор файла обновления» с указанием cf или cfu. Файл cfu предназначен именно для обновления и содержит только изменения.

Сравнение способов

Автообновление через поддержку

Быстрее всего для типовых конфигураций; требует действующей подписки и доступа к порталу

Дистрибутив (setup.exe)

Подходит при отсутствии интернета и для первичной установки; занимает больше времени на установку шаблонов

Файл cfu/cf

Гибкий вариант для ручного контроля и доработанных баз; требует понимания процедуры объединения

Развертывание релиза в доработанной конфигурации

Если конфигурация изменена, автоматическое обновление недопустимо: оно либо откажется работать, либо затрёт доработки. Используйте режим «Обновить конфигурацию» с выбором файла поставки — конфигуратор откроет окно сравнения и объединения.

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

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

Обновление данных информационной базы

После обновления конфигурации базы данных первый запуск в режиме предприятия запускает обработчики обновления данных. Они выполняются монопольно: пользователи в это время работать не могут. Для клиент-серверных баз рекомендуется сначала запустить отложенные обработчики в фоне и контролировать их через «Результаты обновления программы».

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

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

Тестирование на копии перед боевым развертыванием

Для критичных баз (ERP, ЗУП с большой численностью, базы с интеграциями) релиз сначала разворачивают на копии. Восстановите backup на тестовом сервере или загрузите dt в отдельную файловую базу, отключите регламентные задания и обмены — иначе тестовая копия начнёт слать реальные данные во внешние системы.

На копии прогоните минимальный чек-лист: проведение ключевых документов, формирование регламентированной отчётности, работа обменов (в тестовом режиме), печать основных форм. Только после успешного теста планируйте обновление рабочей базы.

Контрольные точки

Как проверить результат

Версия в «О программе»

Норма

Соответствует развёрнутому релизу

Тревожный признак

Старая версия — обновление конфигурации БД не выполнялось

Результаты обновления программы

Норма

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

Тревожный признак

Есть обработчики с ошибками или в статусе «выполняется» часами

Проведение типовых документов

Норма

Документы проводятся без ошибок

Тревожный признак

Ошибки модулей, не найдены процедуры — конфликт доработок с релизом

Журнал регистрации

Норма

Нет массовых ошибок после запуска

Тревожный признак

Повторяющиеся ошибки фоновых заданий и обменов

Откат при неудачном развертывании

Если после развертывания релиза база неработоспособна, не пытайтесь «дочинить» её повторными обновлениями. Корректный путь — восстановить резервную копию и вернуть пользователей к работе, а разбор причин вести на копии. Для клиент-серверной базы это восстановление backup средствами СУБД, для файловой — загрузка dt или возврат файла 1Cv8.1CD.

Если откат невозможен (копия не делалась или повреждена), варианты ограничены: восстановление из теневых копий диска, обращение к средствам восстановления СУБД. Именно поэтому резервная копия — не формальность, а единственная страховка.

Часто задаваемые вопросы

Можно ли обновиться сразу через несколько релизов?

Зависит от конкретной конфигурации. Большинство типовых релизов допускают переход только с определённых предыдущих версий — список указан в описании релиза на портале 1С. Если ваша версия старше минимально допустимой, придётся последовательно ставить промежуточные релизы.

Чем отличается файл cf от cfu?

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

Пользователи не выходят из базы, как запустить обновление?

Установите блокировку сеансов: в файловом варианте — через «Администрирование — Блокировка установки соединений», в клиент-серверном — через консоль кластера (свойства информационной базы). Активные сеансы завершите принудительно, предупредив пользователей заранее.

Обновление данных идёт уже несколько часов — это нормально?

Для больших баз (сотни гигабайт) длительное обновление — обычная ситуация, особенно если релиз меняет структуру регистров или пересчитывает итоги. Проверьте журнал регистрации и нагрузку на СУБД: если процесс активен, прерывать его нельзя. Ориентировочное время лучше оценивать заранее на тестовой копии.

Нужно ли обновлять платформу вместе с релизом конфигурации?

Только если новый релиз требует более свежую версию платформы, чем установлена. Требование указано в описании релиза. Обновлять платформу «про запас» не стоит: смена версии платформы — отдельная процедура со своими рисками и тоже требует тестирования.

Как не потерять доработки при обновлении?

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