Разработка и Конфигурация · 11 мин
Хранилище конфигурации 1С: что это и как с ним работать
Что такое хранилище конфигурации в 1С, зачем оно нужно, как создать, подключиться, захватывать объекты и обновлять конфигурацию из хранилища.
Хранилище конфигурации в 1С — это централизованный репозиторий, в котором платформа сохраняет историю изменений конфигурации и координирует работу нескольких разработчиков над одной базой. Без хранилища два программиста могут одновременно изменить один и тот же объект, и чьи-то правки безвозвратно потеряются. С хранилищем каждый объект перед редактированием «захватывается», а платформа блокирует его для остальных участников команды.
Механизм встроен в платформу 1С:Предприятие и не требует покупки отдельных продуктов. Хранилище представляет собой каталог с файлами (в классическом варианте) или базу данных на сервере 1С (в клиент-серверном режиме хранения). Для небольших команд из двух-пяти разработчиков это самый простой способ организовать совместную разработку без внешних систем контроля версий.
Важно понимать: хранилище конфигурации — это не резервная копия базы данных и не замена Git. Оно хранит только конфигурацию (метаданные, модули, формы), но не пользовательские данные информационной базы. Для защиты данных по-прежнему нужны регулярные выгрузки и бэкапы средствами СУБД.
Что такое хранилище конфигурации и как оно устроено
Хранилище конфигурации — это набор файлов, в которых платформа фиксирует каждую сохранённую версию конфигурации. Каждая версия имеет номер, автора, дату и комментарий. В любой момент можно посмотреть, кто и когда менял конкретный объект, сравнить версии между собой и при необходимости откатиться к предыдущему состоянию.
Физически хранилище чаще всего размещают в сетевой папке, доступной всем разработчикам. Основные файлы — 1cv8ddb.1CD (таблицы хранилища) и служебные файлы в подкаталогах. Удалять или редактировать эти файлы вручную нельзя: это почти гарантированно приведёт к повреждению хранилища.
Ключевое понятие механизма — захват объекта. Пока объект захвачен одним разработчиком, остальные могут его просматривать, но не могут изменять. После завершения работы объект либо помещается в хранилище вместе с изменениями, либо захват отменяется, и правки отбрасываются.
Когда хранилище нужно, а когда можно обойтись без него
Хранилище оправдано, когда над конфигурацией работают два и более разработчика, либо когда один разработчик ведёт параллельно несколько направлений доработок и хочет иметь историю версий. Также оно полезно, если заказчик требует прослеживаемости изменений: кто, когда и зачем изменил конкретный объект.
Единственному разработчику, который ведёт одну доработку за раз, хранилище часто избыточно — достаточно периодических выгрузок конфигурации в файлы .cf или в файлы конфигурации (XML-выгрузка). Крупные команды с ветвлением и код-ревью чаще выбирают EDT с Git, потому что классическое хранилище не поддерживает ветки.
Способы организации версионирования
Подходит командам до 5–10 разработчиков в конфигураторе. Ограничение: нет ветвей, последовательная модель захвата объектов.
Подходит крупным командам, нужны ветки, merge и code review. Ограничение: требует перехода на EDT и освоения Git.
Подходит одиночному разработчику. Ограничение: нет защиты от одновременного редактирования и истории авторства.
Как создать хранилище конфигурации
Создание выполняется из конфигуратора той базы, конфигурацию которой вы хотите поместить в хранилище. Перед началом убедитесь, что в базе нет других активных сеансов конфигуратора и что у вас есть права администратора конфигурации.
- 1Создайте пустой сетевой каталог, доступный всем разработчикам на чтение и запись.
- 2Откройте конфигуратор базы-источника с полными правами.
- 3Выберите меню «Конфигурация → Хранилище конфигурации → Создать хранилище».
- 4Укажите путь к каталогу, задайте имя и пароль пользователя-администратора хранилища.
- 5Дождитесь завершения помещения конфигурации — платформа создаст первую версию.
- 6Проверьте: в меню «Хранилище конфигурации» появились пункты «Захватить», «Поместить», «История хранилища».
После создания текущая конфигурация базы автоматически подключается к хранилищу. Пароль администратора хранилища сохраните отдельно: без него невозможно управлять пользователями хранилища и выполнять административные операции, а штатного механизма восстановления пароля нет.
Как подключиться к хранилищу и настроить пользователей
Каждый разработчик работает со своей копией информационной базы (обычно файловой), подключённой к общему хранилищу. Подключение выполняется через «Конфигурация → Хранилище конфигурации → Подключиться к хранилищу»: указывается путь к каталогу хранилища, имя и пароль пользователя хранилища.
Пользователей хранилища заводит администратор через пункт «Администрирование хранилища → Пользователи». Для каждого разработчика создаётся отдельная учётная запись — это важно для истории изменений и для разграничения прав. Работа всех под одним логином делает журнал версий бессмысленным.
При подключении платформа предложит загрузить конфигурацию из хранилища в базу. Соглашайтесь, если локальная база новая или вы хотите гарантированно получить актуальное состояние. Внимание: загрузка заменит текущую конфигурацию базы, поэтому несохранённые локальные правки будут потеряны.
Ежедневный цикл работы: захват, изменение, помещение
Типовой рабочий день разработчика с хранилищем выглядит так: в начале дня — обновление конфигурации из хранилища, чтобы получить чужие изменения; затем захват нужных объектов, редактирование, тестирование на своей базе и помещение изменений обратно с осмысленным комментарием.
Захватывать объекты можно двумя способами: по одному через контекстное меню объекта или массово через окно «Работа с хранилищем конфигурации». При захвате ставьте флажок «получать захваченные» — тогда вы сразу получите актуальную версию объекта, а не ту, что осталась в вашей базе с прошлого сеанса.
Комментарий при помещении — не формальность. Через полгода по фразе «исправил ошибку» невозможно понять, что именно менялось. Пишите суть: «Исправлен расчёт скидки при частичной оплате, задача №…». Это сильно упрощает поиск по истории хранилища.
Обновление конфигурации базы из хранилища
Обновление выполняется через «Конфигурация → Хранилище конфигурации → Обновить конфигурацию из хранилища». Платформа покажет список объектов, различающихся между вашей базой и хранилищем, и предложит выбрать режим объединения. Для объектов, которые вы не захватывали, обычно безопасен режим «Загрузить из хранилища».
Если объект захвачен вами и при этом изменён в хранилище другим разработчиком, платформа предложит объединение. Здесь нужна внимательность: автоматическое объединение модулей может дать синтаксически корректный, но логически неверный результат. После объединения обязательно проверьте модуль и прогоните ключевой сценарий.
Как проверить результат обновления
Все объекты без пометок конфликта, конфигурация обновляется без ошибок
Платформа сообщает о конфликтах версий или не даёт обновить конфигурацию БД
Проверка конфигурации проходит без ошибок
Ошибки компиляции в объединённых модулях
Изменённый функционал отрабатывает как ожидалось
Поведение изменилось после объединения чужих правок
Обслуживание хранилища и типичные проблемы
Со временем хранилище растёт: каждая версия конфигурации занимает место. Если история старых версий не нужна, её можно сократить через администрирование хранилища с указанием номера версии, до которой выполняется сокращение. Операцию делайте в момент, когда никто не работает с хранилищем, и предварительно скопируйте каталог хранилища целиком.
Частая проблема — «зависшие» захваты: разработчик уволился или его сеанс завершился аварийно, а объекты остались захваченными. Администратор хранилища может отменить чужой захват через окно работы с хранилищем. Перед отменой убедитесь, что коллега действительно не работает с объектом, иначе его несохранённые изменения конфликтуют с вашими.
Если хранилище недоступно (лежит сетевая папка), конфигуратор позволяет работать автономно, но захватывать и помещать объекты нельзя. Не пытайтесь обойти это копированием файлов хранилища в другое место «на время» — при восстановлении доступа получите два расходящихся хранилища.
Как выбрать действие
Частые вопросы о хранилище конфигурации
Можно ли подключить к одному хранилищу несколько разных конфигураций?
Нет. Одно хранилище обслуживает одну конфигурацию. К нему подключаются разные базы разработчиков, но все они содержат версии одной и той же конфигурации. Для другой конфигурации создаётся отдельное хранилище.
Что делать, если забыт пароль администратора хранилища?
Штатного способа восстановления нет. Практический вариант — создать новое хранилище из актуальной конфигурации базы и заново завести пользователей. История версий при этом будет потеряна, поэтому пароль администратора нужно хранить в надёжном месте.
Можно ли работать с хранилищем через интернет, а не по локальной сети?
Да, через сервер хранилища 1С (отдельный компонент платформы) хранилище публикуется по протоколу TCP или HTTP, и разработчики подключаются удалённо. Для небольших команд в одном офисе обычно достаточно сетевой папки.
Чем хранилище конфигурации отличается от Git?
Хранилище — встроенный механизм платформы с последовательной моделью: объект захватывается одним человеком, ветвей нет. Git — распределённая система с ветвлением и слиянием, но для работы с ней конфигурацию нужно выгружать в файлы (EDT делает это штатно). Хранилище проще в освоении, Git гибче для крупных команд.
Нужно ли отключать пользователей базы при работе с хранилищем?
Само хранилище работает с конфигурацией и не требует отключения пользователей. Но обновление конфигурации базы данных (реструктуризация) после загрузки изменений требует монопольного доступа — на этот момент пользователей нужно вывести из базы.
Можно ли посмотреть, кто изменил конкретную строку модуля?
Через «Историю хранилища» по объекту видно, кто и в какой версии менял объект, а сравнение версий покажет изменённые строки модуля. Точности «по строке с автором», как blame в Git, нет, но связка истории и сравнения версий обычно позволяет найти автора правки.
Что важно запомнить
Хранилище конфигурации 1С — встроенный репозиторий версий с захватом объектов для совместной разработки. Создаётся из конфигуратора в сетевом каталоге, требует отдельных учётных записей для каждого разработчика и дисциплины: обновился → захватил → изменил → поместил с комментарием. Данные базы оно не защищает — резервные копии нужны отдельно.