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