Разработка и Конфигурация · 13 мин
Как создать хранилище конфигурации 1С 8.3
Пошаговая инструкция по созданию хранилища конфигурации 1С 8.3: подготовка каталога, подключение разработчиков, настройка прав, типичные ошибки и проверка результата.
Хранилище конфигурации — это централизованное сетевое хранилище версий конфигурации 1С:Предприятие, которое позволяет нескольким разработчикам работать над одной конфигурацией одновременно, не мешая друг другу. Без хранилища совместная разработка превращается в ручную пересылку cf-файлов и постоянные конфликты изменений.
Создание хранилища выполняется из Конфигуратора и занимает несколько минут, но требует подготовки: нужен общий сетевой каталог с корректными правами доступа, актуальная версия платформы у всех участников и чёткое понимание, кто будет администратором хранилища. Ошибки на этапе настройки приводят к потере истории версий или блокировкам объектов.
Ниже разобран полный цикл: от подготовки каталога до подключения разработчиков, настройки пользователей хранилища и проверки корректности работы, а также типичные ошибки и способы их избежать.
Что такое хранилище конфигурации и когда оно нужно
Хранилище конфигурации — это служебная база данных в файловом формате (каталог с набором файлов, включая служебный файл 1cv8ddb.1CD), в которой платформа сохраняет все версии конфигурации и историю изменений по каждому объекту. Каждый разработчик работает с локальной копией конфигурации, а синхронизация выполняется через механизм захвата и помещения объектов.
Хранилище необходимо, если над конфигурацией работают два и более разработчика, если требуется история изменений с возможностью отката к любой версии, а также если нужен контроль того, кто и когда изменил конкретный объект. Для одиночной разработки хранилище тоже полезно как инструмент версионирования, но не является обязательным — многие используют выгрузку в файлы конфигурации и внешние системы контроля версий.
Важно понимать ограничение: хранилище конфигурации не заменяет резервное копирование информационной базы. В нём хранится только конфигурация (метаданные, модули, формы), но не пользовательские данные. Каталог хранилища нужно включать в отдельный регламент резервного копирования.
Подготовка: каталог, права и версии платформы
Перед созданием хранилища подготовьте сетевой каталог, доступный всем разработчикам. Это может быть папка на файловом сервере или на выделенной машине. Каталог должен быть пустым — платформа создаст в нём служебную структуру самостоятельно. Указывать существующий каталог с чужими файлами нельзя.
У всех учётных записей, под которыми работают разработчики, должны быть права на чтение и запись в этот каталог, включая создание и удаление файлов. Частая причина ошибок «Нарушение прав доступа» при работе с хранилищем — недостаточные права на сетевую папку или антивирус, блокирующий служебные файлы. Каталог хранилища рекомендуется добавить в исключения антивируса.
Проверьте, что у всех участников установлена совместимая версия платформы 1С:Предприятие 8.3. Хранилище, созданное или обновлённое под более новой версией платформы, может оказаться недоступным для разработчиков со старой версией. Согласуйте единую версию до начала работы.
Создание хранилища из Конфигуратора
Создание выполняется из Конфигуратора той информационной базы, конфигурацию которой нужно поместить в хранилище. Обычно это отдельная база-источник, созданная специально для разработки, а не рабочая база пользователей.
- Откройте информационную базу в режиме Конфигуратора под пользователем с полными правами.
- Откройте конфигурацию: меню «Конфигурация → Открыть конфигурацию». Дождитесь полной загрузки дерева объектов.
- Выполните команду «Конфигурация → Хранилище конфигурации → Создать хранилище».
- В диалоге укажите путь к подготовленному пустому сетевому каталогу. Используйте UNC-путь (\\сервер\папка), а не локальный диск, если к хранилищу будут подключаться другие разработчики.
- Подтвердите создание. Платформа сформирует структуру хранилища и поместит в него текущую конфигурацию как первую версию.
Процесс может занять заметное время для крупных конфигураций — типовые решения содержат тысячи объектов. Не прерывайте операцию: незавершённое создание оставляет хранилище в неконсистентном состоянии, и процедуру придётся начинать заново с очисткой каталога.
При создании хранилища платформа автоматически создаёт первого пользователя с правами администратора — учётные данные берутся из текущего сеанса. Запомните или запишите имя и пароль этого пользователя: без них невозможно управлять хранилищем.
- 1Создайте пустой общий сетевой каталог с правами на чтение и запись для всех разработчиков
- 2Откройте базу-источник в Конфигураторе под пользователем с полными правами
- 3Откройте конфигурацию и выполните «Конфигурация → Хранилище конфигурации → Создать хранилище»
- 4Укажите UNC-путь к каталогу и дождитесь завершения помещения конфигурации
- 5Сохраните учётные данные администратора хранилища
- 6Проверьте, что в каталоге появились служебные файлы, включая 1cv8ddb.1CD
Настройка пользователей хранилища
После создания хранилища администратор должен завести учётные записи для каждого разработчика. Это делается через команду «Конфигурация → Хранилище конфигурации → Администрирование хранилища» (в ряде версий платформы — «Пользователи хранилища»). В диалоге администрирования добавляются пользователи с именами и паролями.
У пользователя хранилища есть два ключевых параметра: право администрирования и право изменения версий конфигурации. Обычному разработчику достаточно стандартных прав на захват и помещение объектов. Право администрирования давайте минимальному числу людей — администратор может отменять захват объектов других пользователей, менять версии и удалять пользователей.
Практические рекомендации по учётным записям: используйте персональные имена, а не общие аккаунты — иначе история изменений потеряет смысл, так как невозможно будет определить автора конкретной правки. Пароли пользователей хранилища не связаны с паролями информационной базы, это независимая система аутентификации.
Подключение разработчиков к хранилищу
Каждый разработчик работает в собственной копии информационной базы, подключённой к общему хранилищу. Создать такую копию можно выгрузкой и загрузкой базы-источника (dt-файл) или созданием новой пустой базы с последующей загрузкой конфигурации из хранилища.
Подключение выполняется так: в Конфигураторе разработчик открывает конфигурацию и выбирает «Конфигурация → Хранилище конфигурации → Подключиться к хранилищу». В диалоге указывается путь к каталогу хранилища, имя и пароль пользователя хранилища. После подключения платформа предложит получить конфигурацию из хранилища — нужно согласиться, чтобы локальная конфигурация синхронизировалась с актуальной версией.
После подключения в дереве конфигурации появляются индикаторы состояния объектов: замок у захваченных объектов, специальные пиктограммы у объектов, изменённых в хранилище другими разработчиками. Для редактирования объекта его нужно захватить: правой кнопкой по объекту → «Захватить в хранилище». После завершения правок объект помещается обратно с комментарием к изменению.
Комментарии при помещении объектов — обязательная практика. Именно по ним команда потом разбирает историю изменений и ищет, в какой версии появилась конкретная доработка или ошибка. Пустые комментарии делают историю версий бесполезной.
Договоритесь в команде о правиле: захватывать только те объекты, которые реально правятся прямо сейчас, и помещать их в течение рабочего дня. Объекты, захваченные «про запас» и забытые на неделю, — главная причина простоев коллег и вызовов администратора для принудительной отмены захвата.
Регламентная работа и обслуживание хранилища
Хранилище требует минимального, но регулярного обслуживания. Во-первых, настройте резервное копирование каталога хранилища — достаточно файлового копирования всей папки в момент, когда никто не работает, либо копирования теневыми средствами. Потеря хранилища означает потерю всей истории версий.
Во-вторых, контролируйте версию платформы. При обновлении платформы обновляйте её у всех разработчиков одновременно и до начала работы в новой версии выполните резервную копию хранилища. Смешанная работа с разных версий платформы — источник ошибок формата.
В-третьих, периодически проверяйте список захваченных объектов через администрирование хранилища. «Висячие» захваты от уволенных сотрудников или сломанных баз отменяйте вручную, предварительно убедившись, что изменения не потеряются — при отмене захвата непомещённые правки в хранилище не попадут.
Для крупных команд имеет смысл рассмотреть альтернативу — работу через EDT (1C:Enterprise Development Tools) с Git, где версионирование гибче, а ветвление и слияние изменений удобнее. Классическое хранилище остаётся надёжным и простым решением для команд малого и среднего размера, работающих в Конфигураторе.
Проверка результата и устранение проблем
После создания и подключения проверьте работоспособность хранилища простым циклом: захватите любой объект (например, общий модуль), внесите тестовое изменение (комментарий в коде), поместите объект с комментарием и убедитесь, что в истории хранилища появилась новая версия. Затем со второго рабочего места выполните «Обновить конфигурацию из хранилища» и убедитесь, что изменение пришло.
Если при подключении возникает ошибка доступа — проверяйте права на сетевой каталог и корректность пути. Если платформа сообщает о несовместимости версий — сверяйте версии платформы у всех участников. Ошибки чтения служебных файлов часто указывают на антивирус или облачную синхронизацию каталога.
При повреждении хранилища (ошибки формата, невозможность открыть) восстановление выполняется из резервной копии каталога. Если копии нет, единственный выход — создать новое хранилище из актуальной конфигурации любой подключённой базы, но история версий будет потеряна. Это ещё один аргумент в пользу регулярного копирования.
Как проверить результат
В каталоге есть 1cv8ddb.1CD и служебные подкаталоги
Каталог пуст или содержит посторонние файлы
Подключение проходит, конфигурация получается из хранилища
Ошибка доступа или несовместимости версий
Объект захватывается, помещается, версия видна в истории
Ошибки при помещении или версия не появляется
У каждого разработчика персональная учётная запись
Все работают под одним пользователем
Что важно запомнить
Хранилище создаётся из Конфигуратора в пустой общий сетевой каталог по UNC-пути. Каждому разработчику нужна персональная учётная запись хранилища и одинаковая версия платформы. Работа строится на цикле «захват → правка → помещение с комментарием». Каталог хранилища обязательно включайте в резервное копирование и держите вне облачных синхронизаций.
Частые вопросы
Можно ли создать хранилище для рабочей базы, в которой уже работают пользователи?
Технически можно, но правильнее создать отдельную копию базы для разработки и подключать к хранилищу именно её. Рабочая база пользователей не должна быть подключена к хранилищу — обновления в неё переносятся через «Загрузить конфигурацию из файла» или «Обновить конфигурацию базы данных» после тестирования на копии.
Сколько разработчиков может работать с одним хранилищем?
Жёсткого ограничения платформа не накладывает, на практике файловое хранилище комфортно обслуживает команды от двух до нескольких десятков разработчиков. Узкое место — скорость сетевого доступа к каталогу: при медленной сети операции получения и помещения заметно тормозят.
Что делать, если разработчик захватил объект и уволился?
Администратор хранилища может отменить захват принудительно через диалог администрирования. При этом непомещённые изменения, сделанные в локальной базе этого разработчика, в хранилище не попадут — если правки важны, сначала заберите их из его базы выгрузкой или сравнением конфигураций.
Чем хранилище конфигурации отличается от выгрузки конфигурации в файлы?
Выгрузка в файлы — это статичный снимок конфигурации в виде XML-файлов, удобный для интеграции с Git и другими внешними системами. Хранилище — активный механизм совместной работы с блокировками объектов, историей версий и контролем авторства, встроенный прямо в Конфигуратор. Эти подходы можно комбинировать.
Можно ли перенести хранилище на другой сервер?
Да. Остановите работу всех разработчиков, скопируйте весь каталог хранилища целиком на новое место, выдайте права доступа и переподключите каждую базу разработчика к новому пути через «Подключиться к хранилищу». История версий и пользователи сохраняются, так как всё это находится внутри каталога.
Нужно ли хранилище, если разработчик один?
Не обязательно, но полезно: хранилище даёт историю версий с возможностью отката и комментариями к каждому изменению, что удобно даже при одиночной работе. Альтернатива — регулярная выгрузка конфигурации в файлы и версионирование через Git, что требует больше дисциплины, но гибче.