Разработка и Конфигурация · 11 мин
Как развернуть хранилище конфигурации 1С
Как создать и развернуть хранилище конфигурации 1С: выбор каталога, настройка доступа пользователей, подключение баз, резервное копирование и типичные ошибки.
Хранилище конфигурации — это централизованное место, где 1С хранит историю изменений конфигурации при командной разработке. Без него два разработчика не смогут одновременно править одни и те же объекты: изменения одного неизбежно затрут работу другого. Развернуть хранилище можно на файловом сервере локальной сети, через веб-сервер или по протоколу TCP — способ зависит от размера команды и инфраструктуры.
Процедура состоит из трёх этапов: подготовка каталога или сервера, создание хранилища из конфигуратора и подключение к нему рабочих баз разработчиков. Вся настройка выполняется штатными средствами платформы, стороннее ПО не требуется. Ниже разобран каждый шаг с условиями выбора способа доступа, проверкой результата и типичными ошибками.
Перед началом убедитесь, что у вас есть права администратора в конфигураторе, полная выгрузка текущей конфигурации в файл .cf или .dt и доступ к серверу, где будет физически располагаться хранилище. Если конфигурация уже ведётся несколькими людьми без хранилища, сначала договоритесь о «заморозке» изменений на время развёртывания.
Выберите способ доступа к хранилищу
Платформа 1С поддерживает три варианта подключения к хранилищу: файловый (через общий сетевой каталог), через сервер хранилищ по протоколу TCP и через веб-сервер по HTTP/HTTPS. Выбор влияет на производительность, безопасность и сложность поддержки, поэтому определить его стоит до создания хранилища — миграция между способами возможна, но требует пересоздания или перенастройки.
Файловый доступ — самый простой вариант: хранилище лежит в общей папке, а разработчики обращаются к ней по сетевому пути вида \\server\1c_storage. Он подходит для небольших команд в одной локальной сети. Минусы: нужно выдавать права на файловую систему всем разработчикам, а при обрыве сети во время записи есть риск повреждения файлов хранилища.
Сервер хранилищ (crserver) и веб-доступ снимают эти ограничения: пользователям не нужны права на файлы, обмен идёт по протоколу, устойчивому к обрывам, а HTTP-вариант позволяет работать через интернет без VPN. Для распределённой команды или работы из дома предпочтителен веб-сервер с HTTPS.
Сравнение способов доступа
Быстро разворачивается, подходит для 2–5 разработчиков в одной сети. Ограничение: все пользователи получают доступ к файлам хранилища, чувствителен к обрывам сети.
Стабильнее при нестабильной сети, права на файлы не нужны. Требует установки и сопровождения службы сервера хранилищ.
Подходит для удалённой работы через интернет. Требует настройки IIS или Apache и публикации хранилища.
Подготовьте каталог и права доступа
Создайте на сервере отдельный каталог под хранилище, например D:\1C_Storage\MainConfig, и не размещайте в нём ничего постороннего. Для файлового доступа расшарьте каталог и выдайте группе разработчиков права на чтение и запись как на уровне общего ресурса, так и на уровне NTFS. Учётная запись, под которой работают разработчики, должна гарантированно иметь доступ — проверьте это, зайдя по сетевому пути с машины разработчика.
Для сервера хранилищ установите компоненту «Сервер хранилищ конфигураций» из дистрибутива платформы и запустите её как службу, указав каталог хранилищ. Для веб-доступа опубликуйте хранилище через мастер публикации на веб-сервере, включив в файле настройки публикации параметр работы с хранилищем.
Отдельно настройте резервное копирование каталога хранилища. Хранилище содержит всю историю разработки, и его потеря означает потерю истории изменений и возможности корректно обновлять подключённые базы. Включите каталог в регулярный план бэкапов сервера и периодически проверяйте восстановление копии на тестовом каталоге.
Создайте хранилище из конфигуратора
Откройте конфигуратор той базы, конфигурация которой станет эталонной, — обычно это центральная база разработки с актуальной версией. Убедитесь, что конфигурация базы данных обновлена и не содержит незакрытых изменений. Все остальные разработчики на время создания должны выйти из базы.
Перейдите в меню «Конфигурация → Хранилище конфигурации → Создать хранилище». Укажите путь к подготовленному каталогу (для файлового варианта) или адрес сервера хранилищ и имя хранилища (для TCP/HTTP). После подтверждения платформа поместит текущую конфигурацию в хранилище как первую версию — при большом размере конфигурации это может занять заметное время, не прерывайте процесс.
По завершении база автоматически окажется подключённой к хранилищу. Проверьте это: в меню «Конфигурация → Хранилище конфигурации» станут активны команды захвата, помещения и получения объектов, а в заголовке окна конфигуратора появится отметка о подключении.
- 1Подготовьте пустой каталог на сервере и настройте права доступа
- 2Откройте конфигуратор эталонной базы с правами администратора
- 3Выполните «Конфигурация → Хранилище конфигурации → Создать хранилище»
- 4Укажите путь к каталогу или адрес сервера хранилищ
- 5Дождитесь завершения помещения конфигурации в хранилище
- 6Проверьте, что команды работы с хранилищем стали доступны
Добавьте пользователей и настройте права
Сразу после создания в хранилище существует один пользователь — администратор, под которым выполнялось создание. Добавьте остальных разработчиков через «Конфигурация → Хранилище конфигурации → Администрирование хранилища» на вкладке «Пользователи». Для каждого задайте имя и пароль — они не связаны с пользователями информационных баз и заводятся отдельно.
Разграничьте права осознанно. Право захвата и помещения объектов нужно всем разработчикам, а право изменения версий хранилища, добавления пользователей и отмены захвата чужих объектов оставьте одному-двум администраторам. Отмена чужого захвата — частая причина конфликтов и потери несохранённой работы коллег, поэтому раздавать её всем не стоит.
Используйте осмысленные имена пользователей хранилища — по ним в истории версий будет видно, кто и когда менял каждый объект. Учётки вида user1, user2 через несколько месяцев сделают историю бесполезной для разбора изменений.
Подключите базы разработчиков
Каждый разработчик работает в собственной копии базы. Чтобы подключить её, откройте конфигуратор этой копии и выполните «Конфигурация → Хранилище конфигурации → Подключиться к хранилищу». Укажите тот же путь или адрес сервера, что и при создании, введите выданные администратором логин и пароль пользователя хранилища.
При подключении платформа сопоставит конфигурацию базы с версией в хранилище. Если копия делалась из эталонной базы, конфликтов не возникнет. Если конфигурации расходятся, надёжнее сначала загрузить в копию актуальную конфигурацию из хранилища командой «Обновить конфигурацию из хранилища», иначе часть локальных изменений может быть потеряна при первом получении.
После подключения проверьте работу механизма: захватите любой неиспользуемый объект, внесите тестовое изменение, поместите его в хранилище с комментарием и убедитесь, что соседняя база видит новую версию и может её получить. Комментарии к версиям делайте обязательной практикой — без них история изменений теряет смысл.
Как проверить результат
В конфигураторе активны команды захвата и помещения, отображается статус подключения
Команды хранилища неактивны или появляется ошибка доступа к каталогу
Объект помечается как захваченный текущим пользователем, коллеги видят блокировку
Объект захватывается у двух пользователей одновременно или захват не отображается у других
Новая версия появляется в истории с автором и комментарием
Версия не создаётся или автор отображается неверно
Настройте регламент и резервное копирование
Само по себе хранилище не требует обслуживания, но два регламентных действия стоит ввести сразу. Первое — резервное копирование каталога хранилища по расписанию, желательно ежедневно при активной разработке. Второе — периодическая проверка целостности: платформа позволяет выполнить тестирование хранилища при подозрении на ошибки, а при повреждении отдельных файлов помогает восстановление из копии.
Дополнительно полезно регламентировать рабочий процесс: перед помещением объектов в хранилище разработчик обновляет конфигурацию из хранилища и проверяет, что его изменения не конфликтуют с чужими, а в конце дня не оставляет захваченными объекты, над которыми работа завершена. Долго висящие захваты блокируют коллег и провоцируют аварийную отмену захвата администратором.
Если хранилище развёрнуто через файловый доступ, следите за свободным местом на диске: история версий растёт постоянно, и переполнение диска во время записи — один из сценариев повреждения хранилища.
Когда хранилище не нужно и какие есть альтернативы
Хранилище конфигурации оправдано, когда над конфигурацией работают двое и более разработчиков или ведётся параллельная разработка нескольких функциональностей. Если разработчик один, хранилище добавляет лишние действия на каждое изменение, и проще ограничиться регулярными выгрузками конфигурации в .cf как версионными снимками.
Для команд, использующих EDT, альтернативой служит связка 1C:EDT с Git: конфигурация хранится в Git-репозитории, что даёт ветвление, код-ревью и интеграцию с привычными инструментами разработки. Классическое хранилище при этом остаётся рабочим вариантом для команд, разрабатывающих в конфигураторе, и миграция на Git требует перестройки всего процесса, а не только смены инструмента.
Что важно запомнить
Хранилище создаётся из эталонной базы через «Создать хранилище» в заранее подготовленный каталог или на сервер хранилищ. Способ доступа выбирайте по инфраструктуре: сетевая папка — для малой локальной команды, TCP или HTTP — для удалённой работы. Обязательно настройте права пользователей и регулярное резервное копирование каталога хранилища.
Частые вопросы
Можно ли создать хранилище, не останавливая работу пользователей в базе?
Технически создание хранилища не требует монопольного доступа к базе, но на время процедуры стоит исключить внесение изменений в конфигурацию другими разработчиками. Пользователи в режиме предприятия могут продолжать работать — хранилище затрагивает только конфигурацию, а не данные.
Что делать, если хранилище повреждено после обрыва сети?
Сначала сделайте копию всего каталога хранилища в текущем состоянии, чтобы не усугубить ситуацию. Затем проверьте, открывается ли история и выполняется ли получение конфигурации. При ошибках восстановите каталог из последней резервной копии, а несохранённые в ней изменения разработчики смогут повторно поместить из своих локальных баз.
Нужно ли отключать базу от хранилища перед обновлением конфигурации поставщика?
Для типовых конфигураций на поддержке обновление выполняется штатно через поддержку, отключение не требуется. Отключать базу от хранилища нужно только при переносе базы в другую среду разработки или при смене хранилища — операция выполняется через «Отключиться от хранилища» и требует понимания, что связь версий будет потеряна.
Сколько места занимает хранилище и растёт ли оно?
Хранилище хранит все версии конфигурации, поэтому его размер постоянно увеличивается и обычно превышает размер самой конфигурации в разы при долгой истории. Конкретный объём зависит от размера конфигурации и интенсивности изменений — контролируйте свободное место на диске сервера.
Можно ли работать с хранилищем через интернет без VPN?
Да, для этого хранилище публикуется на веб-сервере (IIS или Apache) с обязательным использованием HTTPS и аутентификации. Публиковать хранилище по открытому HTTP нельзя — трафик и пароли пользователей хранилища передавались бы без шифрования.
Что произойдёт с локальными изменениями при подключении базы к хранилищу?
При подключении платформа сверяет конфигурацию базы с версией в хранилище. Незахваченные локальные изменения, расходящиеся с хранилищем, рискуют быть перезаписаны при первом обновлении из хранилища. Перед подключением сохраните важные доработки выгрузкой в файлы или перенесите их после подключения через захват объектов.