Хранилище конфигураций 1С: перевод на новый релиз и новую платформу
Содержание
Чтобы обновить хранилище 1С, выберите, что именно меняется. Обычно это новый релиз типовой конфигурации: разработчик захватывает корневой объект, подгружает поставку 1С в конфигурацию, разбирает конфликты и помещает результат в хранилище. Реже речь о новой платформе, когда хранилище приходится переводить на новый формат.
Любая из этих задач безопасна только с резервной копией хранилища. Без неё откат занимает дни, а не минуты. Ниже порядок действий, способы, типовые ошибки и то, что делать после обновления.
Что подготовить до начала работ
Хранилище конфигураций хранит историю версий каждого объекта. Один неверный коммит, и вся команда получает испорченную основу. Поэтому подготовку не пропускают.
Проверка совместимости
Сверьте три вещи:
- 📌 Платформа. Новый релиз типовой конфигурации требует минимальную версию платформы. Она указана в описании релиза и в окне обновления.
- 📌 Режим совместимости. Если в хранилище задан режим совместимости со старой платформой, новый релиз может его поднять. Решите заранее, кто и когда это делает.
- 📌 Версии клиентов. Разработчики подключаются к хранилищу из конфигураторов. Если у кого-то платформа старше, чем у хранилища, подключение откажет или даст предупреждение.
Версию платформы смотрите в справке «О программе» конфигуратора. Для серверного хранилища учитывайте и версию самого сервера хранилища.
Кто и когда обновляет
На время работ договоритесь, что остальные разработчики не захватывают объекты. Лучше всего, когда все помещают свои правки и отключаются от хранилища. Тогда корень конфигурации захватывает один человек, и конфликтов с чужими незавершёнными изменениями не возникнет.
Если у разработчиков остались захваченные объекты, обновление с поставки их не затрагивает, но потом придётся объединять вашу версию с чужой. Лучше собрать все коммиты заранее.
Чек-лист подготовки
Резервная копия хранилища
Хранилище бывает двух видов, и копируют их по-разному.
| Вид хранилища | Что копировать | Как |
|---|---|---|
| Файловое | Каталог хранилища, главный файл 1cv8ddb.1CD | Закрыть все подключения, скопировать каталог целиком |
| Серверное | Данные сервера хранилища | Остановить службу сервера хранилища, скопировать каталог данных, запустить службу |
Копировать открытый файл 1cv8ddb.1CD на ходу нельзя. Если кто-то подключён, копия получится битой, и узнаете вы об этом только при восстановлении.
Простой порядок для файлового хранилища:
- Попросите всех закрыть конфигураторы.
- Скопируйте каталог хранилища в отдельное место, например
\\backup\1c\storage_2026-10-07\. - Сохраните рядом файл с версией платформы, на которой хранилище работало.
- Проверьте, что размер копии совпадает с оригиналом.
Проверьте, что копию действительно можно открыть. Для этого подключите тестовую информационную базу к копии хранилища и посмотрите историю версий. Копия, которую не пробовали открывать, пока не резервная.
💡 Для крупных хранилищ добавьте в копию ещё и выгрузку текущей конфигурации в файл .cf. Её удобно развернуть на пустой базе, если хранилище придётся собирать заново.
Как обновить хранилище с новым релизом типовой конфигурации
Это основной сценарий. Выполняйте его в базе разработки, подключённой к хранилищу, у человека, который отвечает за обновление.
Шаг 1. Захватить корень
- Откройте конфигуратор в базе разработки.
- Убедитесь, что база подключена к хранилищу и получена последняя версия .
- Захватите корневой объект конфигурации с включённым флажком рекурсивного захвата подчинённых. Нужно захватить всё, иначе обновление не сможет изменить незахваченные объекты.
Если часть объектов захвачена другими, система об этом скажет. Попросите коллег поместить правки или снять захват.
Шаг 2. Загрузить поставку
В конфигураторе откройте меню конфигурации, раздел поддержки, и запустите обновление. Выберите источник: файл поставки или каталог с шаблонами, куда его положил мастер установки релиза.
Система предложит сравнить конфигурации: вашу, текущую, и поставку, новую. Для каждого объекта она покажет, что менялось у вас, что у поставщика и где пересекается.
Шаг 3. Разобрать конфликты
Окно объединения делит объекты на группы. Привычная логика такая:
- ✅ Менялся только поставщик. Берём новую версию. Проблем нет.
- ✅ Менялись только вы. Оставляем свою версию.
- ⚠️ Менялись обе стороны. Нужно решение по каждому объекту. Для модулей смотрите построчное сравнение, для форм и реквизитов решайте вручную.
Для доработанного кода придерживайтесь простого правила: сначала переносим то, что на самом деле нужно бизнесу, потом чистим то, что поставщик уже закрыл своим решением. Не оставляйте собственную копию функции, если типовая стала полноценной, иначе через пару релизов у вас накопится вторая типовая конфигурация внутри первой.
Не нажимайте «Принять всё» ради скорости. Именно так теряются доработки, сделанные три года назад, о которых никто не помнит.
Шаг 4. Обновить конфигурацию базы данных
После объединения конфигуратор спросит про реструктуризацию. Согласитесь на тестовой базе и проверьте, что структура обновилась без потери данных. Затем запустите программу в режиме предприятия и прогоните ключевые сценарии.
Шаг 5. Поместить в хранилище
Когда база работает, откройте меню хранилища и выполните помещение изменений. В комментарии укажите номер релиза и суть работы: «Обновление до релиза такого-то, перенос доработок по счетам и печатным формам». Через год этот комментарий сэкономит часы.
Помещайте корень целиком, а не отдельные объекты. Иначе в истории останется набор разрозненных версий, и откатиться к состоянию «до обновления» будет сложно.
Способы обновления: от мастера до командной строки
Один и тот же результат достигается разными путями. Выбирайте по числу хранилищ и частоте релизов.
| Способ | Когда подходит | Риск |
|---|---|---|
| Интерактивно в конфигураторе | Одно хранилище, релиз раз в несколько месяцев | Ошибки из-за ручных кликов |
| Через пакетный режим конфигуратора | Несколько однотипных хранилищ, автоматизация | Нужно отладить скрипт, пароли в параметрах |
| Через обновление из файла поставки на чистой базе | Серьёзные доработки, нужно перенести их отдельно | Больше работы, зато прозрачнее |
Пакетный режим пригодится, если хранилищ несколько. Конфигуратор запускают из командной строки с параметрами хранилища и действия. Пример каркаса запуска:
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER ^
/F "C:\Bases\dev" ^
/ConfigurationRepositoryF "\\srv\storage\buh" ^
/ConfigurationRepositoryN "Admin" ^
/ConfigurationRepositoryP "%STORAGE_PWD%" ^
/ConfigurationRepositoryUpdateCfg -force ^
/Out "C:\logs\update.log"
Номер платформы в пути подставьте свой. Пароль не пишите прямо в файл, берите из переменной окружения или защищённого хранилища паролей. Проверьте набор параметров по справке к вашей версии платформы, они могут отличаться.
💡 Автоматизируйте только операции получения и обновления. Объединение конфликтов лучше оставить человеку.
Когда обновляется не конфигурация, а сама платформа
С новой платформой хранилище может потребовать преобразования формата. Признак: при подключении конфигуратор сообщает, что хранилище создано в другой версии, и предлагает обновить его.
Порядок такой:
- Сделайте копию хранилища, как описано выше.
- Проверьте в описании платформы, поддерживает ли она ваш формат без потерь.
- Подключитесь одним конфигуратором новой версии и подтвердите преобразование.
- Остальным разработчикам обновите платформу до того же уровня, иначе они не смогут подключиться.
Обратно хранилище на старую платформу не вернётся. Если пилот на новой платформе не удался, откат возможен только с копии.
Разработчикам стоит договориться об окне. Пока один человек преобразует хранилище, остальные должны быть отключены.
Типичные ошибки и что с ними делать
Если не помогло
Откатитесь на копию хранилища и повторите обновление пошагово, проверяя результат после каждого этапа. Если хранилище повреждено, соберите новое из выгрузки .cf и подключите к нему базы разработки заново. Историю версий вы потеряете, поэтому такой вариант последний.
Дополнительно проверьте журнал регистрации и протокол конфигуратора: ошибка часто указана там яснее, чем в диалоговом окне.
Оптимизация хранилища после обновления
После нескольких крупных релизов файл 1cv8ddb.1CD разрастается, и работа с ним замедляется. Это нормально: в нём лежат все версии всех объектов.
Что стоит сделать:
- 🧹 Обрезать историю. В административных функциях хранилища есть возможность удалить старые версии. Решайте вместе с командой, какую глубину хранить. Типовое правило: версии за последние пару лет и все помеченные метками релизов.
- 🏷 Ставить метки версий. Метка на помещении «после обновления до релиза» позволяет вернуться к этому состоянию одним действием.
- 🗜 Держать хранилище на быстром диске. Файловое хранилище на сетевом ресурсе с медленным каналом тормозит каждый захват. Для команды больше пяти человек подумайте о серверном хранилище.
- 📉 Избавиться от лишних объектов. Типовые объекты, которые поставщик убрал, и свои устаревшие обработки.
Ориентиры по размерам: хранилище с типовой бухгалтерской конфигурацией и небольшой командой обычно занимает от сотен мегабайт до нескольких гигабайт. Если файл вырос в разы за год, ищите в истории тяжёлые бинарные данные, например картинки и макеты, которые помещали много раз.
Облако, серверное хранилище и гибридные схемы
Обновление на сервере хранилища отличается подготовкой.
- В серверном варианте остановите службу, сделайте копию каталога данных, и только потом обновляйте платформу сервера хранилища.
- Версия сервера хранилища должна быть не ниже версии клиента.
- Если хранилище размещено у провайдера, уточните у него порядок копирования и окно обслуживания. Обновление платформы на стороне облака без вашего ведома ломает подключение разработчиков.
- При схеме, где часть разработчиков работает по VPN, проверьте таймауты. Крупное помещение корня по медленному каналу может оборваться на середине.
Для гибридных схем, когда хранилище стоит у вас, а база разработки в облаке, заранее проверьте, что порты и адрес сервера хранилища доступны из облачной среды. Проверка занимает десять минут, а сбой на этапе помещения остановит работу на полдня.
Мониторинг и сопровождение после обновления
Помещение в хранилище не финал. Ещё неделю-две следите за обновлённой конфигурацией.
- Следите за ошибками пользователей. Сразу после переноса в рабочую базу собирайте жалобы: чаще всего всплывают печатные формы и отчёты, затронутые доработками.
- Сверьте регламентные задания. После обновления они иногда слетают, особенно на файловых базах.
- Проверьте размер хранилища и скорость захвата. Сравните с цифрами до работ. Резкая разница означает, что в истории лежит лишнее.
- Сравните состав доработок. Выгрузите список изменённых объектов до и после. Он должен отличаться только тем, что вы сознательно закрыли поставкой.
- Заведите журнал работ. Дата, релиз, кто выполнял, какие объекты объединялись вручную. При следующем обновлении этот список сэкономит день.
Раз в квартал проверяйте, что копии хранилища реально восстанавливаются. Для этого разверните последнюю копию на тестовом сервере и подключите базу.