Командная разработка в 1С 8.3: как устроено хранилище конфигурации и как вести в нём доработки

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

Без хранилища двое программистов, которые правят одну базу, рано или поздно затирают работу друг друга. С хранилищем видно, кто что держит, когда и зачем менял, и любую прошлую версию можно достать за пару минут. Механизм общий для платформы 8.3 и не зависит от конфигурации: одинаково работает с БП, ЗУП, УТ и самописными решениями.

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

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

Три варианта размещения:

Файловое хранилище — это каталог с файлом 1cv8ddb.1CD и служебными данными. Сервер хранилища ставится отдельным компонентом из дистрибутива платформы и работает как служба. По умолчанию он слушает порт 1542.

Принцип работы — блокирующий, а не «правь что хочешь, потом сольём»:

• 🔒 объект можно менять, только если он захвачен вами;
• 👀 захваченный объект у остальных доступен только для чтения;
• 📦 помещение создаёт новую версию с номером, автором, датой и комментарием;
• ⬇️ чужие изменения попадают к вам командой получения из хранилища.

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

Создание хранилища, пользователи и права доступа

Создание

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

После этого текущая база уже подключена к хранилищу, а версия 1 содержит всю конфигурацию.

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

Пользователи и права

Пользователи хранилища не связаны с пользователями информационной базы. Их заводят в Конфигурация → Хранилище конфигурации → Администрирование на закладке пользователей.

Права выдаются флажками:

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

Подключение второго разработчика

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

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

Ежедневная работа: захват, правка и помещение изменений в хранилище

Рабочий цикл короткий и повторяется десятки раз в день.

Захват объектов

Выделите объект в дереве конфигурации, в контекстном меню выберите Захватить в хранилище. В диалоге два важных флажка:

• ✅ получать захваченные объекты — перед захватом подтянуть свежую версию объекта из хранилища. Отключать не стоит, иначе вы будете править устаревшую копию;
• 🌳 рекурсивно — захватить объект вместе с подчинёнными: формами, макетами, командами.

У захваченного объекта в дереве появляется зелёный значок замка. Объект, захваченный кем-то другим, отмечен красным.

Правка и проверка

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

Помещение

Команда Поместить в хранилище (контекстное меню или меню хранилища). В диалоге:

• 📝 впишите комментарий — номер задачи и суть: «#1452 Добавлен реквизит Проект в Заказ клиента »;
• 🔓 флажок оставить объекты захваченными — если работа не закончена, а промежуточный результат надо сохранить;
• 📋 проверьте список объектов — туда должно попасть всё, что связано с изменением.

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

Получение чужих изменений

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

Отмена захвата

Если правка не пошла, объект отпускают командой Отменить захват. Платформа спросит, вернуть ли объект к версии из хранилища. Ответ «да» откатит ваши локальные изменения по этому объекту.

История версий: сравнение и разбор расхождений

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

Метки — недооценённый инструмент. Когда в истории 3 000 версий, найти «то, что стоит в рабочей базе» по меткам гораздо быстрее, чем по датам.

Сравнение своей базы с хранилищем

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

Когда возникает конфликт

Блокировки не дают двоим править один объект одновременно, поэтому конфликтов в привычном смысле меньше, чем в Git. Они всё же бывают:

• 🔁 вы правили объект без захвата (база была отключена или захват сняли администратором), а в хранилище по нему уже есть новая версия;
• 📥 при обновлении из хранилища у вас есть незахваченные локальные правки;
• 🧩 переносите изменения из другого хранилища или из .cf.

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

Ветки и поддержка релизов при работе с хранилищем

Встроенных веток у хранилища нет: это одна линия версий. Ветвление строят несколькими хранилищами.

Рабочая схема для команды, у которой есть рабочая база и параллельная разработка:

1. 🟢 Хранилище релиза — точная копия того, что работает у пользователей. Сюда попадают только срочные исправления.
2. 🔵 Хранилище разработки — новая функциональность, которая выйдет в следующем релизе.
3. 🔄 Срочное исправление делают в хранилище релиза, ставят метку, выпускают .cf в рабочую базу, затем переносят ту же правку в хранилище разработки через сравнение-объединение.
4. 🚀 Когда разработка готова, её .cf объединяют с хранилищем релиза, ставят метку нового релиза.

Для каждой крупной доработки, которая идёт несколько недель, можно завести своё хранилище от копии хранилища разработки. Минус схемы — ручной перенос изменений, поэтому чем меньше параллельных хранилищ, тем легче жить.

Обновление типовой конфигурации на поддержке

Когда в хранилище лежит типовая конфигурация с доработками, обновление поставщика проходит так:

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

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

Расширения и Git

Расширения конфигурации тоже подключаются к своему хранилищу — правки в расширении версионируются отдельно от основной конфигурации.

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

Обслуживание и резервное копирование хранилища

Хранилище — такая же ценность, как рабочая база: в нём вся история доработок.

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

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

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

Частые вопросы