Релиз в 1С: полный цикл от разработки до внедрения

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

В этой статье разберём весь цикл создания релиза — от фиксации задач в системе контроля версий до автоматизированного развертывания на сотнях рабочих мест. Акцент сделаем на практические шаги, которые экономят время и снижают риски. Например, почему ОбновлениеКонфигурацииБезопасно() не всегда безопасно, как правильно версионировать релизы для разных филиалов, и что делать, если обновление «зависло» на этапе ПриНачалеОбновленияИнформационнойБазы. Также приведём чек-листы для командной работы и примеры скриптов для автоматизации рутинных операций.

Материал будет полезен как начинающим 1С-разработчикам, так и опытным специалистам, которые хотят оптимизировать процесс выпуска обновлений. Все рекомендации основаны на стандартах 1С и лучших практиках команд, поддерживающих системы с тысячами пользователей.

1. Подготовка к релизу: что нужно сделать до написания кода

Начало работы над релизом — это не открытие конфигуратора, а анализ задач и планирование изменений. Хаотичные правки без документации приводят к тому, что через полгода никто не вспомнит, зачем был добавлен тот или иной обработчик или почему в одном из отчётов появился новый реквизит.

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

• 📌 Контекст: для каких пользователей (бухгалтерия, менеджеры, аналитики) и с какой целью нужен этот функционал.
• 📌 Источники данных: откуда брать информацию для нового поля (например, из регистра накопления или справочника).
• 📌 Формат вывода: нужно ли rounds до копеек, как обрабатывать отрицательные значения, требуется ли группировка.
• 📌 Сроки: когда изменения должны заработать на боевой базе (это влияет на приоритет задачи).

Все уточнённые детали фиксируйте в системе управления задачами (Jira, Redmine, YouTrack или даже в Excel). Пример структуры задачи:

Если в команде несколько разработчиков, обязательно согласуйте ветку разработки. Например, для задачи выше можно создать ветку feature/sales-report-vat. Это поможет избежать конфликтов при слиянии изменений.

2. Разработка и контроль версий: как не потерять изменения

Работать напрямую в основной конфигурации (Main или Master) — грубейшая ошибка. Любая неудачная правка может сломать работоспособность системы для всех пользователей. Вместо этого используйте систему контроля версий (Git, SVN или встроенную в 1С:EDT).

Алгоритм работы:

1. Создайте локальную копию репозитория и обновите её до актуальной версии.
2. Переключитесь на новую ветку для задачи (например, git checkout -b fix/invoice-print).
3. Внесите изменения в конфигураторе, сохраните их в файл .cf или .epf.
4. Закоммитьте изменения с осмысленным сообщением (например, «Исправлена ошибка печати счёта-фактуры при пустом ИНН контрагента»).
5. Протестируйте изменения локально (об этом подробнее в следующем разделе).
6. Слейте ветку в Main после утверждения тестировщиком.

Для командной работы полезно использовать pull requests (в GitHub/GitLab). Это позволяет:

• 🔍 Просматривать изменения до слияния (код-ревью).
• 💬 Обсуждать правки прямо в коде (например, попросить добавить комментарий к сложному алгоритму).
• 🤖 Автоматически запускать тесты перед мерджем.

Если вы работаете в 1С:EDT, то контроль версий встроен в среду. Для классического конфигуратора можно использовать внешние инструменты, например, Git с плагином OneScript или специализированные решения вроде 1C:VersionControl.

3. Тестирование: как найти ошибки до релиза

Тестирование — это не «попробовал сам, вроде работает». Это систематический процесс проверки всех изменений на соответствие требованиям и отсутствие регрессий (когда новое исправление ломает старую функциональность).

Минимальный набор тестов для релиза:

• 🧪 Функциональное тестирование: проверка новой логики по сценариям из задачи. Например, если добавили колонку «НДС» в отчёт, убедитесь, что она корректно рассчитывается для документов с разными ставками (0%, 10%, 20%).
• 🔄 Регрессионное тестирование: проверка, что старые функции работают как раньше. Например, после изменений в модуле документа «РеализацияТоваровУслуг» убедитесь, что печать счёта-фактуры и проводки не сломались.
• 🖥️ Кросс-платформенное тестирование: если у вас есть пользователи на Linux-серверах или в веб-клиенте, проверьте работу изменений в этих средах.
• 📊 Нагрузочное тестирование: для изменений, затрагивающих часто используемые отчёты или документы (например, «Акт сверки»), проверьте время выполнения на большой базе.

Для автоматизации тестов можно использовать:

• 🤖 1С:Тест-центр — встроенный инструмент для написания и запуска тестов.
• 🤖 vanessa-automation — фреймворк для автоматизированного тестирования 1С.
• 🤖 Скрипты на OneScript для проверки критичных операций (например, корректности проводок).

Пример простого теста на OneScript для проверки нового отчёта:

Перем ТЗ;
ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("Сумма");
ТЗ.Колонки.Добавить("НДС");

// Заполняем тестовыми данными
Строка = ТЗ.Добавить();
Строка.Сумма = 1000;
Строка.НДС = 20; // 20%

// Вызываем новый отчёт
Отчет = ПолучитьОтчет("ПродажиПоМенеджерам");
Отчет.Сформировать(ТЗ);

// Проверяем, что колонка НДС заполнена корректно
Если Отчет.Результат.Колонки.Найти("НДС") = Неопределено Тогда
ВыброситьИсключение("Колонка НДС не найдена в отчёте!");
КонецЕсли;

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

Создана резервная копия тестовой базы|Тестовые данные соответствуют реальным сценариям|Подготовлены скриншоты/логи "до изменений"|Проверены права доступа тестового пользователя-->

4. Версионирование и нумерация релизов

Хаотичная нумерация релизов вроде «версия от 15.05.2026» или «исправление для Ивана» приводит к путанице, особенно если у вас несколько филиалов или внешние интеграции. Используйте семантическое версионирование (Semantic Versioning), где номер версии имеет формат X.Y.Z:

• X — мажорная версия (крупные изменения, несовместимые с предыдущими релизами).
• Y — минорная версия (новый функционал, совместимый с предыдущими версиями).
• Z — патч (исправления ошибок).

Примеры:

• 📦 2.0.0 — выпущена новая подсистема «Управление проектами», требующая миграции данных.
• 📦 1.5.0 — добавлен новый отчёт «Анализ дебиторки», обратная совместимость сохранена.
• 📦 1.4.3 — исправлена ошибка с округлением в расчёте зарплаты.

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

Сообщить(Строка(Платформа.Версия()));

Для филиалов или разных типов клиентов (например, «Розница» и «Опт») можно использовать суффиксы:

• 🏢 1.4.3-retail — релиз для розничных магазинов.
• 🏭 1.4.3-factory — релиз для производственного подразделения.

Все изменения версии фиксируйте в файле CHANGELOG.md или в специальном разделе документации. Пример записи:

[1.4.3] - 2026-05-20
Исправлено
- Ошибка округления в расчёте НДФЛ для сотрудников с окладом > 100 000 руб.
- Падение при печати счёта-фактуры с пустым полем "Доп. информация".

Изменено
- Оптимизирован запрос в отчёте "Обороты по контрагентам" (ускорение на 30%).

5. Сборка и упаковка релиза

Когда код написан и протестирован, его нужно подготовить для распространения. В 1С есть несколько форматов релизов:

• 📦 .cf — файл конфигурации (полная выгрузка).
• 📦 .cfu — файл обновления (только изменения относительно предыдущей версии).
• 📦 .epf — внешняя обработка или отчёт (для распределения отдельных функций).
• 📦 .zip — архив с конфигурацией, документацией и скриптами обновления.

Для создания .cfu используйте меню Конфигуратор → Конфигурация → Сравнить, объединить с конфигурацией из файла. Алгоритм:

1. Откройте актуальную версию конфигурации (ту, которую будете обновлять).
2. Выберите файл с новой версией (ту, которую разрабатывали).
3. Нажмите «Создать файл обновления» и сохраните как .cfu.

Важно: файл обновления (.cfu) содержит только различия между версиями. Если пользователь пропустил промежуточные релизы, ему потребуется цепочка обновлений или полный .cf. Чтобы избежать проблем, можно:

• 🔗 Всегда предоставлять полный .cf для мажорных релизов.
• 🔗 Для минорных обновлений — только .cfu, но с указанием минимальной версии, с которой он совместим.

Пример структуры архива релиза:

Release_1.4.3.zip
├── Config
│   ├── MyConfig.cf   (полная конфигурация)
│   └── MyConfig.cfu  (обновление)
├── Docs
│   └── CHANGELOG.md  (список изменений)
├── Scripts
│   └── update.bat    (скрипт для автоматического обновления)
└── README.txt        (инструкция по установке)

Для автоматизации сборки можно использовать Jenkins, GitLab CI или даже простые батники. Пример скрипта для создания .cfu:

@echo off
set PREV_VERSION=1.4.2
set CUR_VERSION=1.4.3
set CF_PATH=C:\Releases\MyConfig.cf
set CFU_PATH=C:\Releases\Updates\MyConfig_%CUR_VERSION%.cfu

// Запускаем 1С в режиме конфигуратора с параметрами
"C:\Program Files\1cv8\8.3.20.1549\bin\1cv8.exe" DESIGNER /S"file='%CF_PATH%'" /NAdmin /P123 /Execute"СоздатьФайлОбновления("%PREV_VERSION%", "%CUR_VERSION%", "%CFU_PATH%")" /Out"C:\Releases\logs\update.log"

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

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

Пошаговая инструкция для ручного обновления:

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

Для автоматизации можно использовать скрипт на PowerShell:

Параметры подключения
$Server = "sr-v1c"
$BaseName = "MainBase"
$User = "Admin"
$Password = "P@ssw0rd"
$CFUPath = "C:\Releases\MyConfig_1.4.3.cfu"

Запуск 1С в режиме обновления
Start-Process -FilePath "C:\Program Files\1cv8\8.3.20.1549\bin\1cv8.exe" -
ArgumentList "DESIGNER /S`"$Server\$BaseName`" /N$User /P$Password /UpdateCf`"$CFUPath`" /OutC:\logs\update_$(Get-Date -Format 'yyyyMMdd').log"

Если обновление прервалось на этапе ПриНачалеОбновленияИнформационнойБазы, проверьте:

• 🔌 Достаточно ли места на диске (особенно если база большая).
• 🔒 Нет ли блокировок в SQL Server (для клиент-серверного варианта).
• 📜 Не конфликтуют ли изменения с локальными правками пользователей (если разрешены).

7. Типичные ошибки и как их избежать

Даже опытные разработчики сталкиваются с проблемами при выпуске релизов. Вот наиболее частые ошибки и способы их предотвращения:

• 🚨 Забыли про резервную копию.
  Последствия: при сбое во время обновления база может стать неработоспособной.
  Решение: настройте автоматический бэкап перед любым обновлением (например, через SQL Agent или 1С:Администрирование сервера).
• 🚨 Не проверили совместимость с версией платформы.
  Последствия: база не откроется с ошибкой «Несовместимая версия».
  Решение: всегда указывайте минимальную версию платформы в документации к релизу.
• 🚨 Игнорировали предупреждения при обновлении.
  Последствия: например, если не обратить внимание на сообщение «Объект 'Документ.ЗаказПокупателя' будет удалён», это приведёт к потере данных.
  Решение: внимательно читайте логи обновления (C:\Users\Public\1C\1Cv8\log\).
• 🚨 Не протестировали права доступа.
  Последствия: пользователи не увидят новый отчёт или не смогут сохранить документ.
  Решение: проверяйте роли на тестовой базе с правами обычного пользователя.

Критическая ошибка: обновление конфигурации без предварительного тестирования на копии рабочей базы. В 80% случаев это приводит к простоям из-за неучтённых особенностей данных (например, уникальных индексов или триггеров в SQL).

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

Выборка = РасширенияКонфигурации.Выбрать();
Пока Выборка.Следующий() Цикл
Сообщить(Выборка.Имя + " (Версия: " + Выборка.Версия + ")");
КонецЦикла;

Если после обновления пользователи жалуются на ошибки вроде «Не найден метод 'РассчитатьНДС'», скорее всего, проблема в несовпадении версий основной конфигурации и расширений.

8. Документирование и обратная связь

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

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

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

1. После обновления перезапустите 1С (закройте и откройте заново).
2. В меню "Отчёты" появится новый пункт "Анализ дебиторки по срокам".
3. Для корректной работы отчёта убедитесь, что у вас заполнены реквизиты:
- "Дата оплаты" в документах "Поступление на расчётный счёт"
- "Срок оплаты" в договорах с контрагентами

Для сбора обратной связи можно:

• 📧 Отправить анкету пользователям (например, через Google Forms).
• 💬 Организовать краткий опрос в корпоративном чате.
• 📊 Анализировать логи ошибок (папка %APPDATA%\1C\1Cv8\logs\).

Если обнаружены критичные ошибки, оперативно выпустите патч (например, версия 1.4.4 с исправлением падения при печати). Для некритичных замечаний заведите задачи в бэклог на следующий релиз.

Храните документацию вместе с файлами релиза (например, в той же папке на сетевом диске или в Confluence). Это упростит поддержку и обучение новых сотрудников.

FAQ: Частые вопросы о релизах в 1С

ras session -disconnect -all -force

Конфигурация: Управление торговлей (1.4.3)
Платформа: 8.3.20.1549
  

Сообщить(Конфигурация.Версия());