Хранилище конфигурации 1С: создание, пользователи и работа с версиями

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

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

Ниже — порядок действий от выбора размещения до разбора конфликтов. Пути приведены для платформы 8.3 с интерфейсом «Такси».

Что выбрать до создания: файловое или серверное размещение

Хранилище бывает двух видов, и это решают один раз, до создания.

Файловое — хранилище лежит в обычном каталоге (локальном или в сетевой папке). Подходит для одного-двух разработчиков или учебной работы. Плюс — ничего не нужно разворачивать: указали путь, и готово. Минус — надёжность и скорость упираются в файловую шару, а по медленной сети работа с большим хранилищем ощутимо тормозит.

Серверное — доступ идёт через отдельный сервер хранилища конфигурации (компонент платформы, устанавливается вместе с ней). Сервер запускают как службу или приложение, указав ему рабочий каталог под хранилища. Клиенты обращаются к нему по адресу вида tcp://сервер:порт, где порт выбирается при запуске сервера хранилища. Это вариант для команды: параллельная работа, устойчивость к обрывам сети, централизованные бэкапы.

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

Проверьте перед стартом несколько вещей:

• 📁 для файлового варианта — пустой каталог, к которому у всех разработчиков есть доступ на запись;
• 👤 у вас есть права сохранять конфигурацию в этой базе (вы её администратор или разработчик);
• 💾 сделана резервная копия информационной базы — создание хранилища меняет конфигурацию, и откатиться без копии будет нечем;
• 🔢 на всех рабочих местах стоит одна версия платформы: хранилище, созданное в более новой версии, старая платформа может не открыть.

Создание хранилища через мастер в Конфигураторе

Откройте базу в режиме Конфигуратор. Конфигурация должна быть сохранена (без несохранённых правок).

Дальше по шагам:

1. Меню Конфигурация → Хранилище конфигурации → Создать хранилище.
2. В поле адреса укажите размещение. Для файлового — путь к пустому каталогу (например, \\server\1c\storage или локальная папка). Для серверного — строку tcp://сервер:порт.
3. Задайте имя и пароль администратора хранилища. Это первая учётная запись, с которой вы потом будете заводить остальных. Запишите этот пароль: восстановить доступ к хранилищу без него штатными средствами нельзя.
4. Подтвердите создание. Платформа создаст структуру хранилища и предложит поместить в него текущую конфигурацию целиком — это и есть первая, нулевая версия.

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

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

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

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

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

Права в хранилище сводятся к нескольким уровням:

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

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

Первичная загрузка конфигурации и подключение рабочих мест

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

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

Теперь подключите остальных разработчиков. На каждом рабочем месте:

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

Не раздавайте всем копию базы администратора с его сохранённым паролем — каждый разработчик подключается под своей учётной записью. Иначе в истории все правки будут числиться за одним человеком.

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

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

Повседневная работа крутится вокруг двух команд: захватить объект и поместить изменения обратно.

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

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

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

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

Если захватили объект, но передумали менять, снимите блокировку командой Отменить захват. Тогда объект снова станет свободным для других, а ваши несохранённые правки по нему откатятся к версии из хранилища.

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

• захватываете ровно то, что собираетесь менять, и не держите объекты занятыми сутками;
• перед началом работы получаете свежую версию из хранилища, чтобы не разойтись с командой;
• помещаете изменения небольшими порциями с понятным комментарием.

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

История версий и сравнение редакций

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

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

Что даёт история на практике:

• 🔍 посмотреть, кто и когда правил конкретный объект;
• ↩️ получить из хранилища состояние объекта на нужную версию, если свежая правка оказалась ошибочной;
• 🧩 сравнить две версии между собой и увидеть построчную разницу.

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

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

Конфликты и типичные проблемы

Главный источник проблем в командной работе — попытка изменить то, что занято или уже изменено другим.

Ещё несколько ситуаций, которые экономят время:

• Разные версии платформы. Если коллега открыл хранилище на более новой платформе и поместил изменения, на старой версии хранилище может не открыться. Держите у всех платформу с номером не ниже согласованного.
• Долгий захват. Объект, захваченный и забытый на неделю, блокирует работу остальных по нему. Договоритесь в команде о правиле: не держать захват дольше, чем нужно на задачу.
• Файловая папка на медленной сети. Большое файловое хранилище по VPN работает медленно. Это повод перейти на серверное размещение, а не «терпеть».

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