Как сделать хранилище конфигурации в 1С

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

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

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

Что такое хранилище конфигурации и когда оно нужно

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

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

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

Подготовка: каталог, права доступа и резервная копия

Перед созданием хранилища подготовьте пустой каталог. Для небольшой команды подойдёт общая сетевая папка на сервере, доступная всем разработчикам по одному пути. Важно, чтобы путь у всех пользователей совпадал: если один подключается как \\server\storage, а другой как Z:\storage, проблем не будет только при условии, что оба пути ведут в один каталог. Каталог должен быть именно пустым — платформа откажется создавать хранилище в папке с посторонними файлами.

Настройте права на файловом уровне: каждому разработчику нужен полный доступ к каталогу хранилища (чтение, запись, изменение, создание файлов и подкаталогов). Ограничение прав — частая причина ошибок вида «Ошибка доступа к файлу хранилища». Если планируется работа через интернет или филиалы, рассмотрите вариант с сервером хранилища вместо прямого файлового доступа.

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

Создание хранилища из конфигуратора

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

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

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

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

Подключение разработчиков и настройка пользователей

Каждый разработчик подключает свою базу к хранилищу через меню Конфигурация → Хранилище конфигурации → Подключиться к хранилищу. Указывается тот же каталог, имя пользователя и пароль. Пользователей хранилища заводит администратор: Конфигурация → Хранилище конфигурации → Администрирование → Пользователи. Здесь же назначаются права — обычный пользователь может захватывать и помещать объекты, административные функции стоит оставить минимальному кругу лиц.

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

Повседневная работа: захват, помещение, обновление

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

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

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

Файловый доступ или сервер хранилища

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

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

Сравнение вариантов доступа

Прямой файловый доступ

Подходит для 2–10 разработчиков в одной локальной сети. Минус: нужна общая папка и полные права на неё у всех, чувствительность к обрывам сети.

Сервер хранилища

Подходит для удалённой работы и больших команд. Требует установки и сопровождения службы, но снимает зависимость от сетевых папок.

Системы версионирования (Git через EDT)

Подходит для проектов на 1C:Enterprise Development Tools с выгрузкой в файлы. Требует перестройки процесса разработки и навыков работы с Git.

Проверка результата и обслуживание хранилища

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

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

Как проверить результат

История хранилища

Норма

Видны версии с номерами, авторами и комментариями

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

История пуста или недоступна — база не подключена к хранилищу

Захват объекта

Норма

У второго пользователя объект доступен только для просмотра

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

Второй пользователь свободно редактирует захваченный объект

Помещение изменений

Норма

Создаётся новая версия, изменения видны после обновления у коллеги

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

Ошибки доступа к файлам или версия не появляется

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

Ответы на частые вопросы

Можно ли создать хранилище для базы, которая уже давно в работе?

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

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

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

Можно ли работать с хранилищем через интернет?

Да, через сервер хранилища: служба публикуется на сервере, разработчики подключаются по адресу tcp://server:port. Прямой файловый доступ через интернет по VPN тоже возможен, но медленнее и чувствительнее к обрывам связи.

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

Хранилище работает на уровне объектов конфигурации и встроено в конфигуратор — это просто, но слабо подходит для ветвления и слияния. Git в связке с 1C:EDT и выгрузкой в файлы даёт ветки, merge и code review, но требует другого инструментария и более строгой дисциплины.

Сколько разработчиков может работать с одним хранилищем?

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

Нужно ли хранилище, если разработчик один?

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