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

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

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

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

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

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

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

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

Подготовка перед созданием хранилища

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

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

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

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

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

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

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

Учётная запись администратора хранилища создаётся отдельно от пользователей информационной базы. Сохраните её пароль в надёжном месте: восстановить пароль администратора хранилища штатными средствами нельзя.

Настройка пользователей и прав доступа

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

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

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

Подключение рабочих баз разработчиков

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

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

Для файловых баз путь к хранилище указывается как сетевой путь (например, \\server\1c_storage\project). Для клиент-серверных баз подключение выполняется так же — хранилище остаётся файловым каталогом, доступ к нему нужен с компьютера, где запущен конфигуратор.

Удобно, чтобы путь к хранилищу был одинаковым у всей команды — например, через подключённый сетевой диск с одной буквой или единый UNC-путь. Тогда инструкции и скрипты пакетной загрузки будут работать у всех без правки.

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

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

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

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

Обслуживание и резервное копирование хранилища

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

Со временем хранилище растёт за счёт накопленных версий. Если история за старые периоды не нужна, администратор может выполнить сокращение хранилища (очистку старых версий) через параметры администрирования. Перед сокращением обязательно сделайте полную копию каталога.

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

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

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

Подключение к хранилищу

Норма

В меню «Конфигурация — Хранилище конфигурации» активны пункты захвата и помещения

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

Ошибка доступа к каталогу или неверный пользователь — проверьте путь и права

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

Норма

Объект помечается как захваченный вами, у коллег он доступен только для чтения

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

Захват не выполняется или объект захвачен неизвестным пользователем

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

Норма

После помещения объекта в истории появляется новая версия с вашим именем

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

Версии не создаются или авторство отображается неверно

FAQ

Можно ли использовать хранилище для одной базы и одного разработчика?

Да, это нормальная практика. Хранилище даст историю версий и возможность отката изменений. Дополнительных накладных расходов минимум — нужно лишь не забывать помещать объекты после доработки.

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

Штатного способа восстановления нет. Если есть второй администратор — он сбросит пароль через администрирование. Если нет, придётся создавать новое хранилище из актуальной конфигурации, при этом история версий старого хранилища сохранится только в старом каталоге.

Как перенести хранилище на другой сервер?

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

Конфликт при обновлении из хранилища — что это значит?

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

Нужно ли хранилище, если используется EDT и Git?

При разработке в 1C:EDT с Git классическое хранилище конфигурации не требуется — версионирование берёт на себя Git. Хранилище остаётся актуальным для команд, работающих в Конфигураторе, и для типовых процессов, построенных на нём.

Можно ли отменить помещение объекта в хранилище?

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