В процессе совместной разработки на платформе 1С:Предприятие 8 часто возникает ситуация, когда разработчикам необходимо обновить свои локальные или тестовые базы актуальными данными из «продуктовом» контура. Традиционный метод — восстановление бэкапа рабочей базы поверх базы разработки — приводит к тому, что настройки связи с хранилищем конфигурации сбрасываются или заменяются настройками из рабочей базы. Последующее переподключение к хранилищу на больших конфигурациях (таких как ERP, КА или УПП) может занимать несколько часов, что существенно тормозит процесс разработки.
В этой статье мы разберем, почему это происходит, и проанализируем основные способы ускорения этого процесса: от организационных маневров до глубокой технической оптимизации.
Разберем внутреннюю механику платформы. Когда мы инициируем команду «Подключиться к хранилищу», конфигуратор не просто прописывает путь к файлам. Он выполняет полную десериализацию объектов метаданных как в текущей информационной базе (ИБ), так и в последней версии хранилища. После этого происходит детальное сравнение и сопоставление каждого объекта.
Основные причины тормозов:
Проанализируем способы решения этой проблемы.
Часто основной дискомфорт вызывает не само время ожидания, а необходимость вручную выполнять рутинные действия в конфигураторе. Мы можем автоматизировать этот процесс, запуская скрипт восстановления базы и подключения к хранилищу в ночное время.
Рассмотрим пример команды для пакетного подключения базы к хранилищу:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" CONFIG /S "Server\Base" /N "Admin" /P "Pass" /ConfigurationRepositoryConnect -Ref "tcp://RepoServer/RepoName" -U "RepoUser" -P "RepoPass" /UpdateDBCfg
Параметры, которые мы использовали:
/ConfigurationRepositoryConnect — основная команда подключения.-Ref — путь к хранилищу (в примере указан серверный путь tcp://).-U и -P — логин и пароль пользователя в самом хранилище./UpdateDBCfg — обновление конфигурации базы данных после успешного подключения.Таким образом, к приходу разработчика на рабочее место база уже будет обновлена и подключена.
Как отмечают опытные специалисты, работа через файловый доступ (общую папку) крайне нестабильна и медленна. Рассмотрим преимущества перехода на сервер хранилища (приложение crserver.exe).
При использовании протокола TCP часть вычислительной нагрузки по сравнению объектов ложится на сервер приложения хранилища. Это значительно сокращает объем данных, пересылаемых по сети.
Важный нюанс: Если в вашей организации используется «зоопарк» платформ (сообщение 36), помните, что сервер хранилища должен соответствовать версии платформы клиента. Чтобы решить эту проблему, можно запустить несколько экземпляров crserver.exe на разных портах. Например:
Проанализируем стратегию, предложенную в сообщении 10. Чтобы не ждать подключения каждый раз, рекомендуется держать не одну, а две или даже три тестовые базы.
Эта схема позволяет полностью исключить простои, связанные с техническим ожиданием связи с хранилищем.
Скорость доступа к файлам хранилища критична. Выясним, что можно улучшить на уровне «железа»:
1cv8storage.1cd и временные файлы *.cln в исключения антивируса на сервере и клиенте.Многие задаются вопросом: можно ли просто «подправить» GUID базы в файлах хранилища? Рассмотрим структуру хранения этих данных.
Связь ИБ с хранилищем хранится внутри самой информационной базы в системной таблице ConfigStorage (в SQL-варианте). Там содержатся:
Внимание: Прямая правка этой таблицы крайне не рекомендуется. При восстановлении бэкапа из рабочей базы данные в этой таблице затираются или становятся невалидными для текущего окружения. Платформа 1С использует механизм внутренних идентификаторов (ProjectID), и если они не совпадут хотя бы в одном байте, база выдаст критическую ошибку при попытке захвата объекта.
Если ваша команда страдает от ограничений классического хранилища (очереди на захват объектов, долгие подключения), стоит рассмотреть переход на Enterprise Development Tools (EDT) в связке с Git.
В этой парадигме конфигурация хранится в виде текстовых XML-файлов. Операция «обновления из мастера» (аналог подключения к хранилищу) в Git занимает секунды или минуты даже для очень больших проектов, так как работа идет с текстом, а не с бинарными данными внутри базы. Это полностью устраняет проблему многочасовых ожиданий, описанную автором темы.
Подведем итог: Самым быстрым и безопасным способом решения проблемы без смены инструментов является комбинация серверного режима хранилища (TCP) и автоматизации подключения через скрипты командной строки в ночное время.