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

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

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

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

Что такое хранилище конфигурации и когда оно нужно

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

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

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

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

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

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

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

1. 1
   Сделайте резервную копию базы (выгрузку .dt или .cf)
2. 2
   Откройте Конфигуратор под пользователем с полными правами
3. 3
   Выберите Конфигурация → Хранилище конфигурации → Создать хранилище
4. 4
   Укажите пустой сетевой каталог для хранилища
5. 5
   Задайте логин и пароль администратора хранилища
6. 6
   Дождитесь завершения выгрузки конфигурации в хранилище
7. 7
   Проверьте, что база подключена: статус виден в окне хранилища

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

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

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

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

Захват объектов и внесение изменений

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

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

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

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

Помещение изменений и обновление из хранилища

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

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

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

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

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

Версия в хранилище

Норма

После помещения номер версии увеличился, комментарий отображается в истории

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

Версия не изменилась или помещение завершилось ошибкой

Статус объектов

Норма

Изменённые объекты освобождены или захвачены вами, пиктограммы корректны

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

Объект остался захваченным коллегой, хотя он его поместил

Обновление базы

Норма

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

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

Платформа сообщает о расхождении версий или требует объединения

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

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

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

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

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

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

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

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

Альтернативы: EDT, Git и внешние средства

Штатное хранилище конфигурации — не единственный способ версионирования в экосистеме 1С. Среда разработки 1C:Enterprise Development Tools (EDT) изначально построена вокруг Git: конфигурация хранится в виде текстовых файлов проекта, а работа с версиями идёт через стандартные механизмы Git — ветки, слияния, pull request. Для крупных команд и сложных проектов это более гибкий подход.

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

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

Штатное хранилище конфигурации

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

EDT + Git

Подходит крупным командам и проектам с параллельной разработкой. Ветки, слияния, интеграция с CI. Требует перехода на EDT и освоения Git.

XML-выгрузка + Git

Компромисс для работы в Конфигураторе с хранением истории в Git. Требует дисциплины и скриптов выгрузки/загрузки.

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

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

Да. Хранилище можно опубликовать на веб-сервере (IIS или Apache) с помощью специального расширения веб-сервера платформы. Подключение тогда выполняется по адресу вида http://сервер/хранилище. Это стандартное решение для распределённых команд и удалённых разработчиков.

Что делать, если забыт пароль пользователя хранилища?

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

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

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

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

Жёсткого ограничения платформа не накладывает, но на практике при большом числе участников растут конфликты захватов и время операций. Для команд, где над одной подсистемой одновременно трудятся многие разработчики, стоит рассмотреть переход на EDT с Git, где параллельная работа организована через ветки.

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

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