В процессе командной разработки на платформе 1С встает вопрос организации единого пространства для хранения программного кода и метаданных. Инструмент Хранилище конфигурации является классическим решением для этой задачи. Однако при его создании и подключении существующих информационных баз (особенно рабочих) возникают риски потери данных из-за несовпадения структуры метаданных. Разберем по шагам, как настроить среду разработки правильно и безопасно.
Первый и самый важный вопрос: с какой базы начинать? Проанализируем ситуацию. Если у нас есть «живая» основная база (продакшн), тестовая база и несколько баз разработчиков, то эталоном всегда должна выступать основная база. Рассмотрим, почему это критично. Хранилище содержит не только программный код, но и уникальные внутренние идентификаторы (GUID) объектов метаданных (справочников, документов, реквизитов). Если создать хранилище из базы разработчика, где структура может даже незначительно отличаться от рабочей, то при последующем подключении рабочей базы к этому хранилищу система обнаружит расхождения.
При подключении существующей базы к хранилищу происходит полная замена конфигурации базы данных конфигурацией из хранилища. Если идентификаторы объектов не совпадут, 1С расценит это как удаление старых объектов и создание новых. В результате таблицы в базе данных будут очищены, и вы потеряете накопленную информацию. Поэтому создаем хранилище исключительно на основании основной (рабочей) базы.
Прежде чем подключать остальные базы (тестовую или базы разработчиков) к созданному хранилищу, необходимо убедиться в их идентичности. Разберем, как это сделать правильно:
Подключиться к хранилищу.Помните: при подключении система не будет спрашивать разрешения на замену структуры — она просто «накатит» версию из хранилища поверх текущей. Если в подключаемой базе были уникальные доработки, которые еще не попали в основную базу, они будут безвозвратно затерты.
Для стабильной работы группы разработчиков крайне не рекомендуется использовать файловый доступ к хранилищу через общую сетевую папку. Это медленно и чревато повреждением файла 1cv8.cr при сбоях сети. Проанализируем более надежные способы подключения:
crserver.exe. Это стандартный и наиболее быстрый способ работы в локальной сети.При использовании сервера хранилища администратор создает базу хранилища и заводит учетные записи для каждого программиста, разграничивая права доступа (от права только на просмотр до полных административных прав).
Ключевой принцип работы в хранилище — монопольный захват. Выясним, как это работает на практике. Чтобы изменить объект, например, ОбщийМодуль.ПроведениеСервер, разработчик должен его «захватить». Пока объект захвачен одним пользователем, другие могут только просматривать его код, но не редактировать.
Рассмотрим полезную функцию — рекурсивный захват. Если вам нужно изменить справочник и все его формы/макеты, вы захватываете корневой объект справочника рекурсивно. Это гарантирует, что никто другой не изменит подчиненные элементы, пока вы ведете работу над объектом в целом.
После завершения кодинга выполняется процедура Поместить в хранилище. В этот момент изменения передаются в центральную базу хранилища, и объект освобождается для других участников процесса.
Со временем файл хранилища 1cv8.cr начинает увеличиваться в размерах, так как он хранит всю историю изменений по каждой версии. Это приводит к замедлению операций захвата и помещения объектов. Разберем, как поддерживать производительность:
Периодически следует выполнять процедуру сокращения истории хранилища. В конфигураторе (при подключенном хранилище с административными правами) можно выбрать дату или номер версии, ранее которых история будет удалена. Это значительно уменьшает объем данных и ускоряет отклик системы. Перед сокращением рекомендуется создать архивную копию файла хранилища на случай, если потребуется восстановить очень старый код.
Для эффективного взаимодействия между основной и тестовой базами используем механизм меток. Допустим, мы закончили разработку функционала для версии 1.2. Мы можем установить в хранилище метку «Релиз_1.2».
Зачем это нужно? Даже если разработка в основной ветке пойдет дальше, мы всегда сможем извлечь состояние конфигурации именно на момент этой метки. Это критично для исправления ошибок в тестовой базе: мы выгружаем конфигурацию по метке, исправляем баг, проверяем и только потом переносим в рабочую среду.
Проанализируем современные тенденции. В крупных проектах все чаще используется 1C:Enterprise Development Tool (EDT). Это альтернативная среда разработки, которая позволяет отказаться от классического хранилища в пользу системы Git.
Преимущества перехода на EDT и Git:
Однако для небольших и средних команд классическое хранилище остается наиболее простым в настройке и эффективным инструментом.
Работа с хранилищем поддерживает управление через командную строку. Это позволяет автоматизировать рутинные задачи. Например, можно настроить скрипт для обновления тестовой базы каждую ночь:
"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER /F "C:\Bases\TestBase" /ConfigurationRepositoryF "tcp://server/Rep" /ConfigurationRepositoryN "Admin" /ConfigurationRepositoryP "Pass" /ConfigurationRepositoryUpdateCfg
Этот скрипт автоматически подключится к хранилищу, заберет последние изменения и обновит конфигурацию тестовой базы без участия человека. Таким образом, мы обеспечиваем актуальность среды тестирования для специалистов контроля качества.
Подводя итог: создавайте хранилище на базе рабочей конфигурации, всегда проверяйте идентичность перед подключением и используйте клиент-серверный режим работы (через crserver.exe) для обеспечения надежности и скорости разработки.