К статье
Практический материал

Разработка и Конфигурация · 11 мин

1С: как подключить хранилище расширений конфигурации

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

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

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

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

Что такое хранилище расширений и когда оно нужно

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

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

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

Требования и подготовка перед подключением

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

В-третьих, подготовьте каталог под хранилище. Для командной работы это должен быть сетевой ресурс, доступный всем разработчикам по одному и тому же пути — либо единый UNC-путь вида \\server\share, либо одинаково подключенный сетевой диск. Разные пути у разных разработчиков — частая причина проблем с подключением.

В-четвертых, решите, в какой базе будет вестись разработка. Рекомендуемая схема — отдельная копия базы для разработки, чтобы экспериментальные версии расширения не попадали в рабочую среду до завершения тестирования.

Как создать хранилище расширения

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

Далее выделите расширение в списке и перейдите в меню «Расширение конфигурации — Хранилище расширения — Создать хранилище». В диалоге укажите путь к пустому каталогу и задайте параметры администратора хранилища: имя пользователя и пароль. Это учётная запись именно хранилища, она не связана с пользователями информационной базы.

Порядок создания хранилища
  1. 1
    Откройте базу в конфигураторе и перейдите в «Конфигурация — Расширения конфигурации»
  2. 2
    Создайте расширение или выделите существующее
  3. 3
    Откройте «Расширение конфигурации — Хранилище расширения — Создать хранилище»
  4. 4
    Укажите пустой каталог на сетевом ресурсе
  5. 5
    Задайте имя и пароль администратора хранилища
  6. 6
    Дождитесь сообщения об успешном создании и проверьте статус подключения

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

Как подключиться к существующему хранилищу

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

Затем выполните «Расширение конфигурации — Хранилище расширения — Подключиться к хранилищу». Укажите тот же путь к каталогу хранилища, что использовал коллега, и введите свои учётные данные пользователя хранилища. Если учётной записи ещё нет, администратор хранилища должен завести её заранее через пункт управления пользователями хранилища.

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

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

Как проверить результат подключения

Статус расширения в списке
Норма

Расширение подключено к хранилищу, признак подключения отображается

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

Пункты меню хранилища неактивны или статус пустой

Получение версии из хранилища
Норма

Версия получается без ошибок, объекты появляются в дереве

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

Ошибка доступа к каталогу или неверные учётные данные

Захват объекта
Норма

Объект захватывается, у коллег он становится недоступен для захвата

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

Захват не выполняется или объект свободен у всех

Ежедневная работа: захват, изменение и помещение версий

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

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

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

Настройка прав и пользователей хранилища

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

Администратор хранилища дополнительно может снимать чужие захваты объектов. Это нужно, когда разработчик ушёл в отпуск или уволился, оставив захваченные объекты. Используйте эту возможность аккуратно: снятие захвата без согласования может привести к потере несохранённых правок коллеги.

Типичные ошибки и способы их устранения

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

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

Типичные ошибки
01
Работа всех разработчиков под одной учётной записью хранилища — история изменений теряет смысл, автора версии установить нельзя
02
Разные пути к хранилищу у разных разработчиков (буква диска против UNC) — периодические ошибки подключения
03
Долгая работа без получения изменений коллег — накопленные расхождения и конфликты при помещении
04
Забытые захваты объектов — блокировка работы команды, нужно вмешательство администратора
05
Разработка напрямую в рабочей базе — риск доставить непроверенные изменения пользователям

Альтернативы хранилищу расширений

Хранилище расширений — не единственный способ организовать версионирование. Распространённая альтернатива — выгрузка расширения в файлы конфигурации (XML) и хранение их в Git. Этот подход даёт ветвление, слияние и интеграцию с привычными инструментами код-ревью, но требует дисциплины и настройки процесса выгрузки-загрузки.

Для одиночной разработки достаточно файловых копий расширения в формате *.cfe с датами в имени. Выбор зависит от размера команды и требований к процессу: встроенное хранилище проще в старте, Git гибче в долгосрочной перспективе.

Сравнение вариантов

Встроенное хранилище расширений

Подходит команде 1С-разработчиков без инфраструктуры Git; захват объектов встроен в конфигуратор. Ограничение — нет ветвления и удобного код-ревью

Git + выгрузка в файлы конфигурации

Подходит зрелым командам с практиками code review и CI. Требует настройки процесса выгрузки и дисциплины

Файловые копии *.cfe

Подходит одиночному разработчику с редкими изменениями. Нет истории и защиты от потери промежуточных версий

Итог

Что важно запомнить

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

Частые вопросы

Можно ли подключить одно хранилище расширений к нескольким базам?

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

Что делать, если забыт пароль администратора хранилища?

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

Работает ли хранилище расширений в клиент-серверном варианте?

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

Можно ли отключить расширение от хранилища без потери изменений?

Да, отключение от хранилища не удаляет само расширение и его объекты из базы — теряется только связь с версиями. Рекомендуется перед отключением поместить все захваченные объекты в хранилище, чтобы последние правки сохранились в истории.

Чем отличается хранилище расширения от хранилища основной конфигурации?

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

Можно ли посмотреть, кто и когда изменил объект расширения?

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