При работе с тяжелыми конфигурациями, такими как 1С:ERP Управление предприятием или ERP УХ, многие команды сталкиваются с критическим замедлением хранилища конфигураций. Длительные блокировки объектов, многочасовое ожидание при помещении изменений и невозможность параллельной работы программистов — типичные проблемы, которые могут парализовать отдел разработки. Разберем подробно, как оптимизировать этот процесс, перенастроить инфраструктуру и изменить подходы к самой разработке.
Первое, что мы должны проанализировать, — это способ подключения к хранилищу. Использование прямого файлового доступа через сетевую шару (даже при наличии 10-гигабитной сети) является основной причиной низкой производительности. Разберем, почему это происходит: при файловом доступе клиентское приложение (конфигуратор) самостоятельно выполняет все операции чтения и записи сотен мелких файлов метаданных, что порождает огромное количество сетевых коллизий.
Рассмотрим правильный алгоритм действий для перехода на сервер хранилища:
crserver.exe на сервере, который имеет максимально быстрый доступ к дисковой подсистеме.tcp://имя_сервера/путь_к_хранилищу позволяет серверу хранилища самостоятельно управлять кэшированием и блокировками, что значительно ускоряет работу.Типичная ошибка — подключение всех баз (включая рабочую и тестовые) к одному хранилищу. Это создает избыточную нагрузку при каждом обновлении конфигурации базы данных. Выясним, как правильно распределить роли баз:
Рабочая база (Production): Ее категорически не рекомендуется держать подключенной к основному хранилищу разработки. Рассмотрим схему обновления через файлы поставки (.cf или .cfu). Это позволяет обновлять рабочую базу в строго отведенное технологическое окно, не блокируя работу программистов в хранилище.
Тестовые базы: Вместо постоянного подключения к хранилищу, используем скрипты для автоматического обновления тестовых контуров. Например, разберем возможность ночной сборки, когда специальное регламентное задание выгружает конфигурацию из хранилища и обновляет тестовые базы без участия человека.
Базы разработчиков: Программисты должны работать в «легких» базах. Разберем этот термин: это информационная база, которая содержит в себе всю конфигурацию, подключенную к хранилищу, но не имеет тяжелых транзакционных данных. Это позволяет выполнять операцию Обновить конфигурацию базы данных (F7) за считанные секунды.
Проанализируем ситуацию, когда задача занимает несколько недель. Держать объекты захваченными всё это время — значит мешать другим коллегам. Выясним, какие инструменты помогут нам избежать блокировок:
Использование нескольких хранилищ (Каскадная схема): Создадим отдельное «хранилище фич» (Feature Storage) для крупных проектов. Разработчики работают там, а по завершении этапа конфигурация объединяется с основным хранилищем. Это требует аккуратности, но полностью снимает проблему блокировок в основном контуре.
Переход на Git и EDT: Посмотрим на современный стек 1С. Использование 1C:Enterprise Development Tools (EDT) в связке с Git позволяет уйти от парадигмы захвата объектов. В Git программисты работают в параллельных ветках, а слияние кода происходит без блокировки всей системы метаданных.
Часто жизнь заставляет нас вносить правки в «боевую» базу немедленно (Hotfix), в то время как нужные объекты захвачены в хранилище под долгосрочные задачи. Рассмотрим, как решить эту проблему цивилизованно:
Создадим временное расширение конфигурации. Вместо того чтобы пытаться отобрать объект у коллеги в хранилище, мы выносим исправленный метод или форму в расширение. Подключаем его к рабочей базе динамически. Позже, когда основная задача будет завершена и объекты в хранилище освободятся, мы перенесем код из расширения в основную конфигурацию и удалим временный объект.
Чтобы хранилище не тормозило «со временем», проанализируем необходимость регулярного технического обслуживания. Основная причина деградации производительности — раздутая история версий.
Рассмотрим пример команды для пакетного запуска конфигуратора с целью получения изменений, которую можно поместить в .bat файл для ночного исполнения:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "Server1C\BaseName" /N "Admin" /P "Pass" /ConfigurationRepositoryF "tcp://RepoServer/MainRepo" /ConfigurationRepositoryN "User" /ConfigurationRepositoryP "UserPass" /ConfigurationRepositoryUpdateCfg
Важные шаги по оптимизации самой базы хранилища:
Когда мы обновляем ERP на новый релиз от 1С, процесс помещения изменений в хранилище может занимать часы. Проанализируем, как минимизировать простой:
Процедуру обновления поставщика лучше выполнять в два этапа. Сначала обновим конфигурацию в копии базы, не подключенной к хранилищу. Проверим работоспособность и выполним все сопоставления объектов. Только после этого, выбрав время, когда никто из коллег не работает, выполним захват «корня» конфигурации и поместим обновленные метаданные в хранилище. Это позволит избежать блокировки работы команды на период ручного сопоставления объектов в режиме объединения.
Подведем итог: для комфортной работы команды из 4-7 человек над крупным проектом, мы должны обязательно использовать серверный вариант хранилища на SSD, отказаться от подключения продуктивной базы к общему хранилищу и активно использовать механизм расширений для оперативных правок.