Как правильно обновить Библиотеку стандартных подсистем (БСП) в нетиповой конфигурации с версии 2.3 до 3.1?

← На главную

При работе с платформой 1С:Предприятие 8.3 и разработкой нетиповых конфигураций, основанных на Библиотеке стандартных подсистем (БСП), мы часто сталкиваемся с необходимостью обновления БСП. Эта задача становится особенно сложной, когда требуется перейти с очень старых версий, таких как 2.3.2.76, на значительно более новые, например, 3.1.1.151. Мы рассмотрим подробный процесс такого обновления, основываясь на рекомендациях 1С и опыте разработчиков.

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

Ключевой документ: файл UpdateSSL.htm

При каждом обновлении БСП, независимо от того, насколько большой или маленький скачок в версиях вы планируете, нашим главным ориентиром будет файл UpdateSSL.htm. Этот файл находится в комплекте поставки БСП по пути /ExtFiles/Docs/UpdateSSL.htm. Он содержит подробные инструкции по переходу с предыдущих версий, включая:

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

Именно в этом файле мы найдем информацию о том, с какой минимальной версии возможен переход на текущий релиз, а также увидим критически важные примечания о последовательном выполнении инструкций.

Последовательность обновления: основные принципы

Обновление БСП с версии 2.3.2.76 до 3.1.1.151 — это значительный шаг, охватывающий несколько крупных редакций (2.3.x -> 2.4.x -> 3.0.x -> 3.1.x). Нам потребуется последовательный подход:

Создание резервной копии: Прежде чем начать любые действия, мы обязательно создаем полную резервную копию информационной базы и конфигурации. Это наша страховка на случай непредвиденных проблем и возможность отката к предыдущему состоянию.
Актуализация платформы: Убеждаемся, что версия платформы 1С:Предприятие 8.3 совместима с целевой версией БСП (3.1.1.151). Информацию о совместимости обычно указывают в документации к дистрибутиву БСП, а также на портале 1С:ИТС. При необходимости обновляем платформу до требуемой версии.
Последовательное обновление: Несмотря на кажущуюся трудоемкость, наиболее безопасный и рекомендуемый подход — это последовательное обновление БСП через все промежуточные версии. Это означает, что мы не можем просто "прыгнуть" с 2.3.2.76 сразу на 3.1.1.151. Нам необходимо пройти через следующие этапы: 2.3.2.76 -> 2.3.3.x -> 2.3.4.x -> ... -> 2.4.x -> ... -> 3.0.x -> ... -> 3.1.1.151. Каждая промежуточная версия может содержать критические изменения в структуре метаданных и данных.
Применение инструкций для каждой версии: Для каждой версии БСП, через которую мы проходим, необходимо:
1. Скачать соответствующий дистрибутив БСП с портала 1С:ИТС.
2. Выполнить сравнение и объединение конфигурации с конфигурацией поставщика БСП из этого дистрибутива. При этом мы внимательно анализируем предлагаемые изменения.
3. Самое важное: Тщательно изучить и последовательно выполнить все инструкции из файла UpdateSSL.htm для текущей версии, а также для всех "пропущенных" версий, если мы приняли решение о сравнении и объединении через несколько релизов (об этом подробнее ниже). Эти инструкции могут включать запуск специальных обработок, ручные настройки или проверки.
4. Запустить и выполнить все обработки обновления данных, предусмотренные для данной версии в UpdateSSL.htm. Эти обработки критически важны для корректной миграции данных под новую структуру.
Тестирование: После каждого значимого этапа обновления (например, после перехода на новую крупную редакцию: с 2.3 на 2.4, с 2.4 на 3.0, с 3.0 на 3.1) мы проводим тщательное тестирование основного функционала, чтобы убедиться в его корректной работе. Это помогает выявить проблемы на ранних этапах и локализовать их.

"Противоречие" в документации и его объяснение

Нередко пользователи сталкиваются с тем, что документация к БСП может указывать на возможность перехода, например, с версии 2.3.3 на 3.1.1, но при этом в том же файле UpdateSSL.htm будет требование "затем последовательно выполнить инструкции из всех разделов Переход с предыдущих версий для каждой пропущенной версии". На первый взгляд это может показаться противоречием.

Давайте разберем эту ситуацию, чтобы избежать недопонимания:

Возможность перехода (сравнение и объединение): Когда документация говорит, что возможен переход с версии X на версию Y, это обычно означает, что инструмент "Сравнение, объединение конфигураций" (доступный через меню "Конфигурация" -> "Сравнить, объединить с конфигурацией из файла...") в режиме сравнения с конфигурацией поставщика сможет корректно обработать изменения метаданных между этими версиями. То есть, вы сможете применить дистрибутив версии Y к вашей конфигурации, основанной на версии X, и получить актуальную структуру метаданных без критических ошибок на этапе слияния. Документация может указывать, что, например, с версии 2.3.3 возможен переход на 3.1.1. Это означает, что конфигурации этих версий "понимают" друг друга при сравнении.
Необходимость выполнения инструкций: Однако, процесс обновления — это не только изменение структуры метаданных. Он также включает в себя:
- Миграцию данных: изменение структуры таблиц в базе данных, перенос значений из старых реквизитов в новые, преобразование данных.
- Запуск фоновых заданий: активация и выполнение регламентных заданий, которые обновляют или дополняют данные.
- Изменение настроек системы: перенастройка параметров работы подсистем, которые могли измениться в новых версиях.
- Выполнение специальных обработок: запуск кода, который подготавливает базу данных или конфигурацию к работе с новым функционалом.
Все эти действия описываются в инструкциях раздела "Переход с предыдущих версий" файла UpdateSSL.htm. Если мы перескакиваем через несколько версий БСП при сравнении и объединении (например, с 2.3.2 сразу на 2.3.5, как в примере из форума, где упоминался переход с 2.3.2 сразу на 2.3.5), то нам обязательно нужно последовательно выполнить инструкции для 2.3.3, затем для 2.3.4, и только потом для 2.3.5. Невыполнение этих инструкций приведет к некорректной работе системы, ошибкам и потенциальной порче данных, даже если конфигурация успешно объединилась.

Таким образом, "противоречия" нет: сравнение и объединение конфигурации можно сделать с пропуском версий (если это указано в документации для конкретного перехода и платформа это позволяет), но выполнение инструкций по обновлению данных и логики из UpdateSSL.htm должно быть последовательным для каждой пропущенной версии. Если в файле UpdateSSL.htm для версии 3.1.1.151 указано, что возможен переход с 2.3.3, но при этом требуется последовательно выполнить инструкции для всех пропущенных версий, это именно то, что мы должны сделать.

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

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

Сравнение и объединение: При каждом шаге сравнения и объединения мы тщательно анализируем конфликты (используя информер по метаданным для визуализации структуры). Если объекты (например, формы, модули, справочники) были изменены в БСП и также доработаны в нашей конфигурации, мы принимаем решение:
- Принять изменения из БСП: Если наша доработка незначительна или легко переносится на новый код БСП, мы можем принять изменения поставщика, а затем повторно реализовать нашу доработку на новой основе.
- Объединить изменения: В более сложных случаях нам потребуется вручную объединять код и метаданные, аккуратно интегрируя наши доработки в новую версию объектов БСП. Это может потребовать значительных усилий по рефакторингу и адаптации кода, особенно при изменении внутренней логики БСП.
- Оставить наш вариант: Крайне редко, но иногда бывает, что наша доработка критична и абсолютно несовместима с новой логикой БСП. В этом случае мы можем оставить наш вариант объекта, но это влечет за собой необходимость постоянного контроля и поддержки этого объекта, а также отказ от нового функционала БСП, связанного с ним. Обычно этот подход не рекомендуется.
Перенос доработок: Часто приходится переносить наши доработки на новые версии типовых объектов БСП. Например, если форма справочника была доработана и в новой версии БСП она полностью переделана, нам придется заново реализовать наши доработки на новой форме. Это требует хорошего понимания как нашей доработки, так и изменений в БСП.
Последовательный подход: В нетиповых конфигурациях особенно важно придерживаться последовательного обновления. Это помогает минимизировать количество конфликтов на каждом шаге и упростить анализ изменений, так как объем изменений между соседними версиями обычно меньше, чем между сильно разнесенными.

Обновление пустой базы: что учитывать?

Вопрос об обновлении БСП в "пустой" базе (например, когда конфигурация только что написана и данных нет, но используется старая версия БСП как основа) также часто возникает. Может показаться, что раз нет данных, то и инструкции по их миграции не нужны. Однако это не совсем так:

Изменения метаданных: Инструкции из UpdateSSL.htm могут содержать не только обработки данных, но и указания на изменение структуры метаданных (например, добавление новых реквизитов, изменение типов, удаление объектов). Эти изменения необходимо применять независимо от наличия данных. Инструмент сравнения и объединения сам по себе не всегда вносит все необходимые изменения, которые могут требоваться после ручной обработки или выполнения процедур инициализации.
Инициализация системы: Некоторые инструкции могут касаться инициализации новых подсистем, настройки стандартных классификаторов, заполнения начальных данных, необходимых для работы БСП (например, ролей, прав доступа, служебных справочников). Эти шаги также критически важны для корректного функционирования, даже если база еще не использовалась для учета. Например, корректная инициализация подсистемы "Пользователи" или "Права доступа" БСП важна для будущего разграничения доступа — есть обработка анализа прав доступа и ролей БСП.
Будущие данные: Если вы планируете использовать базу в дальнейшем, то даже при отсутствии данных сейчас, правильное применение всех структурных и логических изменений из UpdateSSL.htm гарантирует корректную работу системы, когда данные появятся. Игнорирование этих шагов может привести к ошибкам при вводе данных или некорректной работе функционала в будущем.

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

Заключительные рекомендации

Процесс обновления БСП с версии 2.3.2.76 до 3.1.1.151 — это масштабная задача, требующая методичного и терпеливого подхода. Мы с вами определили ключевые шаги, которые помогут нам успешно справиться с этой задачей:

Всегда начинаем с резервной копии. Это аксиома для любых изменений в рабочей информационной базе.
Последовательно обновляем БСП, используя дистрибутивы каждой промежуточной версии. Мы не пытаемся "перескочить" через множество релизов при сравнении и объединении, если это не подтверждено документацией для конкретного, небольшого шага.
Тщательно изучаем и выполняем все инструкции из файла UpdateSSL.htm для КАЖДОЙ ПРОПУЩЕННОЙ ВЕРСИИ. Это критически важно для миграции данных и корректной работы логики системы, даже если сравнение и объединение можно было сделать "скачком".
Будьте готовы к ручной доработке и переносу изменений в нетиповых конфигурациях. Это неотъемлемая часть процесса, требующая глубокого анализа конфликтов и адаптации кода.
Не игнорируем инструкции даже для пустой базы. Структурные изменения и инициализация новых подсистем важны независимо от наличия данных.
Тестируем функционал после каждого значимого этапа обновления, чтобы оперативно выявлять и исправлять возможные проблемы.

Следуя этим рекомендациям, мы значительно снизим риски возникновения ошибок и обеспечим стабильную и корректную работу нашей конфигурации на актуальной версии БСП, сохраняя при этом все необходимые доработки.