← На главную

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

Архитектурные различия: как работают файловый и серверный варианты

Рассмотрим, что происходит «под капотом» при помещении или получении объектов конфигурации в обоих режимах:

1. Файловое хранилище: представляет собой файл базы данных 1Cv8.1cd, размещенный в локальном каталоге или на сетевом ресурсе (SMB/CIFS). Каждый экземпляр Конфигуратора, запущенный у разработчика, обращается к файлу хранилища напрямую через файловую систему операционной системы. При фиксации изменений захватываются диапазоны байт файла, а операции записи выполняются каждым клиентом независимо.
2. Серверное хранилище: файл 1Cv8.1cd обслуживается отдельным выделенным процессом — службой crserver (или модулем веб-сервера wsconf). Конфигураторы разработчиков не имеют прямого доступа к файлу на диске; они взаимодействуют со службой по протоколам TCP (по умолчанию порт 1542) или HTTP/HTTPS. Служба централизованно управляет транзакциями, очередью запросов и кэшем метаданных.

Почему файловое хранилище повреждается: риски и уязвимости

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

1. Нестабильность сетевых соединений: если файловое хранилище расположено на сетевом диске, малейший обрыв связи или потеря сетевого пакета в момент выполнения операции записи (помещение изменений, создание новой версии) приводит к нарушению целостности структуры 1Cv8.1cd.
2. Влияние сетевых протоколов (SMB Oplocks): механизмы оппортунистических блокировок и кэширования сетевой файловой системы Windows могут вызывать коллизии при одновременной записи данных несколькими процессами Конфигуратора.
3. Блокировки антивирусного ПО: работающие на файловом сервере антивирусы при сканировании файлов «на лету» или службы теневого копирования могут заблокировать файл хранилища именно в момент фиксации транзакции Конфигуратором. Это гарантированно вызывает ошибку формата потока или повреждение заголовков таблиц.
4. Конкуренция процессов на терминальном сервере: даже если все разработчики работают в сеансах RDS на том же сервере, где лежит файл, множественные прямые обращения процессов 1cv8.exe к одному файлу создают повышенную нагрузку на файловые дескрипторы ОС и увеличивают вероятность взаимных блокировок (deadlocks).

Преимущества серверного хранилища (crserver)

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

1. Транзакционная целостность: служба crserver выполняет все операции записи строго последовательно через внутренний механизм транзакций. Если клиент аварийно завершит работу во время фиксации изменений, служба корректно откатит незавершенную операцию, не повредив общую базу.
2. Безопасность и сокрытие доступа: разработчикам и посторонним учетным записям не требуется выдавать права на чтение и запись в сетевую папку операционной системы. Файл хранилища физически защищен от случайного удаления, повреждения вирусами-шифровальщиками или некорректных действий пользователей.
3. Работа через интернет: публикация хранилища на веб-сервере (Apache или IIS) позволяет удаленным сотрудникам подключаться по защищенному протоколу HTTPS без настройки сложных VPN-туннелей и терминальных ферм. При этом трафик между клиентом и веб-сервером автоматически сжимается.
4. Поддержка фоновых конвейеров CI/CD: автоматические выгрузки конфигурации скриптами командной строки через параметры /ConfigurationRepositoryF, /ConfigurationRepositoryN и /ConfigurationRepositoryP выполняются параллельно с работой программистов, не вызывая конфликтов блокировки на уровне файлов.

Практические рекомендации по настройке и оптимизации

Рассмотрим комплекс мер, позволяющих добиться максимальной скорости и стабильности при совместной разработке:

1. Исключение из антивирусной проверки: обязательно добавим каталог с хранилищем конфигурации (как файловым, так и базой службы crserver) в список доверенных исключений антивирусного ПО и систем теневого резервного копирования на сервере.
2. Регулярная очистка локального кэша: Конфигуратор кэширует версионированные метаданные локально в профиле пользователя ОС (каталоги AppData\Local\1C\1Cv8). Если операции сравнения или обновления конфигурации из хранилища начинают замедляться, очистим локальный кэш разработчика.
3. Процедура сокращения хранилища: по мере накопления истории и тяжелых коммитов размер файла базы растет, что замедляет построение отчетов по истории версий. Периодически выполним административную операцию «Сократить хранилище» в меню Конфигуратора, удалив устаревшие промежуточные версии до определенной контрольной точки.
4. Организация резервного копирования: для создания корректного бэкапа серверного хранилища службу crserver кратковременно останавливают либо настраивают выгрузку версий штатными скриптами, что гарантирует целостность скопированного файла.

Итоги и рекомендации по выбору

Подведем итог: файловое хранилище допустимо использовать исключительно для одного разработчика или локальной разработки без сетевого доступа. Для команды даже из 2–5 человек (как на выделенных ПК, так и в терминальной среде) единственным надежным промышленным решением является серверное хранилище конфигураций (служба crserver или публикация через веб-сервер), гарантирующее сохранность исходного кода и стабильность транзакций.