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

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

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

Материал ориентирован на администраторов и ведущих разработчиков 1С, которые настраивают командную разработку впервые или переносят хранилище на новый сервер.

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

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

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

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

Выбор типа хранилища: файловое или серверное

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

Файловый вариант проще в развёртывании и подходит команде до примерно 5–10 разработчиков при умеренной интенсивности изменений. Его главные риски — зависание блокировок при обрыве сети и деградация скорости при росте числа версий. Серверный вариант устойчивее к сбоям, быстрее работает с большой историей и позволяет централизованно администрировать доступ, но требует установленного сервера 1С и навыков его администрирования.

Сравнение вариантов

Файловое хранилище

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

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

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

Подготовка каталога и требования к окружению

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

Учтите несколько технических требований. Во-первых, у всех разработчиков должна быть совместимая версия платформы: подключение к хранилищу с более старой платформы, чем та, которой оно создавалось, может быть заблокировано. Во-вторых, сетевой путь к каталогу должен быть одинаково доступен всем — лучше использовать UNC-путь вида \\server\1c-storage\, а не подключенные диски, буквы которых у разных пользователей различаются. В-третьих, антивирус на сервере желательно настроить так, чтобы он не блокировал файлы хранилища в момент записи, иначе возможны ошибки помещения версий.

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

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

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

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

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

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

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

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

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

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

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

Регламентная работа: захват, помещение и обновление

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

Комментарии к версиям — не формальность. Осмысленное описание («Исправлен расчёт скидки в документе Реализация при частичной оплате») позволяет позже найти нужную версию и понять причину изменения. Комментарии вида «правки» или «fix» делают историю бесполезной.

Если разработчик уходит в отпуск или увольняется с захваченными объектами, администратор может отменить захват через администрирование хранилища. Это штатная операция, но применять её стоит аккуратно: непомещённые изменения, сделанные после захвата, при отмене в хранилище не попадут.

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

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

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

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

Помещение объекта в хранилище

Норма

Версия создаётся, в истории видны автор и комментарий

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

Ошибка доступа к файлам или обрыв по сети

Захват объекта другим пользователем

Норма

Платформа сообщает, что объект захвачен, и блокирует захват

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

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

Обновление конфигурации из хранилища

Норма

Изменения коллег применяются к локальной базе

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

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

Резервная копия каталога хранилища

Норма

Копия создаётся по расписанию и восстанавливается в тестовом каталоге

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

Копий нет или восстановление не проверялось

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

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

Можно ли развернуть хранилище для файловой информационной базы?

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

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

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

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

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

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

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

Заменяет ли хранилище резервное копирование базы?

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

Чем хранилище конфигурации отличается от EDT и Git?

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