Разработка и Конфигурация · 11 мин
Как работает хранилище конфигурации 1С
Как устроено хранилище конфигурации 1С: создание, подключение, захват объектов, помещение изменений, версии и типичные ошибки при командной разработке.
Хранилище конфигурации — это встроенный в платформу 1С:Предприятие механизм коллективной разработки. Оно решает две задачи: не даёт двум разработчикам одновременно менять один и тот же объект и сохраняет историю всех изменений конфигурации по версиям. Без хранилища совместная работа над одной конфигурацией быстро превращается в ручное сравнение cf-файлов и потерянные доработки.
Физически хранилище — это каталог с файлом 1cv8ddb (в старых версиях — 1cv8.mddb) и служебными данными, к которому разработчики подключаются из конфигуратора. Каждый разработчик работает со своей информационной базой, но обменивается изменениями через общее хранилище: захватывает объект для редактирования, меняет его у себя, затем помещает результат обратно.
Важно понимать: хранилище — не система контроля версий вроде Git. Оно не поддерживает ветки, слияния и pull-запросы. Механизм проще и жёстче: пока объект захвачен одним разработчиком, остальные могут его только просматривать. Для распределённых команд и сложных процессов разработки часто используют связку хранилища с EDT и Git, но базовый сценарий по-прежнему строится вокруг хранилища конфигурации.
Как устроено хранилище изнутри
Хранилище состоит из файла базы данных хранилища (1cv8ddb) и вложенных каталогов с данными версий. Платформа сама управляет этой структурой: вручную менять, копировать отдельные файлы внутри каталога или удалять их нельзя — это почти гарантированно приводит к повреждению хранилища.
Внутри хранилища фиксируются версии конфигурации. Каждый раз, когда разработчик помещает изменённые объекты, создаётся новая версия с номером, датой, автором и комментарием. По любой версии можно посмотреть состав изменений, получить конфигурацию целиком или сравнить две версии между собой.
Доступ к хранилищу регулируется пользователями хранилища — это отдельный список, не связанный напрямую с пользователями информационной базы. Администратор хранилища заводит учётные записи и назначает права: захват объектов, изменение состава версий, администрирование.
Создание хранилища и подключение разработчиков
Хранилище создаётся из конфигуратора той информационной базы, конфигурация которой станет эталонной. Порядок действий: меню «Конфигурация» → «Хранилище конфигурации» → «Создать хранилище», затем указывается путь к пустому каталогу. Каталог должен быть доступен всем разработчикам: либо по сети (общая папка), либо через сервер хранилища, либо по протоколу http/https через веб-сервер.
После создания хранилища текущая конфигурация базы помещается в него первой версией, а база автоматически подключается к хранилищу. Остальные разработчики создают у себя пустые (или копии) информационные базы и выполняют «Подключиться к хранилищу», указывая тот же путь и свои учётные данные.
Для работы по сети предпочтительнее использовать сервер хранилища 1С или публикацию через веб-сервер, а не прямой доступ к общей папке. Файловый доступ проще в настройке, но чувствителен к обрывам сети: прерванная операция может оставить хранилище в неконсистентном состоянии.
- 1Администратор создаёт пользователя в хранилище: Конфигурация → Хранилище конфигурации → Администрирование → Пользователи
- 2Разработчик создаёт у себя новую информационную базу без конфигурации или копию базы
- 3В конфигураторе: Конфигурация → Хранилище конфигурации → Подключиться к хранилищу, указать путь, имя и пароль
- 4Выполнить «Получить из хранилища» или обновить конфигурацию из хранилища, чтобы получить актуальную версию
- 5Проверить: объекты в окне конфигурации отображаются с пиктограммами состояния (замок, захват)
Основной цикл работы: захват, изменение, помещение
Типичная рабочая сессия выглядит так. Перед началом работы разработчик получает из хранилища свежие изменения коллег: «Конфигурация» → «Хранилище конфигурации» → «Получить из хранилища» либо через обновление конфигурации. Затем захватывает нужные объекты — вручную через «Захватить в хранилище» или автоматически при первом редактировании, если включён соответствующий режим.
Захваченные объекты помечаются в дереве конфигурации. Разработчик вносит изменения, тестирует их в своей базе, затем выполняет «Поместить в хранилище» с обязательным комментарием. После помещения захват по умолчанию снимается, и объект становится доступен коллегам.
Комментарии к версиям — не формальность. По ним потом ищут, когда и зачем появилась конкретная доработка. Договоритесь в команде о формате: номер задачи, краткое описание, автор. Это сильно упрощает разбор инцидентов и перенос доработок между конфигурациями.
Версии, сравнение и откат изменений
История хранилища доступна через «Конфигурация» → «Хранилище конфигурации» → «История хранилища». Там виден список версий с авторами и комментариями. По выбранной версии можно получить отчёт по сравнению с другой версией, выгрузить конфигурацию в cf-файл или загрузить её в свою базу.
Откат ошибочных изменений делается не «удалением версии», а получением нужной старой версии или выборочным переносом объектов. В истории по конкретному объекту можно посмотреть, в каких версиях он менялся, и сравнить его состояние между версиями — это основной инструмент расследования «кто сломал документооборот».
Администратор может изменять состав версий (например, исправить комментарий), но удалять версии следует крайне осторожно: это необратимо и может нарушить целостность истории. Периодическую упаковку и сокращение истории делают только после резервного копирования каталога хранилища.
Блокировки, отмена захвата и конфликтные ситуации
Самая частая проблема — «висячий» захват: разработчик захватил объект и ушёл в отпуск, либо его сеанс завершился аварийно. Объект остаётся недоступным для остальных. Решение — администратор хранилища отменяет захват принудительно через окно состояния хранилища или администрирование. При этом непомещённые изменения того разработчика в хранилище не попадут — они останутся только в его локальной базе.
Вторая типичная ситуация — расхождение локальной конфигурации с хранилищем. Если разработчик долго не получал изменения, при помещении могут возникнуть конфликты по связанным объектам. Правильная реакция — сначала получить свежую версию из хранилища, разрешить расхождения у себя, протестировать и только потом помещать.
Для снижения числа конфликтов полезны простые договорённости: захватывать только реально нужные объекты, помещать изменения небольшими порциями, не держать захват дольше нескольких дней, а масштабные доработки согласовывать заранее по составу объектов.
Администрирование и обслуживание хранилища
Хранилище требует минимального, но регулярного обслуживания. Во-первых, резервное копирование: каталог хранилища копируется целиком в момент, когда никто не выполняет операций с ним. Это единственная защита от потери истории версий.
Во-вторых, контроль размера. Со временем история разрастается, особенно в конфигурациях с большими модулями и частыми помещениями. Платформа позволяет сократить историю, удалив старые версии, но делать это стоит планово и после копии. Также полезно периодически проверять список пользователей хранилища и отключать учётные записи ушедших сотрудников.
В-третьих, мониторинг доступности. Если хранилище опубликовано через сетевую папку, убедитесь, что у всех разработчиков стабильный доступ на чтение и запись, а у посторонних доступа нет: в хранилище содержится полный текст конфигурации, включая весь прикладной код.
Как проверить здоровье хранилища
Операции завершаются без ошибок, версии появляются в истории
Ошибки доступа к файлам, обрывы операций, зависания
Захвачены только объекты активных разработчиков
Много старых захватов от неактивных пользователей
Свежая копия каталога хранилища создана и проверяется восстановлением
Копий нет или они старше недели при активной разработке
Когда хранилища недостаточно: EDT и Git
Хранилище конфигурации хорошо работает для команд до десятка разработчиков с последовательным характером доработок. Его ограничения — отсутствие ветвления, слияний, код-ревью и интеграции с CI/CD. Как только требуется параллельная разработка нескольких функциональностей или автоматическая сборка, хранилище становится узким местом.
Современная альтернатива — 1C:Enterprise Development Tools (EDT) с Git. Конфигурация выгружается в файловый формат, версионируется в Git, а хранилище либо не используется, либо остаётся как промежуточное звено для обмена с конфигуратором. Для типовых конфигураций на поддержке часто применяют гибрид: основная разработка в Git, поставка и сравнение с типовой — через механизмы конфигуратора.
Хранилище или Git + EDT
Подходит небольшим командам с последовательной разработкой; простая настройка, но нет веток и слияний
Подходит распределённым командам и CI/CD; требует освоения EDT и перестройки процессов
Git для разработки, хранилище для обмена с конфигуратором и поддержки типовых механизмов; сложнее в сопровождении
Выбор определяется процессами команды, а не модой. Если у вас три разработчика и стабильный поток доработок, грамотно настроенное хранилище закроет все потребности. Переход на EDT и Git оправдан, когда появляются параллельные релизные ветки, код-ревью и автоматические проверки.
Что важно запомнить
Хранилище конфигурации — механизм коллективной разработки с захватом объектов и версионированием. Работайте короткими циклами: получил изменения — захватил объект — изменил — поместил с комментарием. Регулярно копируйте каталог хранилища и не редактируйте его файлы вручную.
Частые вопросы
Можно ли работать с хранилищем через интернет?
Да. Хранилище публикуется через веб-сервер (IIS или Apache) с расширением платформы, и разработчики подключаются по http/https-адресу. Это удобнее и надёжнее, чем VPN с доступом к сетевой папке: операции идут через сервер, а не напрямую с файлами.
Что делать, если разработчик уволился, а объекты остались захвачены?
Администратор хранилища открывает администрирование хранилища, находит захваченные объекты этого пользователя и отменяет захват. Непомещённые изменения будут потеряны для хранилища, поэтому при увольнении разработчика стоит заранее получить с его базы актуальные доработки.
Как восстановить хранилище после повреждения?
Единственный надёжный способ — восстановить каталог из резервной копии. Если копии нет, можно попробовать создать новое хранилище из актуальной конфигурации рабочей базы, но вся история версий будет утеряна безвозвратно.
Можно ли подключить одну базу к другому хранилищу?
Да, сначала базу отключают от текущего хранилища («Отключиться от хранилища»), затем подключают к новому. При этом состав конфигурации базы и хранилища может различаться — расхождения придётся разрешать через сравнение и объединение.
Почему при помещении возникает ошибка «объект изменён в хранилище»?
Значит, связанные объекты были изменены другим разработчиком после вашего последнего получения. Выполните получение изменений из хранилища, разрешите расхождения в своей базе, проверьте работоспособность и повторите помещение.