Разработка и Конфигурация · 10 мин
Как создать хранилище расширения конфигурации в 1С
Как создать хранилище расширения конфигурации в 1С: пошаговая инструкция, требования к версии платформы, подключение разработчиков, настройка прав и типичные ошибки.
Хранилище расширения конфигурации в 1С — это механизм командной разработки, который позволяет нескольким разработчикам одновременно работать над одним расширением, контролировать версии объектов и отслеживать историю изменений. По сути, это тот же подход, что и у классического хранилища конфигурации, но применённый к расширению, которое дорабатывает типовую конфигурацию без её изменения.
Механизм хранилища расширений появился в платформе 1С:Предприятие 8.3.11, поэтому перед началом работы нужно убедиться, что на всех машинах разработчиков установлена платформа не ниже этой версии. Если хотя бы один участник команды работает на более старой платформе, подключиться к хранилищу он не сможет, и совместная разработка окажется невозможной.
Ниже разобран полный цикл: от создания хранилища и подключения расширения до настройки прав пользователей, типичных ошибок и проверки результата. Материал ориентирован на разработчиков и администраторов 1С, которые впервые настраивают командную работу с расширениями.
Когда хранилище расширения действительно нужно
Если над расширением работает один разработчик, хранилище не обязательно: достаточно регулярно выгружать расширение в файлы или сохранять его копию в файл *.cfe. Хранилище становится необходимым, когда в разработке участвуют двое и более специалистов и возникает риск, что они одновременно изменят один и тот же объект.
Основные сценарии, где хранилище оправдано: параллельная доработка форм и модулей разными разработчиками, необходимость отката к предыдущей версии расширения, ведение истории изменений для аудита и интеграция с процессами сборки и тестирования. Также хранилище удобно, когда расширение развивается долго и нужно понимать, кто, когда и зачем менял конкретный объект.
Требования и подготовка перед созданием
Перед созданием хранилища проверьте версию платформы: механизм поддерживается начиная с 1С:Предприятие 8.3.11. Узнать версию можно через «Справка → О программе» в конфигураторе. Если платформа старше, сначала обновите её на всех рабочих местах разработчиков.
Подготовьте каталог для хранилища. Это должен быть пустой каталог, доступный всем разработчикам — обычно сетевая папка на файловом сервере. Учтите, что файловый режим хранилища чувствителен к качеству сети: при нестабильном соединении возможны ошибки блокировки файлов. Для надёжности каталог следует включить в план резервного копирования.
Также убедитесь, что у вас есть права администратора в информационной базе, где развёрнуто расширение, и что само расширение создано и открывается в конфигураторе без ошибок. Хранилище создаётся именно из окна расширения, а не из основной конфигурации.
Создание хранилища расширения: пошаговая инструкция
Процедура выполняется в конфигураторе и занимает несколько минут. Важно выполнять действия именно в окне расширения, иначе вы создадите хранилище основной конфигурации.
- 1Откройте конфигуратор и перейдите в «Конфигурация → Расширения конфигурации»
- 2Откройте нужное расширение двойным щелчком — появится отдельное окно с деревом объектов расширения
- 3В окне расширения выберите «Конфигурация → Хранилище конфигурации → Создать хранилище»
- 4Укажите путь к пустому каталогу хранилища и подтвердите создание
- 5Задайте имя и пароль пользователя с правами администратора хранилища
- 6Дождитесь сообщения об успешном создании и поместите начальную версию объектов в хранилище
После создания хранилища платформа предложит поместить в него текущую версию объектов расширения. Согласитесь — так в истории появится первая версия, от которой будет вестись дальнейший учёт изменений. Если этого не сделать, объекты останутся незахваченными и история начнётся с пустого состояния.
Проверьте результат: в статусной строке окна расширения должен отображаться путь к хранилищу, а при открытии меню «Хранилище конфигурации» должны быть доступны команды захвата и помещения объектов. Это признак того, что расширение успешно подключено к хранилищу.
Подключение разработчиков и настройка пользователей
Каждый участник команды подключается к хранилищу со своего компьютера. Для этого в окне расширения выбирается «Конфигурация → Хранилище конфигурации → Подключиться к хранилищу», указывается путь к каталогу хранилища и учётные данные пользователя хранилища.
Пользователи хранилища — это отдельная система учётных записей, не связанная с пользователями информационной базы. Администратор хранилища создаёт их через «Администрирование → Пользователи хранилища». Каждому разработчику заводится своё имя — это критично для корректной истории изменений и блокировок объектов.
Права в хранилище расширения распределяются просто: администратор может управлять пользователями, версиями и настройками, обычные разработчики — захватывать и помещать объекты. Не выдавайте права администратора всем участникам: случайное изменение настроек или удаление версий может нарушить работу всей команды.
Организация повседневной работы с хранилищем
Базовый цикл работы разработчика выглядит так: захватить нужные объекты в хранилище, изменить их локально, протестировать в своей базе, затем поместить изменения обратно с комментарием. Пока объект захвачен одним разработчиком, другие не смогут его изменить — это и есть защита от конфликтов.
Комментарии при помещении объектов стоит писать содержательно: что изменено и по какой задаче. Через несколько месяцев именно комментарии позволят понять, зачем вносилась правка, и найти версию, к которой нужно откатиться. Практика «пустых» комментариев быстро обесценивает историю хранилища.
Периодически выполняйте получение изменений из хранилища, чтобы локальная копия расширения не расходилась с актуальной версией. Чем дольше разработчик работает без обновления, тем выше вероятность конфликтов при помещении своих изменений.
Удобно договориться в команде о правиле: захватывать только те объекты, которые реально правятся прямо сейчас, и помещать их обратно в течение дня. Долго удерживаемые захваты — главная причина простоев коллег, ожидающих освобождения объекта.
Типичные ошибки и ограничения механизма
Самая частая ошибка — попытка создать хранилище из окна основной конфигурации. В этом случае создаётся хранилище конфигурации, а не расширения, и команда начинает работать не с тем объектом. Всегда проверяйте заголовок активного окна перед созданием хранилища.
Вторая группа проблем связана с инфраструктурой: размещение хранилища на медленном или нестабильном сетевом ресурсе, отсутствие резервного копирования, разные версии платформы у участников. Всё это приводит к ошибкам доступа, повреждению данных хранилища или невозможности подключения.
Учитывайте и ограничение механизма: хранилище расширения управляет версиями самого расширения, но не связано с хранилищем основной конфигурации. Если типовая конфигурация обновляется, совместимость расширения нужно проверять отдельно — хранилище эту задачу не решает.
Проверка результата и обслуживание хранилища
После настройки убедитесь, что механизм работает: захватите тестовый объект под одним пользователем, попробуйте захватить его же под другим — платформа должна отказать с сообщением о блокировке. Затем поместите объект и проверьте, что в истории хранилища появилась новая версия с вашим комментарием.
Для обслуживания хранилища достаточно двух регулярных действий: резервное копирование каталога и периодическая проверка списка пользователей. Уволенных сотрудников из хранилища следует отключать, а перед этим — снимать их захваты с объектов, иначе объекты останутся заблокированными.
Как проверить, что хранилище работает
Отображается путь к хранилищу
Путь отсутствует — расширение не подключено
Платформа выдаёт сообщение о блокировке
Объект захватывается — пользователи работают под одной учётной записью
Новая версия с автором и комментарием
Версия не появляется — помещение не выполнено
Частые вопросы
Можно ли создать хранилище расширения на платформе 8.3.10?
Нет. Механизм хранилищ расширений конфигурации поддерживается начиная с платформы 1С:Предприятие 8.3.11. На более ранних версиях командная разработка расширений через хранилище недоступна — потребуется обновление платформы на всех рабочих местах команды.
Чем хранилище расширения отличается от хранилища конфигурации?
Технически механизм один и тот же, различается объект версионирования: хранилище конфигурации управляет основной конфигурацией базы, а хранилище расширения — только объектами конкретного расширения. У одной базы может быть хранилище конфигурации и несколько независимых хранилищ расширений.
Что делать, если разработчик ушёл, не сняв захват с объектов?
Администратор хранилища может принудительно отменить захват объектов этого пользователя через администрирование хранилища. Локальные изменения ушедшего разработчика при этом не попадут в хранилище — их нужно будет перенести вручную, если они сохранились в его базе.
Как откатить расширение к предыдущей версии?
В истории хранилища выберите нужную версию и получите её в локальную базу через команду получения версии. После этого поместите её как новую актуальную версию с комментарием об откате — так в истории останется след операции, и коллеги получат исправленное состояние при следующем обновлении.
Нужно ли хранилище, если разработчик один?
Не обязательно, но полезно. Хранилище даёт историю версий и возможность отката, что удобно даже при одиночной разработке. Альтернатива — регулярная выгрузка расширения в файлы и версионирование через внешние системы контроля версий.
Можно ли перенести хранилище расширения на другой сервер?
Да. Хранилище — это обычный каталог с файлами. Скопируйте его целиком на новое место, после чего каждый разработчик должен отключиться от старого пути и подключиться к хранилищу по новому. Перед копированием убедитесь, что никто не работает с хранилищем.
Что важно запомнить
Хранилище расширения создаётся из окна расширения в конфигураторе и требует платформу 8.3.11 или новее. Каждый разработчик работает под своей учётной записью хранилища, объекты захватываются перед изменением и помещаются с комментарием. Каталог хранилища должен быть доступен всей команде, исключён из облачной синхронизации и включён в резервное копирование.