При переходе от одиночной разработки к командной многие начинающие специалисты сталкиваются с заблуждением: кажется, что достаточно создать хранилище конфигурации прямо в рабочей базе или одной общей копии, после чего несколько программистов смогут одновременно открыть конфигуратор и работать вместе. Однако платформа 1С блокирует попытку одновременного запуска второго сеанса конфигуратора для одной и той же информационной базы. Разберем архитектурные принципы работы механизма совместной разработки, выясним, как правильно организовать рабочие места, а также рассмотрим особенности администрирования хранилища конфигурации.
Почему нельзя открыть два конфигуратора в одной информационной базе
Информационная база 1С на уровне платформы проектируется с расчетом на то, что режим конфигуратора является монопольным по отношению к структуре метаданных. При открытии конфигуратора накладывается эксклюзивная системная блокировка на изменение схемы данных и конфигурации базы данных. Если бы два разработчика одновременно правили одну и ту же базу через разные окна конфигуратора, это привело бы к взаимным блокировкам, разрушению таблиц метаданных и повреждению таблиц базы данных в СУБД.
Иногда системные администраторы и разработчики пытаются обойти это ограничение, регистрируя одну физическую базу данных в SQL на двух разных кластерах серверов 1С или под разными именами. Делать это категорически нельзя, так как это приводит к разрушению уникальных идентификаторов (UUID), повреждению кэша метаданных и полной потере согласованности данных.
Правильная архитектура совместной разработки
Смысл хранилища конфигурации заключается в синхронизации исходного кода и метаданных между независимыми информационными базами разработчиков, а не в совместном доступе к одному конфигуратору. Разберем стандартную схему организации рабочих мест:
Создание эталонного хранилища: создается центральное хранилище конфигурации (на сервере хранилища 1С или в сетевом каталоге), содержащее базовую версию конфигурации проекта.
Развертывание баз для разработчиков: каждый программист получает свою собственную изолированную информационную базу (локальную или на сервере разработки).
Подключение к хранилищу: каждый разработчик открывает свой конфигуратор в своей базе и выполняет подключение к общему хранилищу через меню Конфигурация - Хранилище конфигурации - Подключиться к хранилищу.
Рабочий процесс: для редактирования конкретного объекта разработчик производит его захват в хранилище. После внесения изменений и локальной отладки выполняется операция поместить в хранилище.
Получение изменений: остальные участники команды выполняют команду обновить конфигурацию из хранилища, получая доработки коллег в свои персональные базы.
Для автоматизации создания и обновления баз разработчиков можно использовать запуск конфигуратора в пакетном режиме со специальными ключами командной строки:
Выбор между файловым хранилищем и сервером хранилища
Платформа 1С предоставляет два варианта развертывания хранилища конфигурации:
Файловый вариант (общая сетевая папка): хранилище создается как набор файлов в локальном или сетевом каталоге. Подходит только для небольших команд (1–2 разработчика) с надежной локальной сетью. Главный недостаток — высокая чувствительность к сбоям сети. Если у разработчика оборвется связь или компьютер уйдет в спящий режим во время помещения объектов, база хранилища может повредиться. При использовании файлового варианта обязательно нужно настроить ежедневное резервное копирование каталога хранилища.
Сервер хранилища конфигурации (crserver): отдельная служба, обеспечивающая работу по протоколу TCP/IP или HTTP/HTTPS. Этот вариант существенно надежнее, производительнее и защищен от сетевых сбоев клиентов. Однако важно помнить: служба сервера хранилища строго привязана к конкретной версии платформы 1С. Все разработчики команды и сам сервер хранилища должны использовать полностью совпадающую версию платформы (включая номер сборки).
Ограничения штатного механизма хранилища
Проанализируем технические ограничения, о которых необходимо знать при работе со штатным хранилищем 1С:
Гранулярность блокировок: захват объектов происходит на уровне элемента метаданных целиком. Если один разработчик захватил общий модуль или форму документа, второй программист не сможет параллельно редактировать даже другую процедуру в этом же объекте.
Блокировка корня конфигурации: создание новых объектов метаданных, изменение свойств подсистем, состава общих реквизитов и ролей требует захвата корня дерева конфигурации. На время захвата корня другие разработчики не смогут добавлять новые объекты.
Строго линейная история: штатное хранилище не поддерживает ветвление (ветки функциональности, feature branches) и автоматическое слияние веток (merge), как это принято в распределенных системах контроля версий.
Регламентное обслуживание и устранение неполадок
В процессе активной командной работы база хранилища увеличивается в объеме, а в кэше клиентов могут возникать ошибки. Разберем регламентные процедуры для поддержания стабильности:
Очистка локального кэша хранилища: если конфигуратор сообщает, что объект заблокирован, хотя блокировка снята, или выдает ошибки несоответствия версий, необходимо закрыть конфигуратор и удалить каталоги локального кэша хранилища в профиле пользователя операционной системы (папки %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8).
Проверка целостности и оптимизация: администратор хранилища должен периодически открывать конфигуратор монопольно и выполнять команды меню Конфигурация - Хранилище конфигурации - Администрирование хранилища: действия Проверить целостность и Оптимизировать хранилище для удаления устаревших служебных данных и уменьшения размера файла хранилища.
Альтернативные подходы к командной разработке
Для крупных проектов и команд, которым недостаточно возможностей классического хранилища, применяются современные инструменты разработки:
Разработка через расширения конфигурации: изолирование нового функционала в расширениях позволяет нескольким командам работать над разными задачами без постоянных конфликтов блокировок в основной конфигурации.
Среда 1C:Enterprise Development Tools (1C:EDT) и Git: в EDT исходный код хранится в виде текстовых файлов, что позволяет использовать классический Git, вести параллельную разработку в ветках, выполнять построчное слияние изменений в одном модуле и проводить обязательное код-ревью перед попаданием кода в основную ветку.
Выгрузка конфигурации в XML-файлы: использование штатных параметров конфигуратора /DumpConfigToFiles и /LoadConfigFromFiles для построения процессов непрерывной интеграции (CI/CD) на базе внешних систем контроля версий.