К статье
Практический материал

Разработка и Конфигурация · 13 мин

Как подключить базу 1С к хранилищу конфигурации

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

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

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

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

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

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

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

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

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

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

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

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

Откройте эталонную базу в конфигураторе под пользователем с полными правами. Перейдите в меню «Конфигурация → Хранилище конфигурации → Создать хранилище». В открывшемся окне укажите путь к каталогу хранилища — рекомендуется использовать UNC-путь вида \\server\1c_storage\project, а не путь через подключённый сетевой диск, чтобы исключить зависимость от буквы диска на разных машинах.

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

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

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

Настройка пользователей хранилища

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

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

Минимально необходимое право для рядового разработчика — захват и помещение объектов. Права на изменение состава версий и администрирование оставьте одному-двум ответственным. Такая схема снижает риск случайного удаления истории или отмены чужих захватов.

Подключение рабочей базы разработчика к хранилищу

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

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

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

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

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

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

Цикл работы с хранилищем выглядит так. Перед началом правок разработчик выполняет «Получить из хранилища» (Ctrl+Alt+F6 в стандартных назначениях), чтобы подтянуть чужие изменения. Затем захватывает нужные объекты: правый клик по объекту → «Захватить в хранилище». Захваченный объект помечается специальной пиктограммой и становится недоступен для изменения другими пользователями хранилища.

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

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

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

Как проверить, что всё работает

Статус подключения
Норма

В конфигураторе видны команды захвата/помещения, объекты имеют пиктограммы хранилища

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

Команды хранилища неактивны — база не подключена

Захват объекта
Норма

Объект захватывается, у коллеги он блокируется для редактирования

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

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

История версий
Норма

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

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

Версия не создаётся — объект не был захвачен или помещён

Типичные ошибки и их решение

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

Вторая типичная ситуация — «зависший» захват: разработчик захватил объект и ушёл в отпуск или уволился. Разблокировать такой захват может администратор хранилища через администрирование — отмена захвата без сохранения изменений. Делать это стоит осознанно: непомещённые правки того разработчика в хранилище не попадут.

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

Типичные ошибки
01
Подключение одной общей базы несколькими разработчиками — приводит к конфликтам и потере правок
02
Хранилище на локальном диске без резервного копирования — риск потери всей истории версий
03
Один логин хранилища на всю команду — невозможно отследить авторство изменений
04
Длительный захват объектов без помещения — блокирует работу коллег и накапливает конфликты
05
Пустые комментарии при помещении — история версий теряет практическую ценность

Альтернативы и ограничения механизма

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

Для команд, которым нужны ветки, код-ревью и интеграция с CI, применяется связка EDT с Git: конфигурация выгружается в XML-формат и версионируется в Git-репозитории. Это более сложная в настройке схема, но она снимает ограничения классического хранилища. Для небольших команд из 2–5 разработчиков штатного хранилища обычно достаточно.

Варианты организации совместной разработки

Файловое хранилище конфигурации

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

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

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

1C:EDT + Git

Ветвление, код-ревью, интеграция с CI. Требует перехода команды на EDT и настройки выгрузки в XML-формат

FAQ: частые вопросы о подключении к хранилищу

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

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

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

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

Нужно ли отключать пользователей из базы при создании хранилища?

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

Как отключить базу от хранилища?

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

Почему объект не удаётся захватить, хотя никто его не редактирует?

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

Фиксируются ли в хранилище изменения данных, а не конфигурации?

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

Итог

Что важно запомнить

Хранилище создаётся один раз из эталонной базы, затем каждый разработчик подключает свою отдельную копию базы по UNC-пути с личной учётной записью. Работа строится по циклу «получить изменения → захватить → изменить → поместить с комментарием». Резервное копирование каталога хранилища и эталонной базы обязательно, а пароль администратора хранилища нужно хранить надёжно — восстановить его штатными средствами нельзя.