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

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

Хранилище конфигурации 1С: как оно работает

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

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

Физически хранилище представляет собой набор служебных файлов в отдельном каталоге (файловый вариант) либо данные, размещённые через сервер 1С или веб-сервер. Главный файл каталога хранилища — 1cv8ddb.1cd, в нём платформа хранит версии конфигурации, сведения о пользователях хранилища и состояние захваченных объектов. Каждое помещение изменений создаёт новую версию с номером, комментарием и автором.

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

Как устроено хранилище и что в нём хранится

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

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

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

Как создать хранилище и подключиться к нему

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

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

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

Для распределённой команды файловый доступ по сети — самый простой, но самый уязвимый вариант: обрыв соединения в момент записи может повредить файлы хранилища. Более надёжные варианты — публикация хранилища через веб-сервер (HTTP/HTTPS) или использование сервера хранилища на платформе 8.3.

Захват, изменение и помещение объектов

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

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

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

Версии, история и откат изменений

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

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

Права пользователей и администрирование

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

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

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

Хранилище и внешние системы контроля версий

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

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

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

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

Простейший вариант для 2–5 разработчиков в одном офисе; уязвим к обрывам сети и требует общего доступа к каталогу

Хранилище через веб-сервер

Подходит для удалённой команды; требует настройки публикации, но устойчивее к проблемам сети

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

Централизованный вариант для нескольких хранилищ и большего числа пользователей; нужна отдельная служба

Git + EDT / выгрузка в файлы

Для зрелых процессов с ветками и ревью; требует перестройки привычного цикла работы и дисциплины команды

Как проверить, что работа с хранилищем настроена правильно

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

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

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

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

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

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

Конфигурация редактируется свободно — подключение не выполнено или потеряно

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

Захваченный объект помечен в дереве, другие пользователи видят владельца захвата

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

Захват не отображается у коллег — проблемы с доступом к каталогу хранилища

Помещение и получение
Норма

После помещения версия появляется в истории с комментарием, коллеги получают изменения

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

Версия не создаётся или коллеги не видят изменений после получения

Резервная копия
Норма

Каталог хранилища входит в расписание бэкапов, копия проверена восстановлением

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

Копии нет или она старше недели при активной разработке

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

Частые вопросы о хранилище конфигурации 1С

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

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

Что делать, если хранилище повреждено?

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

Можно ли подключить одну базу к другому хранилищу?

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

Почему коллега не видит мои помещённые изменения?

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

Нужно ли захватывать всю конфигурацию целиком?

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

Чем хранилище отличается от поддержки у поставщика?

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

Итог

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

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