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