Хранилище конфигурации 1С: как оно устроено и когда без него не обойтись

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

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

Чем хранилище конфигурации отличается от базы и резервных копий

Путаница возникает потому, что везде фигурируют файлы .1CD. Но назначение у них разное.

Главный вывод из таблицы: хранилище не заменяет резервную копию базы . Если бухгалтер случайно удалил документы, хранилище не поможет — нужен .dt или бэкап СУБД. И наоборот: бэкап базы не покажет, кто и когда поменял строку в модуле.

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

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

Физически хранилище — это каталог. В нём основной файл 1cv8ddb.1CD и служебные подкаталоги с данными версий. Работать с этими файлами руками нельзя: только через Конфигуратор или сервер хранилища.

Два способа доступа

• 📁 Файловый. Каталог лежит в общей сетевой папке, разработчики подключаются по пути вида \\server\repo\buh. Просто, но медленно на больших конфигурациях и чувствительно к обрывам сети.
• 🖥️ Через сервер хранилища. Устанавливается компонент crserver (сервер хранилища конфигураций), подключение идёт по адресу tcp://имя-сервера/путь. По умолчанию сервер хранилища слушает порт 1542. Есть и вариант публикации через веб-сервер по HTTP.

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

Что происходит при работе

1. Разработчик подключает свою базу к хранилищу. Конфигурация базы становится привязанной: объекты без захвата редактировать нельзя.
2. Перед правкой объект захватывают. В дереве конфигурации у него появляется зелёная галочка, у остальных — красный замок.
3. После правки объект помещают в хранилище с комментарием. Возникает новая версия с номером, автором и датой.
4. Остальные выполняют обновление конфигурации из хранилища и получают изменения.
5. Каждый, кто получил изменения, обновляет конфигурацию своей базы данных (F7 или кнопка «Обновить конфигурацию базы данных»).

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

Пять сценариев, где хранилище нужно обязательно

1. 👥 Несколько программистов на одной конфигурации. Без захвата объектов изменения неизбежно затирают друг друга при объединении .cf.
2. 🔄 Доработанная типовая на поддержке. Обновлять типовую с правками удобнее в отдельной базе, подключённой к хранилищу: каждая итерация обновления фиксируется версией, и при неудаче легко вернуться назад.
3. 🧑‍💼 Подрядчик или фрилансер. История показывает, кто и что менял, а права ограничивают, кто может помещать изменения. При смене подрядчика ничего не теряется.
4. 🧪 Разделение «разработка → тест → прод». Разработческие и тестовые базы подключены к хранилищу, рабочая — нет. В прод уходит проверенная версия, сохранённая в .cf.
5. 🧩 Расширения конфигурации . Расширение тоже можно подключить к хранилищу — отдельно от основной конфигурации. Удобно, когда изменения сделаны расширениями, а типовая остаётся без снятия с поддержки.

Даже программисту-одиночке хранилище полезно ради истории: «что я поменял в этом модуле три месяца назад» находится за минуту.

Создание и подключение хранилища по шагам

Шаг 1. Подготовьте место

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

Шаг 2. Создайте хранилище

1. Откройте в Конфигураторе базу, конфигурацию которой нужно поместить в хранилище. Лучше сразу ту, где конфигурация в актуальном состоянии.
2. Выберите Конфигурация → Хранилище конфигурации → Создать хранилище.
3. Укажите путь: каталог (\\server\repo\buh) или адрес сервера (tcp://srv-1c/buh).
4. Задайте имя и пароль администратора хранилища. Это отдельная учётная запись, не пользователь базы.
5. Дождитесь окончания помещения конфигурации. На крупной конфигурации это занимает от нескольких минут до часа.

Первая версия хранилища — исходная конфигурация. Её стоит сразу пометить меткой, например «Исходная типовая».

Шаг 3. Заведите пользователей и права

Откройте Конфигурация → Хранилище конфигурации → Администрирование. Для каждого разработчика создайте пользователя и выдайте права:

Тестировщику или аналитику хватит пользователя без прав захвата: он сможет обновлять свою базу из хранилища и смотреть историю.

Шаг 4. Подключите базы разработчиков

1. Каждый разработчик делает свою копию базы (обычно из .dt рабочей).
2. В Конфигураторе: Конфигурация → Хранилище конфигурации → Подключиться к хранилищу.
3. Указывает путь, своё имя и пароль в хранилище.
4. Если конфигурация базы отличается от хранилища, платформа предложит заменить её конфигурацией из хранилища. Соглашайтесь только если локальных правок нет или они сохранены в .cf.

Шаг 5. Автоматизируйте обновление тестовой базы

Тестовую базу удобно обновлять из хранилища по расписанию пакетным запуском:

"C:\Program Files\1cv8\8.3.24.1691\bin\1cv8.exe" DESIGNER /F "D:\Bases\Test" ^
  /ConfigurationRepositoryF "tcp://srv-1c/buh" ^
  /ConfigurationRepositoryN "test-robot" /ConfigurationRepositoryP "пароль" ^
  /ConfigurationRepositoryUpdateCfg -force /UpdateDBCfg ^
  /Out "D:\Logs\update.log"

Путь к 1cv8.exe подставьте свой. Пароль в bat-файле храните на сервере с ограниченным доступом, а пользователю test-robot не давайте прав захвата.

Где на практике ломается работа с хранилищем

• 🔒 Объект захвачен неделями. Разработчик ушёл в отпуск с захваченным общим модулем, остальные стоят. Администратор хранилища может отменить чужой захват, но несохранённые правки владельца при этом в хранилище не попадут. Договоритесь: захват дольше дня — только по согласованию.
• 📝 Помещение без комментария. Через полгода история из сотни версий «без описания» бесполезна. Пишите номер задачи и суть: «#412 — новая печатная форма акта».
• 🧱 Получили изменения, но базу не обновили. Конфигурация в Конфигураторе новая, а в режиме Предприятия всё по-старому. После обновления из хранилища нужно обновить конфигурацию базы данных.
• 🔀 Рабочая база подключена к хранилищу. Любое помещение сразу провоцирует желание «быстро обновить прод». Отключите рабочую базу и переносите изменения через .cf после теста.
• 💾 Хранилище не попадает в бэкап. Повреждение каталога или диска — и пропадает вся история. Копируйте каталог хранилища по расписанию, лучше в момент, когда никто не помещает изменения.
• 🧩 Захват «на всякий случай» всей конфигурации. Захват корня с рекурсией блокирует всех. Захватывайте только то, что правите.

Можно ли подружить хранилище 1С с Git

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

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

Для gitsync понадобится файл соответствия пользователей хранилища и авторов Git (имя и e-mail). Без него все коммиты окажутся от безымянных авторов.

Что хранилище умеет помимо захвата и помещения

Эти функции есть в меню хранилища, но ими редко пользуются.

История и сравнение версий

Конфигурация → Хранилище конфигурации → История хранилища. Выделите версию и сравните её с текущей конфигурацией или с другой версией — увидите, какие объекты и строки менялись. Удобно, когда после выкладки «что-то сломалось»: за пять минут находится, что именно поменяли.

История одного объекта

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

Метки версий

Меткой отмечают важные точки: «Выложено в рабочую 15.09», «До обновления на новый релиз». Метка не меняет данные, но по ней быстро находится нужная версия в длинной истории.

Сохранение любой версии в файл

Из истории можно сохранить любую версию в .cf. Это и есть откат: сохранили версию до неудачного изменения, загрузили в тестовую базу, проверили — и отправили в прод.

Отчёт по версиям

Отчёт по хранилищу собирает список версий за период с авторами и комментариями. Его используют для отчёта перед заказчиком: что сделано за месяц. Пакетно отчёт формируется ключом /ConfigurationRepositoryReport.

Помещение с сохранением захвата

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

Получение без захвата

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

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