Новый релиз типовой и командная разработка: порядок работы с хранилищем 1С
Содержание
Чтобы обновить конфигурацию
в хранилище 1С, захватите корень конфигурации рекурсивно, выполните Конфигурация → Поддержка → Обновить конфигурацию в базе, подключённой к хранилищу, проверьте результат и поместите изменения командой Конфигурация → Хранилище конфигурации → Поместить в хранилище. Остальные разработчики после этого получают новую версию командой «Обновить конфигурацию из хранилища
».
Частое заблуждение: новый релиз можно накатить прямо на файлы хранилища или на рабочую базу, а хранилище «подтянется само». Не подтянется. Хранилище знает только то, что в него поместили из Конфигуратора. Всё, что сделано в обход, оно не видит, и при следующей синхронизации эти правки потеряются или сломают сравнение.
Как устроено хранилище конфигурации и что значит «обновить» его
Хранилище — это общая база версий конфигурации. Каждый разработчик работает в своей информационной базе, подключённой к хранилищу. Правки идут по кругу:
- 🔒 Захват — объект закрепляется за вами, другие его менять не могут.
- ✏️ Изменение — вы правите объект у себя в базе.
- 📤 Помещение — изменения уходят в хранилище, появляется новая версия с номером и комментарием.
- 📥 Получение — коллеги забирают новую версию к себе.
Слияния «строка в строку», как в Git, здесь нет. Объект в каждый момент может менять только один человек. Поэтому классических конфликтов при помещении почти не бывает, а реальные сложности возникают в двух местах: при обновлении типовой конфигурации на новый релиз и при объединении конфигураций из файла.
Хранилище бывает трёх видов по способу подключения:
| Вид | Как указывается путь | Когда подходит |
|---|---|---|
| Файловое | Каталог на диске или сетевой папке | 1–2 разработчика в одной локальной сети |
| Через сервер хранилища | tcp://имя_сервера/имя_хранилища (служба crserver, порт по умолчанию 1542) | Команда, нестабильная сеть, много объектов |
| Через веб-сервер | Адрес публикации по HTTP | Удалённые разработчики без VPN |
Для файлового хранилища по сетевой папке скорость падает заметно уже на крупных конфигурациях вроде ERP. Если обновление релиза идёт часами, первым делом стоит перевести хранилище на сервер хранилища.
«Обновить конфигурацию в хранилище» на практике означает одно из двух. Либо поместить туда свои доработки (обычный рабочий цикл). Либо обновить типовую часть на новый релиз фирмы-поставщика. Второй сценарий самый трудоёмкий, ему посвящена основная часть.
Подготовка: права в хранилище и рабочее место разработчика
Права пользователей хранилища
Пользователи хранилища — свои, они не связаны с пользователями информационной базы. Список открывается в Конфигураторе: Конфигурация → Хранилище конфигурации → Администрирование. Войти туда может только тот, у кого есть административные права в хранилище.
У каждого пользователя настраиваются флажки прав:
- 🛡 Административные функции — управление пользователями, отмена чужих захватов, служебные операции с историей.
- 🔒 Захват объектов — без него пользователь только читает и получает версии.
- 🏷 Изменение версий — правка комментариев и меток у уже помещённых версий.
Для обновления релиза нужен пользователь с правом захвата. Если релиз накатывает ведущий разработчик, удобно дать ему и административные функции: при обновлении часто приходится снимать забытые захваты коллег.
Рабочее место
Перед обновлением подготовьте отдельную базу-копию, подключённую к хранилищу. Не делайте обновление в базе, где параллельно идёт повседневная доработка: в ней могут висеть ваши незавершённые правки.
Что проверить заранее:
- ✅ версия платформы на машине не ниже той, что требует новый релиз (указана в описании релиза);
- ✅ под рукой файл обновления
.cfuили полный.cfнужного релиза; - ✅ известна цепочка: с какого релиза на какой можно обновиться напрямую;
- ✅ коллеги предупреждены, что на время обновления захватить объекты не смогут.
Перед обновлением сделайте копию хранилища. Для файлового хранилища это копия каталога целиком, для сервера хранилища — копия каталога, когда к нему никто не подключён. Копировать каталог во время работы людей нельзя: получится несогласованная копия. Если ради копии вы останавливаете службу crserver, все подключённые разработчики потеряют связь с хранилищем, поэтому делайте это вне рабочего времени.
Дополнительно сохраните текущую конфигурацию хранилища в файл: Конфигурация → Хранилище конфигурации → Сохранить конфигурацию хранилища в файл. Этот .cf пригодится для сравнения «до и после» и как запасной вариант отката.
Захват объектов в хранилище: сколько и как захватывать
Захват открывается из дерева конфигурации: правый клик по объекту → Хранилище конфигурации → Захватить в хранилище. В окне захвата есть два флажка:
- Рекурсивно — захватить объект вместе со всеми подчинёнными. Для корня конфигурации это означает захват всего.
- Получать захваченные объекты — перед захватом подтянуть из хранилища последнюю версию объекта. Держите этот флажок включённым, иначе вы начнёте править устаревший вариант.
Для обновления релиза захватывайте корень конфигурации рекурсивно. Причины две. Релиз поставщика меняет сотни объектов, и выборочный захват превращается в долгую охоту за каждым. А в корне хранятся настройки поддержки: без его захвата платформа не даст изменить состояние поддержки и применить обновление.
Если часть объектов уже захвачена коллегами, захват всей конфигурации не пройдёт. Посмотреть, кто что держит, можно в окне хранилища: Конфигурация → Хранилище конфигурации → Хранилище. Там видно владельца захвата по каждому объекту.
Варианты действий:
- Попросить коллегу поместить или отменить свои правки.
- Если человек недоступен, администратор хранилища снимает его захват. Правки этого разработчика по таким объектам останутся только в его базе, и ему придётся переносить их вручную после обновления.
Захват делают по согласованию в чате команды: «захватываю всё под релиз такой-то, до вечера ничего не берите». Такая простая договорённость спасает от потерянных правок лучше любых настроек.
Обновление типовой конфигурации поставщика в хранилище
Это основной алгоритм. Он выполняется в базе разработчика, подключённой к хранилищу, после рекурсивного захвата корня.
Шаг 1. Получить последнюю версию
Выполните Конфигурация → Хранилище конфигурации → Обновить конфигурацию из хранилища. Ваша конфигурация должна совпадать с последней версией хранилища, иначе вы обновите устаревший вариант.
Шаг 2. Запустить обновление поставщика
Откройте Конфигурация → Поддержка → Обновить конфигурацию. Укажите файл обновления: из каталога шаблонов или через выбор файла .cfu либо .cf. Платформа загрузит новую конфигурацию поставщика и откроет окно сравнения и объединения.
Шаг 3. Разобрать объекты в окне сравнения
Окно показывает три стороны: старую конфигурацию поставщика, вашу основную конфигурацию и новую конфигурацию поставщика. Для нетронутых типовых объектов правило объединения ставится автоматически. Работа нужна только по объектам, которые изменили и вы, и поставщик. Об этом подробнее в следующем разделе.
Шаг 4. Выполнить объединение и проверить
Нажмите «Выполнить». Затем:
- запустите синтаксический контроль модулей:
Конфигурация → Проверка конфигурации; - обновите конфигурацию своей базы (F7) и запустите её в режиме 1С:Предприятие;
- откройте документы и отчёты, которые вы дорабатывали.
Шаг 5. Поместить результат в хранилище
Выполните Конфигурация → Хранилище конфигурации → Поместить в хранилище. В комментарии укажите номер релиза, например: «Обновление до 3.0.ХХХ.ХХ, объединение доработок по документу Реализация». В окне помещения есть флажок «Оставить объекты захваченными» — снимите его, чтобы коллеги снова могли работать.
Обновление через отдельную базу
Если релиз большой, держать всю конфигурацию захваченной целый день неудобно. Практики делают так:
- Сохраняют конфигурацию хранилища в
.cf. - Разворачивают её в отдельной базе без подключения к хранилищу и спокойно обновляют там, разбирая конфликты сколько нужно.
- Сохраняют результат в
.cf. - Захватывают корень рекурсивно в базе, подключённой к хранилищу, и выполняют
Конфигурация → Сравнить, объединить с конфигурацией из файла. - Проверяют и помещают.
Захват при этом длится не день, а один-два часа. После такого объединения откройте Конфигурация → Поддержка → Настройка поддержки и убедитесь, что указана версия нового релиза поставщика. Если версия осталась старой, следующий релиз встанет с лишними конфликтами.
Конфликты при объединении версий: как их разрешать
Конфликт — это объект, который изменён и в вашей конфигурации, и у поставщика. Платформа помечает такие объекты в окне сравнения. Чтобы не листать тысячи строк, включите в окне отбор, при котором показываются только дважды изменённые свойства.
По каждому такому объекту выбирается режим объединения:
| Режим | Что произойдёт | Когда выбирать |
|---|---|---|
| Взять из новой конфигурации поставщика | Ваши правки в объекте теряются | Правка больше не нужна или поставщик сделал то же самое |
| Объединить с приоритетом основной конфигурации | Сливаются обе версии, при пересечении побеждает ваша | Доработка важнее, изменений поставщика немного |
| Объединить с приоритетом новой конфигурации поставщика | Сливаются обе версии, при пересечении побеждает поставщик | Ваши правки точечные, у поставщика крупная переработка |
| Не объединять | Объект остаётся как был у вас | Временно, если нужно разобраться позже |
Для модулей объединение идёт по процедурам. Платформа сравнивает текст и может склеить его так, что код синтаксически верен, но логически сломан. Поэтому каждый объединённый модуль открывайте и просматривайте глазами, особенно процедуры, где ваша вставка стоит посреди типового кода.
С формами сложнее. Объединение управляемых форм часто даёт лишние или пропавшие элементы. Надёжнее взять форму от поставщика и заново внести свои изменения, а их список заранее выписать.
Каждый конфликт при обновлении — это доработка, вшитая в типовой объект. Переносите такие доработки в расширения конфигурации. Расширения не участвуют в объединении с релизом, и следующий релиз встанет почти без ручной работы.
Ещё один источник конфликтов — отключение от хранилища. Если разработчик отключился, правил объекты, а потом подключился заново, платформа предложит получить конфигурацию из хранилища, и локальные правки затрутся. Перед повторным подключением сохраните свою конфигурацию в .cf, а после подключения захватите нужные объекты и перенесите правки через «Сравнить, объединить с конфигурацией из файла».
Как раздать обновлённую конфигурацию команде и в рабочую базу
Остальные разработчики выполняют Конфигурация → Хранилище конфигурации → Обновить конфигурацию из хранилища, а затем F7 у себя.
Рабочую базу пользователей к хранилищу обычно не подключают. Варианты доставки:
Обновление структуры рабочей базы требует монопольного доступа: пользователей нужно выгнать из базы, их сеансы будут завершены. Планируйте это на нерабочее время и сделайте резервную копию базы.
После F7 в типовых конфигурациях при первом входе запускается обработка обновления данных информационной базы. На крупной базе она идёт долго, это нормально.
История хранилища: сравнение версий, метки и откат
История открывается командой Конфигурация → Хранилище конфигурации → История хранилища. В списке у каждой версии номер, дата, пользователь и комментарий. Отсюда удобно разбирать, что изменилось и кем.
Что можно сделать с версией:
- 🔍 Сравнить две версии или версию с текущей конфигурацией — увидите все изменённые объекты и код.
- 📄 Получить отчёт по версиям — список изменений в виде табличного документа, удобно для описания доработок.
- 💾 Сохранить в файл — выгрузить конфигурацию этой версии в
.cf. - 🏷 Установить метку — пометить версию, например «Релиз 3.0.ХХХ, выложено в рабочую». По меткам потом быстро находят нужную точку.
Как откатить хранилище к прошлой версии
Есть два пути, и они сильно различаются по последствиям.
Мягкий откат: новая версия поверх. Сохраните нужную старую версию в файл, захватите затронутые объекты, объедините с этим файлом и поместите как новую версию с комментарием «Откат к версии N». История сохраняется целиком, ошибку можно отследить. Этот способ подходит почти всегда.
Жёсткий откат через администрирование. Администратор хранилища может откатить хранилище к выбранной версии, и все последующие версии будут удалены. Удалённые версии не восстановить без копии каталога хранилища. Пользуйтесь им, только если последние версии гарантированно мусорные, например после ошибочного помещения чужой конфигурации, и только после копии.
После любого отката всем разработчикам нужно выполнить «Обновить конфигурацию из хранилища». Тем, у кого были захвачены объекты, придётся сверить свои правки с новым состоянием.