Хранилище конфигурации 1С: настройка, захват объектов и права разработчиков

Пользоваться хранилищем 1С просто: базу разработчика подключают через Конфигурация → Хранилище конфигурации → Подключиться к хранилищу, перед правкой объект захватывают, после правки помещают обратно с комментарием. Остальные разработчики получают изменения командой Получить из хранилища. Всё это делается в Конфигураторе платформы 8.3 и одинаково для любой конфигурации: БП, ЗУП, УТ или самописной.

Выбор есть только в одном месте — где лежит само хранилище. Файловое хранилище в сетевой папке подходит команде из 2–3 человек в одной локальной сети. Сервер хранилища (TCP) или публикация через веб-сервер (HTTP) нужны, когда разработчиков больше или кто-то подключается удалённо.

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

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

Каждый разработчик работает в своей копии информационной базы. Его основная конфигурация «привязана» к хранилищу. Схема работы такая:

• 🔒 Захват. Объект блокируется за одним пользователем. Остальные видят его, но изменить не могут.
• ✏️ Правка. Разработчик меняет объект у себя, проверяет, отлаживает.
• 📤 Помещение. Изменения уходят в хранилище, создаётся новая версия с номером, автором, датой и комментарием.
• 📥 Получение. Коллеги забирают новую версию в свои базы.

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

Три способа разместить хранилище

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

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

Создание и подключение хранилища в Конфигураторе

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

Создание нового хранилища

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

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

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

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

Хранилище для расширения

Расширения конфигурации подключаются к хранилищу отдельно от основной конфигурации. Откройте окно расширений (Конфигурация → Расширения конфигурации), выделите расширение и найдите команды хранилища в меню этого окна. Для расширения создаётся своё хранилище по отдельному адресу.

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

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

• 🟢 зелёный замок — объект захвачен вами;
• 🔴 красный замок — объект захвачен другим пользователем;
• без значка — объект свободен.

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

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

Захватывать можно как один объект, так и ветку целиком. Если нужно добавить новый объект (например, новый документ), захватывают родительскую ветку: для документа — ветку Документы, для новой роли — ветку Роли. Добавление реквизита требует захвата самого объекта.

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

1. Выберите Конфигурация → Хранилище конфигурации → Поместить изменения конфигурации в хранилище….
2. В списке отметьте объекты, которые отправляете.
3. Напишите комментарий: номер задачи и что сделано. Через год только он объяснит, зачем менялся модуль.
4. Если продолжаете работу над объектом, включите флажок «Оставить объекты захваченными».
5. Нажмите «Поместить».

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

Получение и отмена

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

После получения изменений не забывайте обновить конфигурацию базы данных (F7). Без этого изменения видны в Конфигураторе, но не работают в режиме 1С:Предприятие.

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

Конфигурация → Хранилище конфигурации → История хранилища показывает все версии с авторами и комментариями. Отсюда можно:

• сравнить две любые версии и увидеть, кто что поменял;
• сохранить конфигурацию нужной версии в файл .cf;
• поставить на версию метку, например «Релиз для рабочей базы, сборка 47».

Пакетный режим: обновление рабочей базы из хранилища

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

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER ^
  /S "srv1c\buh" /N "Администратор" /P "пароль_ИБ" ^
  /ConfigurationRepositoryF "tcp://srvrepo:1542/buh" ^
  /ConfigurationRepositoryN "deploy" /ConfigurationRepositoryP "пароль_хранилища" ^
  /ConfigurationRepositoryUpdateCfg -force ^
  /UpdateDBCfg ^
  /DisableStartupDialogs /Out "C:\logs\update.log"

Что делают параметры:

• /ConfigurationRepositoryF, /ConfigurationRepositoryN, /ConfigurationRepositoryP — адрес хранилища, пользователь и пароль;
• /ConfigurationRepositoryUpdateCfg — получить последнюю версию из хранилища в конфигурацию базы;
• /UpdateDBCfg — применить изменения к базе данных;
• /Out — записать протокол в файл, чтобы потом понять, что пошло не так.

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

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

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

Пользователями хранилища управляет администратор: Конфигурация → Хранилище конфигурации → Администрирование…. В этом окне создают и удаляют пользователей, задают пароли и права.

Права выставляются флажками в карточке пользователя. Логика простая:

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

Правила, которые стоит завести сразу:

• 👤 Одна учётная запись — один человек. Общий логин «dev» лишает историю смысла: не видно, кто поместил ошибку.
• 🔑 Пароли у всех. Без пароля любой, кто знает адрес, подключится и захватит корень.
• 🚪 Ушедших сотрудников удаляйте. Их захваты освободите через администрирование, не дожидаясь звонка.
• 🗂️ Доступ к папке хранилища. Для файлового варианта права на сетевую папку дают только разработчикам. Для сервера хранилища папку с данными видит лишь учётная запись службы.

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

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

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

Что ускоряет работу

• 🖥️ Сервер хранилища вместо сетевой папки. Самый заметный эффект: клиент обменивается с сервером только нужными данными, а не читает файл по сети.
• 🧩 Одинаковая версия платформы. У сервера хранилища и у всех разработчиков должна стоять одна и та же сборка платформы. Разные сборки — частая причина отказа в подключении.
• 💾 Быстрый диск под хранилище. Хранилище много читает мелкими блоками, SSD заметно сокращает время захвата и получения.
• 📦 Захват точечно. Захват корня конфигурации или большой ветки без нужды тормозит работу всей команды и мешает коллегам.

Регулярное обслуживание

1. Резервная копия. Для файлового хранилища копируйте всю папку целиком. Для сервера хранилища — остановите службу, скопируйте каталог с данными, запустите снова. Остановка службы оборвёт подключения разработчиков, поэтому делайте это вне рабочего времени или предупредите команду.
2. Оптимизация данных. В окне администрирования есть команда оптимизации хранения данных. Она уменьшает размер хранилища; запускайте её, когда никто не работает .
3. Проверка файла. Если файловое хранилище повреждено после сбоя, файл 1cv8ddb.1CD можно проверить утилитой chdbfl.exe из каталога bin платформы. Работайте с копией, а не с оригиналом.
4. Сохранение версий в .cf. Перед крупными изменениями сохраните текущую версию из истории в файл. Это дешёвая страховка.

Ошибки при работе с хранилищем и как их устранить

Большинство проблем с хранилищем укладывается в несколько повторяющихся ситуаций. Найдите свой симптом:

Если база была скопирована вместе с привязкой

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

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

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