Разработка и Конфигурация · 12 мин
Хранилище конфигурации 1С: что это и как с ним работать
Хранилище конфигурации 1С — что это, зачем нужно, как создать, подключиться и работать с версиями. Разбираем захват объектов, типичные ошибки и альтернативы.
Хранилище конфигурации — это встроенный в платформу 1С:Предприятие механизм коллективной разработки, который хранит историю изменений конфигурации и управляет доступом разработчиков к объектам метаданных. По сути, это система контроля версий, специально адаптированная под структуру 1С: вместо файлов с кодом она оперирует объектами конфигурации — справочниками, документами, отчётами, модулями.
Механизм решает две задачи. Первая — предотвращение конфликтов: пока один разработчик редактирует объект, он «захватывает» его, и остальные не могут изменить тот же объект, пока захват не снят. Вторая — история версий: каждая помещённая в хранилище версия конфигурации сохраняется, и в любой момент можно посмотреть, кто и что изменил, сравнить версии или откатиться к предыдущему состоянию.
Хранилище применяется как в командах из нескольких разработчиков, так и при работе одного специалиста — в этом случае оно выступает надёжным архивом изменений. Ниже разберём, как устроен механизм, как его создать и подключить, какие правила работы помогают избежать потери данных и когда хранилище стоит заменить альтернативными инструментами.
Как устроено хранилище конфигурации
Физически хранилище — это файл с расширением 1CD (по умолчанию имя вида 1cv8ddb.1cd), который платформа создаёт в указанном каталоге. Формат файла аналогичен формату файловой информационной базы: внутри находятся все версии конфигурации, данные о пользователях хранилища и служебная информация о захваченных объектах.
Каждая информационная база может быть подключена к одному хранилищу. При этом конфигурация базы, подключённой к хранилищу, считается «подчинённой»: её нельзя изменить напрямую, минуя механизм захвата. Попытка отредактировать объект без захвата приведёт к тому, что изменения либо не сохранятся, либо будут выполнены в обход хранилища — что создаёт рассинхронизацию и проблемы при обновлении.
Ключевые операции с хранилищем: захват объектов для редактирования, помещение изменённых объектов (создаёт новую версию), получение изменений из хранилища в свою базу, сравнение и объединение конфигураций, просмотр истории версий. Все они доступны в конфигураторе через меню «Конфигурация — Хранилище конфигурации».
Когда хранилище нужно, а когда можно обойтись без него
Хранилище практически обязательно, если над одной конфигурацией работают два и более разработчика. Без него правки придётся передавать файлами cf и вручную объединять, что при параллельной работе почти гарантированно приводит к потере изменений одного из участников.
Одиночному разработчику хранилище тоже полезно: оно даёт автоматическую историю версий без ручного копирования cf-файлов и позволяет быстро вернуться к работающему состоянию после неудачной доработки. Однако если конфигурация типовая, обновляется только штатно и не дорабатывается, подключать хранилище не нужно — оно лишь усложнит обновление.
Как выбрать действие
Как создать хранилище и подключить базу
Создание выполняется из конфигуратора той базы, конфигурация которой станет начальной версией хранилища. Откройте меню «Конфигурация — Хранилище конфигурации — Создать хранилище», укажите каталог и имя файла хранилища, задайте имя и пароль администратора хранилища. Платформа создаст файл и поместит в него первую версию конфигурации.
Каталог хранилища должен быть доступен всем разработчикам. На практике используют два варианта размещения: сетевой файловый ресурс (общая папка) либо публикацию через сервер хранилищ 1С (crserver) по протоколу tcp или http. Файловый вариант проще в развёртывании, но при большом числе пользователей и активной работе сервер хранилищ даёт более стабильный доступ и меньше рисков повреждения файла из-за сетевых сбоев.
Подключение остальных баз выполняется через пункт «Подключиться к хранилищу»: указывается путь к хранилищу, имя и пароль пользователя. Пользователей хранилища заводит администратор через пункт «Администрирование — Пользователи» в меню хранилища — это отдельная учётная система, не связанная с пользователями информационной базы.
- 1Сделайте резервную копию информационной базы (выгрузку в dt)
- 2Откройте конфигуратор: Конфигурация — Хранилище конфигурации — Создать хранилище
- 3Укажите каталог, имя файла, логин и пароль администратора хранилища
- 4Дождитесь завершения помещения первой версии конфигурации
- 5Создайте пользователей хранилища через Администрирование — Пользователи
- 6Подключите базы разработчиков через Подключиться к хранилищу
- 7Проверьте: статус подключения виден в окне хранилища, объекты доступны для захвата
Как работать с объектами: захват, изменение, помещение
Базовый цикл работы выглядит так. Перед началом правок разработчик обновляет конфигурацию базы из хранилища, чтобы работать с актуальным состоянием. Затем захватывает нужные объекты — в окне захвата можно выбрать конкретные справочники, документы, модули. После захвата объекты редактируются обычным образом.
Завершив правки и проверив их в своей базе, разработчик выполняет помещение объектов в хранилище. Платформа создаёт новую версию конфигурации, в которую входят все помещённые изменения. К помещению стоит добавлять осмысленный комментарий — он сохраняется в истории версий и сильно упрощает поиск нужного изменения позже.
Если правки оказались ошибочными, захват можно отменить: объект вернётся к состоянию из хранилища, а изменения в локальной базе будут потеряны. Это безопасный способ «откатить» эксперимент, не затрагивая других участников.
История версий, сравнение и откат
История хранилища открывается через пункт «История хранилища» и показывает список версий с датой, автором и комментарием. По каждой версии можно посмотреть, какие объекты изменились, и выполнить детальное сравнение — вплоть до построчного сравнения текстов модулей между двумя версиями.
Для отката используется загрузка конфигурации из хранилища выбранной версии в отдельную базу: из неё можно выгрузить нужные объекты или вернуть состояние целиком. Прямой кнопки «вернуться к версии N» в хранилище нет, поэтому откат делается через сравнение и перенос объектов — этот момент стоит учитывать при планировании аварийного восстановления.
Как проверить результат
В окне сообщений нет ошибок, конфигурация базы успешно обновлена
Ошибки обновления, объекты остались в старом состоянии
Захваченные вами объекты отмечены соответствующим признаком
Объект захвачен другим пользователем, а вы его редактируете
Новая версия появилась с вашим комментарием и списком объектов
Версия не создалась или в ней нет ожидаемых объектов
Типичные ошибки и риски при работе с хранилищем
Самая частая проблема — «зависшие» захваты: разработчик захватил объект и ушёл в отпуск, не поместив и не отменив захват. Разблокировать такой объект может администратор хранилища через отмену захвата от имени пользователя, но при этом несохранённые в хранилище правки того сотрудника будут потеряны.
Вторая группа ошибок связана с обходом механизма: изменение объектов без захвата, загрузка cf-файлов в подключённую к хранилищу базу, отключение от хранилища «для быстрой правки». Всё это приводит к расхождению конфигурации базы и хранилища, и восстановление консистентности может потребовать полного переподключения базы с потерей локальных изменений.
Резервное копирование и обслуживание хранилища
Файл хранилища — единственная точка отказа всей истории разработки, поэтому его нужно включать в регулярное резервное копирование. Для файлового варианта достаточно копировать 1CD-файл в период, когда с хранилищем никто не работает, либо использовать механизмы снапшотов файловой системы. Для сервера хранилищ резервная копия снимается средствами СУБД или копированием каталога данных сервера.
Со временем файл хранилища разрастается, так как хранит все версии конфигурации. Платформа позволяет сократить историю: при сохранении хранилища в файл можно указать номер версии, начиная с которой сохранять данные. Старые версии при этом удаляются безвозвратно — перед сокращением истории убедитесь, что архивная копия полного хранилища сохранена.
Полезно договориться в команде о простых правилах: помещать изменения не реже раза в день, обновляться из хранилища каждое утро, перед захватом корневых объектов (общих модулей, ролей) предупреждать коллег. Такие договорённости снижают число конфликтов сильнее, чем любые технические настройки.
Альтернативы хранилищу: EDT и Git
Классическое хранилище имеет ограничения: нет ветвления и слияния веток, нет удобного код-ревью, блокировочная модель захвата плохо подходит для параллельной разработки разных функций. Для проектов, где эти возможности критичны, фирма «1С» предлагает среду 1C:EDT, которая работает с конфигурацией как с набором файлов и интегрируется с Git.
Переход на EDT и Git даёт ветки, merge-запросы и интеграцию с системами сборки, но требует перестройки процессов: команда должна освоить Git, а конфигурация — соответствовать требованиям EDT. Для небольших команд и поддержки существующих решений классическое хранилище остаётся простым и достаточным инструментом.
Сравнение вариантов
Встроено в платформу, простое освоение, захват объектов исключает конфликты. Ограничения: нет веток и код-ревью, блокировочная модель
Ветвление, слияние, ревью, интеграция с CI. Требует освоения Git и адаптации конфигурации под формат EDT
Промежуточный вариант: история в Git, разработка в конфигураторе. Сложнее синхронизация, возможны конфликты форматов
Что важно запомнить
Хранилище конфигурации — встроенная система контроля версий 1С с механизмом захвата объектов. Работайте по циклу «обновление — захват — изменение — помещение», помещайте изменения часто и с комментариями, регулярно копируйте файл хранилища. Для ветвления и код-ревью рассмотрите переход на EDT с Git.
Частые вопросы
Можно ли подключить одну базу к двум хранилищам?
Нет, информационная база одновременно подключается только к одному хранилищу. Если нужно перенести конфигурацию в другое хранилище, базу отключают от текущего, после чего подключают к новому. При отключении связь с историей версий старого хранилища теряется, поэтому перед переключением сохраните резервные копии и сам файл хранилища.
Что делать, если разработчик уволился, а объекты остались захвачены?
Администратор хранилища может отменить захват от имени любого пользователя через функции администрирования хранилища. Учтите: все изменения, которые уволившийся сотрудник не поместил в хранилище, при этом будут потеряны. Если его база ещё доступна, сначала попробуйте поместить объекты из неё.
Влияет ли хранилище на работу пользователей в режиме Предприятия?
Нет, хранилище используется только на этапе разработки в конфигураторе. Пользователи рабочей базы никак не взаимодействуют с хранилищем. Обычно разработку ведут в отдельных копиях базы, а в рабочую базу изменения переносят через обновление конфигурации после тестирования.
Как перенести хранилище на другой сервер?
Для файлового варианта достаточно скопировать файл хранилища в новый каталог и переподключить базы разработчиков, указав новый путь. При использовании сервера хранилищ переносится каталог данных сервера либо хранилище предварительно сохраняется в файл и разворачивается на новом месте. Перед переносом все пользователи должны завершить работу с хранилищем.
Можно ли восстановить удалённую версию из хранилища?
Нет, удалённые при сокращении истории версии восстановлению из самого хранилища не подлежат. Единственный способ вернуть их — восстановить файл хранилища из резервной копии. Поэтому перед любым сокращением истории обязательно снимайте полную копию файла хранилища.
Нужно ли хранилище для внешних обработок и отчётов?
Хранилище конфигурации работает только с объектами самой конфигурации — внешние обработки и отчёты в него не помещаются. Для них используют обычные файловые архивы, Git-репозитории или выгрузку в исходные файлы через EDT. Часто внешние инструменты хранят рядом с хранилищем в отдельном каталоге с собственной историей.