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

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

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

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

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

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

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

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

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

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

Если команда планирует использовать внешние системы контроля версий (Git), платформа предлагает альтернативу — выгрузку конфигурации в файлы XML и работу через EDT. Но классическое хранилище остаётся самым простым способом организовать совместную работу без дополнительной инфраструктуры.

Подготовка: требования и выбор расположения

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

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

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

Создание хранилища: пошаговая инструкция

Создание выполняется один раз из базы-источника администратором разработки. Последовательность действий одинакова для файлового и клиент-серверного варианта базы.

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

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

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

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

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

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

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

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

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

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

Полезные сценарии для отдельных ситуаций описаны ниже.

Рекурсивный захват

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

Обновление без захвата

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

Просмотр истории и сравнение версий

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

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

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

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

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

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

Пункты меню хранилища неактивны или предлагается только «Подключиться»

Помещение изменений
Норма

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

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

Номер версии не увеличился, история пуста или версия записана под чужим именем

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

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

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

Коллега может захватить тот же объект — значит, захват не выполнен или вы работаете в разных хранилищах

Администрирование и обслуживание хранилища

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

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

Резервное копирование хранилища — простое копирование его каталога в момент, когда никто не выполняет операций. Делайте копию перед массовыми изменениями и перед подавлением версий: отменить удаление старой истории нельзя.

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

Типичные ошибки и как их избежать

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

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

Отдельная ошибка — попытка использовать хранилище как инструмент обмена между удалёнными площадками через медленные VPN-каналы в файловом режиме. При нестабильной сети это прямой путь к повреждению данных. В таких сценариях используйте сервер хранилищ или рассмотрите переход на EDT с Git.

Варианты размещения хранилища

Сетевой файловый каталог

Подходит небольшим командам в одной локальной сети. Простая настройка, но чувствительность к обрывам сети и медленнее на больших конфигурациях.

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

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

EDT + Git вместо хранилища

Подходит командам, готовым перейти на 1C:Enterprise Development Tools. Полноценные ветки и merge, но требует перестройки процессов и обучения.

FAQ

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

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

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

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

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

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

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

Файловый вариант через интернет (VPN, медленные каналы) использовать не рекомендуется из-за риска повреждения данных при обрыве соединения. Для удалённой работы поднимите сервер хранилищ и публикуйте доступ к его порту, либо рассмотрите переход на EDT с Git-репозиторием.

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

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

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

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

Итог

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

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