Работа с крупными прикладными решениями, такими как 1С:Управление производственным предприятием (УПП), часто сопряжена с техническими сложностями. Когда база данных разрастается до 100 ГБ и более, стандартные операции — захват объектов в хранилище, сравнение конфигураций и обновление — начинают занимать непозволительно много времени. Ситуация осложняется, если над проектом работают одновременно несколько специалистов, а аппаратные ресурсы разработчиков ограничены. Рассмотрим детально, как оптимизировать процесс коллективной разработки в таких условиях.
Одной из главных проблем, описанных в ситуации, является невозможность развернуть полную копию базы на локальном ПК разработчика из-за ее объема и низкой скорости работы. Разберем наиболее эффективный метод организации окружения, который используют профессиональные команды:
УПП и выполняем процедуру свертки данных (удаление старых периодов, очистка неиспользуемых логов и помеченных на удаление объектов). Цель — получить базу размером 5–10 ГБ, в которой сохранена структура и минимально необходимый набор данных для тестирования логики.cf.Если операции захвата объектов занимают часы, проблема может крыться в способе подключения или состоянии самого хранилища. Рассмотрим шаги по технической очистке и настройке:
Многие разработчики по привычке подключаются к хранилищу через общую сетевую папку (протокол SMB). На больших конфигурациях это критическая ошибка. Рассмотрим преимущества перехода на tcp://:
При использовании сервера хранилища конфигурации (служба crserver.exe) большая часть вычислительных операций по сравнению версий происходит на стороне сервера. Это значительно ускоряет отклик конфигуратора. Выясним причину: протокол SMB передает огромные объемы метаданных по сети, тогда как tcp оптимизирован для работы платформы 1С.
Часто тормоза при работе с хранилищем вызваны «раздутым» кэшем на стороне клиента. Проанализируем ситуацию: платформа хранит локальные копии объектов для ускорения сравнения, но при сбоях или огромном размере конфигурации этот механизм начинает работать против нас. Рекомендуется:
%AppData%\Local\1C\1Cv8\).1cv8ddb.1cd) фрагментируются и разрастаются. Процедура сокращения истории (например, до последних 100 версий) может значительно ускорить работу.Чтобы избежать длительной реструктуризации основной базы при каждом изменении, мы можем применить механизм расширений конфигурации (доступно в 1С v8.3). Рассмотрим, как это помогает в коллективной разработке:
Вместо того чтобы захватывать «тяжелые» объекты (например, общие модули или формы документов в УПП), разработчик создает расширение. Все новые функции и доработки интерфейса вносятся в расширение. Это позволяет:
Обновить конфигурацию базы данных.Посмотрим на ситуацию со стороны системного администрирования. База в 100 ГБ — это средний объем, и современные технологии позволяют работать с ней эффективно. Проанализируем необходимые ресурсы:
Для комфортной работы команды из нескольких человек крайне желательно выделить отдельный сервер разработки. Основные требования:
Если стандартное хранилище перестает справляться, стоит рассмотреть переход на современные инструменты разработки, такие как 1C:EDT (Enterprise Development Tool). Разберем этот вариант:
1C:EDT базируется на Eclipse и использует Git для контроля версий. В отличие от хранилища, Git работает с текстовыми файлами конфигурации. Это позволяет:
Подводя итог, можно сказать, что работа с большой базой требует комплексного подхода. В первую очередь, мы должны разделить хранилище и рабочую базу, используя для разработки облегченные копии данных. Во вторую — оптимизировать само хранилище, переведя его на серверный режим и сократив историю. Использование современных методов, таких как расширения и 1C:EDT, поможет свести время ожидания к минимуму, позволяя специалистам сосредоточиться на написании кода, а не на борьбе с инструментарием.