Хранилище конфигурации 1С: что это и как с ним работать

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

Физически хранилище — это файл с расширением .1cd, размещённый на общем сетевом ресурсе или доступный через сервер хранилища. Внутри него лежит полная структура конфигурации, история изменений по версиям и данные о том, кто какие объекты захватил. Разработчики подключаются к хранилищу из конфигуратора под своими учётными записями.

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

Зачем нужно хранилище и какую задачу оно решает

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

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

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

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

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

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

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

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

Как подключиться и работать с объектами

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

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

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

История версий и откат изменений

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

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

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

Ограничения хранилища и когда нужен Git

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

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

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

Хранилище 1С или Git с EDT

Хранилище конфигурации

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

1C:EDT + Git

Подходит для продуктовой разработки, параллельных версий и CI/CD. Ограничение: требует освоения EDT и инфраструктуры Git, не все сценарии конфигуратора перенесены.

Гибридная схема

Хранилище для типовой конфигурации и обновлений от поставщика, Git — для собственных доработок через выгрузку в файлы. Требует дисциплины синхронизации.

Типичные ошибки при работе с хранилищем

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

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

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

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

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

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

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

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

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

Норма

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

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

Команды хранилища неактивны — база не подключена

Блокировка объектов

Норма

Захваченный коллегой объект открывается только на чтение

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

Объект редактируется всеми — нарушена связь с хранилищем

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

Норма

Каждое помещение создаёт версию с автором и комментарием

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

Версии не фиксируются или автор везде один при работе нескольких человек

Часто задаваемые вопросы

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

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

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

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

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

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

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

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

Чем хранилище конфигурации отличается от выгрузки базы в .dt?

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

Почему при обновлении из хранилища появляются сообщения о расхождениях?

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