← База знаний

Оптимизация хранилища конфигурации 1С: ускорение групповой разработки

Если в вашей команде работает больше 3 программистов 1С, вы наверняка сталкивались с ситуацией: захват общего модуля длится 5 минут, помещение изменений в хранилище отнимает полчаса, а Конфигуратор внезапно "вылетает". Разбираем, как ускорить коллективную разработку (Тимлидам на заметку).

Почему хранилище 1С начинает тормозить?

По своей природе Хранилище конфигурации 1С — это обычная файловая база данных (набор файлов .1CD). Она страдает от тех же проблем, что и любая старая файловая версия 1С:

  • Сетевой доступ по протоколу SMB: Когда несколько разработчиков одновременно пытаются прочитать и записать изменения в файл по "расшаренной" сетевой папке (вида \\Server\1C_Repo) - возникают чудовищные конфликты блокировок файлов на уровне Windows.
  • Безгранично растущая история: Хранилище содержит каждую версию каждого модуля за 5 лет. Если его размер превысил 10-15 ГБ, файловая СУБД начинает физически "разваливаться".
  • Неисправный кэш Конфигуратора: У локального разработчика ломается синхронизация кэша конфигуратора (локальной базы и хранилища), что приводит к ошибке "Файл не является файлом базы данных".

🛠️ Золотые правила оптимизации хранилища

Правило 1: Только Сервер Хранилища (TCP)

Никогда не подключайте разработчиков к хранилищу через расшаренную сетевую папку! Организуйте работу через специальную службу "Сервер хранилища конфигураций 1С" (crserver).
При подключении адрес хранилища у программиста должен выглядеть как tcp://RepositoryServer/ERP_Config. Это перенесет всю логику работы с файлами на отдельную службу и ускорит работу в 5-10 раз.

Правило 2: Регулярное усечение истории (Свертка)

Как и обычную базу 1С, хранилище нужно "сворачивать". Раз в полгода-год тимлид должен:

  1. Создать абсолютно новое пустое хранилище конфигурации.
  2. Загрузить туда актуальный CF файл конфигурации (эталонную версию).
  3. Переподключить всех программистов на новое хранилище.
Старое многогигабайтное хранилище просто переименовывается в "Архив 2025" (для истории коммитов), а работа продолжается в новом "легком", которое "летает".

Правило 3: Делегирование и расширения

Избегайте захвата "корневого" узла конфигурации. Если программист работает над небольшой задачей, он не должен менять основную конфигурацию. Переводите команду на работу в Механизм расширений. У каждого расширения может быть свое, отдельное мини-хранилище, которое обновляется мгновенно.

Git как альтернатива Хранилищу 1С

В современных энтерпрайз-проектах от архаичного Хранилища отказываются в пользу EDT (Enterprise Development Tools) и версионирования исходников через Git (GitLab / GitHub).

Это снимает вообще все проблемы с блокировками, позволяя программистам вести разработку параллельно в своих ветках (Feature Branches) и решать конфликты "мерджа" современными инструментами, а не звонками в Skype ("Отпусти общий модуль Вася!"). Если у вас в штате больше 5 человек — это единственный путь к стабильному CI/CD.

Разработчики простаивают из-за тормозов 1С?

Построю современный CI/CD процесс для вашего отдела 1С. Ускорю хранилище, переведу команду на работу с расширениями и настрою автоматическое тестирование (SonarQube) вашего кода перед релизом в рабочую базу.

Получить консультацию →

📚 Связанные статьи