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