В процессе разработки на платформе 1С:Предприятие возникают ситуации, когда разработчику необходимо временно отключить рабочую или девелоперскую базу от хранилища конфигурации, выполнить определенный пул задач в автономном режиме, а затем подключить базу обратно и залить свои доработки в общее хранилище. Это может быть связано с отсутствием стабильного интернет-соединения, необходимостью проведения экстренного хотфикса на продуктивной базе или проведением опасных экспериментов, которые не должны затронуть основную ветку разработки.
В этой статье мы подробно разберем, как устроен этот процесс, с какими критическими опасностями можно столкнуться при его реализации (включая угрозу полной утери данных пользователей) и как выглядит пошаговый безопасный алгоритм слияния изменений. Также мы рассмотрим современные альтернативные подходы, которые позволяют избежать рисков, присущих классическому хранилищу 1С.
Прежде чем приступать к практическим действиям, проанализируем внутренние механизмы работы платформы 1С. При подключении информационной базы к хранилищу платформа выполняет полное замещение текущей редактируемой конфигурации конфигурацией хранилища. Это необходимо для обеспечения стопроцентного совпадения внутренних уникальных идентификаторов (UUID) всех объектов метаданных.
Если разработчик отключается от хранилища и создает новые объекты метаданных (справочники, документы, реквизиты, регистры) в автономном режиме, а затем пытается вернуть их обратно обычным накатыванием файла конфигурации, возникают следующие риски:
ФизическиеЛицаДополнительно), для платформы это будут два абсолютно разных объекта.Именно поэтому простое замещение конфигурации файлом .cf после обратного подключения к хранилищу категорически запрещено.
Рассмотрим детальный и технически выверенный регламент, который позволит вам вернуть доработки из автономной базы в хранилище без риска повредить структуру метаданных или потерять информацию.
Шаг 1. Подготовка файла изменений в автономной базе
В базе, где вы вели локальную разработку без подключения к хранилищу, необходимо зафиксировать все изменения. Для этого выполните обновление конфигурации базы данных (клавиша F7), чтобы основная конфигурация полностью соответствовала конфигурации БД. После этого выгрузите конфигурацию в файл, перейдя в меню: Конфигурация — Сохранить конфигурацию в файл.... Назовем этот файл, например, offline_changes.cf.
Шаг 2. Подключение к хранилищу и обновление локальной копии
Откройте базу, которую вы планируете использовать для связи с хранилищем (это может быть ваша локальная база, предварительно очищенная, или заново созданная пустая база). Выполните подключение к хранилищу через меню Конфигурация — Хранилище конфигурации — Подключиться к хранилищу.... Для регулярного выполнения этого действия можно использовать скрипт для автоматического подключения базы к хранилищу конфигурации.
Важно помнить: В процессе подключения ваша локальная основная конфигурация будет полностью перезаписана актуальной версией из хранилища. Ваши автономные изменения на этом этапе в базе сотрутся — не пугайтесь, именно для этого мы сохранили их в файл на первом шаге.
Шаг 3. Захват объектов в хранилище
Теперь нам необходимо подготовить место для безопасной заливки изменений. В подключенной к хранилищу базе захватите те объекты метаданных, которые вы редактировали в автономном режиме. Если изменений было очень много и они затронули корневые свойства или структуру подчиненных объектов, выполните рекурсивный захват корня конфигурации.
Перед захватом обязательно убедитесь, что никто из коллег в данный момент не занят редактированием этих же объектов, чтобы избежать организационных коллизий.
Шаг 4. Сравнение и объединение конфигураций
Запустите процедуру объединения. Для этого перейдите в меню: Конфигурация — Сравнить, объединить с конфигурацией из файла... и выберите ранее сохраненный файл offline_changes.cf.
Шаг 5. Выборочный перенос изменений
После того как платформа построит дерево сравнения конфигураций, выполните следующие действия:
Этот шаг критически важен: он гарантирует, что вы не занесете в хранилище случайный "мусор", старые версии чужих объектов или ошибочные метаданные.
Шаг 6. Контрольная проверка и тестирование
После завершения объединения не спешите отправлять код в хранилище. Проведите повторное сравнение с конфигурацией базы данных, запустите сеанс отладки в режиме "1С:Предприятие", проверьте работоспособность внесенных изменений на актуальных данных из хранилища.
Шаг 7. Помещение изменений в хранилище
Когда вы убедились, что все работает корректно, вызовите команду Конфигурация — Хранилище конфигурации — Поместить в хранилище.... Обязательно оставьте подробный комментарий к истории изменений, указав, что данные доработки были выполнены автономно.
Обсуждая работу с хранилищем, важно затронуть тему обновления живых (продуктивных) баз данных. Настоятельно рекомендуем придерживаться следующего правила: рабочая база (продакшн) должна находиться на поддержке БЕЗ подключения к хранилищу конфигурации.
Подключение базы продакшена напрямую к хранилищу несет колоссальные риски:
.cfu) или полные файлы конфигурации (.cf), прошедшие все стадии тестирования.Для правильной сборки релизов в крупных проектах обычно создается вспомогательная база (так называемая "база сборки"), которая подключена к хранилищу. Именно из нее выгружается эталонный файл конфигурации для последующего обновления продуктивного контура.
Описанная выше схема с отключением и ручным слиянием через файлы сравнения является рабочей, но довольно архаичной и трудоемкой. В современной практике разработки на 1С все чаще отказываются от классического хранилища в пользу связки 1С:EDT (Enterprise Development Tools) + Git.
Использование распределенной системы контроля версий Git полностью решает озвученные проблемы:
Если ваша команда регулярно сталкивается с необходимостью отключаться от хранилища или страдает от блокировок объектов коллегами, рассмотрение перехода на Git и EDT станет лучшим стратегическим решением для автоматизации процесса разработки.