К статье
Практический материал

Разработка и Конфигурация · 11 мин

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

Как создать и настроить хранилище конфигурации 1С, подключить разработчиков, захватывать объекты, обновлять конфигурацию из хранилища и избегать типичных ошибок.

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

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

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

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

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

Хранилище необходимо, когда над конфигурацией работают два и более разработчика — это его основное назначение. Но оно полезно и для одиночной разработки: история версий работает как страховка от ошибочных изменений и заменяет ручное копирование cf-файлов «на всякий случай».

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

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

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

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

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

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

Захват, изменение и помещение объектов

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

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

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

Получение изменений и обновление конфигурации базы

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

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

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

Просмотр истории и работа с версиями

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

Сравнение версий — главный инструмент разбора инцидентов. Если после обновления перестал работать отчёт, сравните текущую версию с версией, где всё работало, и посмотрите, какие объекты затронуты. Для модулей доступно построчное сравнение текста.

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

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

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

Статус подключения
Норма

В меню хранилища активны команды захвата и помещения

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

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

Актуальность конфигурации
Норма

После «Получить из хранилища» список изменений пуст

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

Повторное получение снова предлагает те же объекты

Захваченные объекты
Норма

В дереве конфигурации видны пиктограммы захвата с вашим именем

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

Объект захвачен другим пользователем, который его не редактирует

Типичные ошибки и ограничения механизма

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

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

Ещё одно ограничение — производительность при большом количестве версий и пользователей через медленную сеть. В таких случаях хранилище размещают через веб-сервер или сервер хранилища, что заметно ускоряет операции получения и помещения.

Типичные ошибки
01
Работа всех разработчиков под одним пользователем хранилища — история изменений теряет смысл, виновника ошибки найти невозможно
02
Помещение изменений без комментария — через месяц никто не вспомнит, зачем менялся объект
03
Захват объектов «про запас» и надолго — коллеги не могут работать с нужными объектами
04
Редкое получение изменений — накапливаются конфликты, объединение превращается в ручную работу
05
Загрузка cf-файла поверх базы, подключённой к хранилищу, — разрыв связи и потеря синхронизации версий

Альтернативы и выбор подхода к версионированию

Стандартное хранилище — не единственный способ организовать совместную разработку. Для небольших команд из 2–5 человек, работающих последовательно над одной конфигурацией, его возможностей достаточно, а настройка занимает минуты. Для распределённых команд и параллельной разработки релизов чаще выбирают Git в связке с 1C:EDT, где доступны ветки, pull request и код-ревью.

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

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

Стандартное хранилище

Подходит небольшим командам в конфигураторе; простая настройка, но нет ветвления и код-ревью

1C:EDT + Git

Для крупных команд и параллельных релизов; требует перехода на EDT и освоения Git

Выгрузка в файлы + Git

Компромисс для конфигуратора; даёт историю в Git, но операции выполняются вручную

Без версионирования (обмен cf)

Допустимо только для одиночной разработки; высокий риск потери изменений

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

Можно ли подключить к хранилищу базу, в которой уже есть доработки?

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

Что делать, если объект захвачен уволившимся сотрудником?

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

Хранилище заменяет резервное копирование базы?

Нет. Хранилище содержит только конфигурацию и её историю, но не данные информационной базы. Резервное копирование (выгрузка в dt или средствами СУБД) должно выполняться независимо и регулярно.

Почему после помещения в хранилище изменения не видны в режиме предприятия?

Помещение в хранилище меняет только основную конфигурацию. Чтобы изменения заработали в пользовательском режиме, нужно выполнить «Обновить конфигурацию базы данных» (клавиша F7 в конфигураторе) и при необходимости перезапустить сеансы пользователей.

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

Да. Хранилище можно опубликовать через веб-сервер (с использованием расширения веб-сервера 1С) или развернуть отдельный сервер хранилища. Это также ускоряет работу по сравнению с доступом через медленный сетевой каталог.

Как перенести хранилище на другой сервер?

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

Итог

Что важно запомнить

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