Как устроена командная разработка в 1С через хранилище и захват объектов

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

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

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

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

Задачи, которые хранилище закрывает:

• 👥 Параллельная работа. Пять человек дорабатывают одну конфигурацию, не мешая друг другу.
• 🔒 Защита от затирания. Нельзя изменить объект, который захватил коллега.
• 🕓 История. Видно, кто, когда и с каким комментарием поменял модуль или форму.
• ↩️ Откат. Любую прошлую версию можно получить, сравнить с текущей или выгрузить в файл.
• 🏷️ Метки. Версию, ушедшую в рабочую базу, помечают меткой, например «Релиз 2.4».

Хранилище нужно и одиночке. Если вы дорабатываете типовую БП 3.0 под клиента, история версий сэкономит часы, когда через полгода спросят, зачем поменяли проведение реализации.

Как устроено хранилище конфигураций: архитектура и принцип работы

Из чего оно состоит

Физически хранилище — это каталог на диске. Главный файл — 1cv8ddb.1CD: база в формате файловой СУБД 1С, где лежат версии, пользователи и захваты. Рядом платформа держит служебные каталоги. Открывать и править эти файлы вручную нельзя — только через Конфигуратор.

Общая схема выглядит так:

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

Три способа доступа

Сервер хранилища — это служба crserver, которую ставит дистрибутив платформы, если отметить компонент «Сервер хранилища конфигураций 1С:Предприятия». Порт по умолчанию — 1542. Файл хранилища тогда читает только служба, а клиенты обмениваются с ней короткими сообщениями, а не гоняют по сети куски файла.

Версия crserver должна совпадать с версией платформы у разработчиков. Обновили платформу на рабочих местах — обновляйте и службу сервера хранилища.

Жизненный цикл изменения

1. Разработчик выделяет объект в дереве и выполняет «Захватить в хранилище». Рядом с объектом появляется отметка захвата.
2. Правит модуль, форму или реквизиты в своей базе.
3. Выполняет «Поместить в хранилище», пишет комментарий. Платформа создаёт новую версию с номером на единицу больше.
4. Коллеги выполняют «Получить из хранилища» или «Обновить конфигурацию из хранилища » и видят изменения у себя.

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

История версий и метки

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

Что можно сделать с любой версией из истории:

• 🔍 открыть состав изменений — какие объекты вошли в версию;
• ⚖️ сравнить её с текущей конфигурацией или с другой версией;
• 💾 сохранить конфигурацию этой версии в .cf-файл;
• 🏷️ поставить метку с понятным текстом.

Метка удобна для связки с выпусками. Например, версия 312 получила метку «Выпуск 2.4 — в работе с 14.03». Когда рабочая база начнёт вести себя странно, вы точно знаете, с какой версией сравнивать.

Чем хранилище 1С отличается от Git и других систем контроля версий

Главное отличие — модель блокировок. Git оптимистичен: правят все, конфликты сливают потом. Хранилище пессимистично: правит только тот, кто захватил.

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

Из-за отсутствия веток и код-ревью многие команды ведут хранилище и Git параллельно. Хранилище остаётся источником правды для Конфигуратора, а Git — зеркалом для анализа кода и проверки качества.

Как начать работу с хранилищем конфигурации: настройка по шагам

Шаг 1. Создать хранилище

1. Откройте эталонную базу в Конфигураторе. Ту, конфигурация которой станет первой версией.
2. Конфигурация → Хранилище конфигурации → Создать хранилище…
3. Укажите адрес: пустой каталог, tcp://srv:1542/имя или HTTP-адрес публикации.
4. Задайте первого пользователя и пароль. Он получит административные права в хранилище.

После создания эта база сразу подключена к хранилищу, а все объекты помещены в версию 1.

Шаг 2. Завести пользователей

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

У пользователя хранилища три группы прав: захват объектов, изменение состава версий (например, установка меток) и административные функции. Администраторов держите одного-двух.

Шаг 3. Подключить базы разработчиков

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

Шаг 4. Договориться о правилах

Типичные сбои при работе с хранилищем конфигурации

Большинство проблем связаны с захватами, версиями платформы и сетью. Выберите симптом:

Ещё одна частая беда — гигантский рост хранилища. Каждая версия хранит изменённые объекты целиком, а обновление типовой конфигурации поставщика затрагивает тысячи объектов. После десятка обновлений БП или ЗУП хранилище легко вырастает до десятков гигабайт. Держите под него диск с запасом и не ставьте его на тот же диск, что базы SQL.

Резервные копии и восстановление хранилища

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

Как сделать копию

1. Предупредите разработчиков: на время копирования не помещать изменения.
2. Для сервера хранилища — остановите службу crserver. Для файлового — убедитесь, что никто не выполняет операций.
3. Скопируйте каталог хранилища целиком, со всеми подкаталогами.
4. Запустите службу обратно.

Копирование «на ходу» без остановки может поймать файл в момент записи. Такая копия откроется с ошибкой.

Дополнительная страховка через пакетный режим

Помимо копии каталога, полезно регулярно выгружать последнюю версию в .cf. Это не заменяет копию с историей, но спасает конфигурацию при повреждении файла:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /F "D:\Bases\Dev" ^
 /ConfigurationRepositoryF "tcp://srv:1542/buh" ^
 /ConfigurationRepositoryN "backup" /ConfigurationRepositoryP "pass" ^
 /ConfigurationRepositoryDumpCfg "E:\Backup\buh_last.cf" ^
 /Out "E:\Backup\dump.log"

Номер платформы в пути замените на свой. Для служебной выгрузки заведите отдельного пользователя хранилища без права захвата.

Восстановление

• 🗂️ Каталог повреждён. Остановите службу, переложите каталог из копии, запустите службу. Разработчикам, которые помещали после момента копии, придётся поместить изменения заново.
• ↩️ Нужна старая версия. Откройте историю хранилища, выберите версию и сохраните её в .cf или сравните с текущей.
• 🧩 Нужно откатить один объект. В истории выберите версию, где объект был правильным, получите его, захватите и поместите как новую версию.

Перед восстановлением из копии сделайте копию текущего, пусть и битого, каталога. Иногда из него ещё удаётся достать последние версии.

Связь хранилища с Git, CI и внешними инструментами

Хранилище закрыто внутри Конфигуратора, но у платформы есть два моста наружу.

Пакетный режим Конфигуратора. Ключи /ConfigurationRepositoryF, /ConfigurationRepositoryN, /ConfigurationRepositoryP задают подключение, а дальше идут действия:

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

Выгрузка в файлы. Конфигурация → Выгрузить конфигурацию в файлы раскладывает метаданные по XML-файлам, а модули — по .bsl. Эти файлы уже можно положить в Git.

На этом построен открытый инструмент gitsync на OneScript. Он проходит по версиям хранилища, выгружает каждую в файлы и делает коммит с автором и комментарием из хранилища. В итоге в Git появляется полная история, по которой работают анализаторы кода и код-ревью.

Если команда готова уйти от Конфигуратора совсем, следующий шаг — 1С:EDT. Там основа — проект в файлах и Git, а хранилище не используется.

Частые вопросы о хранилище конфигурации