← На главную

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

Способ 1. Перенос изменений через файл конфигурации (.cf) и механизм сравнения/объединения

Этот способ часто применяют начинающие специалисты или разработчики, работающие в одиночку над небольшими проектами. Разберем по шагам правильный регламент переноса:

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

Важные нюансы и подводные камни сопоставления объектов:

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

1. Сравнение произвольных конфигураций: сопоставление выполняется преимущественно по имени объекта. Если имя реквизита или объекта было изменено в тестовой базе, механизм сравнения посчитает старый объект удаленным, а новый — добавленным. При бездумном объединении это приведет к потере данных старого реквизита. Если пару по имени найти не удалось, платформа пытается сопоставить по внутреннему уникальному идентификатору (UUID).
2. Сравнение родственных конфигураций (например, с конфигурацией базы данных или хранилища): сопоставление выполняется строго по внутренним идентификаторам, имя объекта роли не играет.
3. Сравнение с конфигурацией поставщика: выполняется сопоставление по внутренним идентификаторам с учетом правил поддержки.

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

Способ 2. Использование Хранилища конфигурации 1С

Использование встроенного механизма Хранилище конфигурации — это профессиональный стандарт командной и одиночной разработки в экосистеме 1С. Разберем ключевые преимущества этого инструмента:

1. Гарантия идентичности идентификаторов: все подключенные к хранилищу базы оперируют одинаковыми внутренними идентификаторами (UUID) метаданных, что исключает ошибки при реструктуризации, распределенных информационных базах (РИБ) и последующих обновлениях.
2. История версий и аудит: фиксируется автор каждого изменения, дата помещения и комментарий к коммиту. Всегда можно посмотреть, кто и когда изменил конкретную процедуру или реквизит.
3. Откат и сравнение версий: можно в любой момент сравнить текущее состояние объекта с любой исторической версией и при необходимости выполнить откат.
4. Простота доставки релиза: разработчик захватывает объекты в базе разработки, вносит изменения, тестирует и помещает их в хранилище. В рабочей базе достаточно выполнить команду Конфигурация — Хранилище конфигурации — Обновить конфигурацию из хранилища и нажать F7.

Способ 3. Использование расширений конфигурации (.cfe)

Если рабочая конфигурация является типовой (например, 1C:Бухгалтерия, 1С:Управление торговлей, 1С:ERP) и находится на официальной поддержке поставщика, рекомендуется реализовывать доработки с помощью механизма Расширения конфигурации.

Рассмотрим преимущества такого подхода:

1. Сохранение типовой поддержки: основная конфигурация остается на полной поддержке «замке», что делает регулярные обновления типовых релизов от вендора быстрыми и беспроблемными.
2. Изоляция доработок: новые отчеты, обработки, регистры и переопределенная логика процедур (через директивы &Вместо, &После, &Перед) хранятся в отдельном файле .cfe.
3. Обновление без простоя: если расширение не добавляет собственных таблиц в базу данных (не меняет структуру СУБД), его можно подключать и обновлять в режиме 1С:Предприятие без монопольного захвата базы и выгона пользователей.

Способ 4. Современная разработка через Git и 1C:Enterprise Development Tools (EDT)

В крупных проектах и распределенных командах применяется подход выгрузки конфигурации в исходный код (XML-структура и модули). Это позволяет использовать классическую систему контроля версий Git:

1. Разработка ведется в среде 1C:EDT или через выгрузку конфигурации в файлы с помощью стандартной платформы.
2. Используется версионирование по веткам (Feature Branch), проводятся обязательные перекрестные проверки кода (Code Review) через Pull Requests.
3. Сборка релизного файла .cf и доставка на тестовые и рабочие серверы автоматизируются через конвейеры непрерывной интеграции (CI/CD) с помощью пакетного запуска Конфигуратора через командную строку.

Правила безопасности при внесении изменений в рабочую базу

Проанализируем обязательные меры предосторожности перед релизом доработок в продуктивную среду:

1. Отказ от динамического обновления: обновление конфигурации базы данных «на лету» без перезапуска рабочих процессов часто приводит к рассинхронизации кэша метаданных на сервере и клиентах, повреждению таблиц и аварийному завершению сеансов пользователей. Всегда применяйте структурные изменения с плановым перезапуском сеансов.
2. Учет длительности реструктуризации: если доработка затрагивает типы данных существующих реквизитов больших таблиц или добавляет измерения в регистры с миллионами записей, операция вызовет физическую перестройку таблиц СУБД. Планируйте технологическое окно или используйте механизм фоновой реструктуризации таблиц информационной базы.
3. Блокировка сеансов: перед обновлением устанавливайте блокировку начала сеансов и завершайте фоновые задания, чтобы исключить дедлоки и повреждение транзакций во время фиксации метаданных.