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