Управление множеством хранилищ конфигурации: сервер хранилищ, ветки, именование, конфигуратор

Хранилища конфигурации, сервер хранилищ, хранилища-ветки и именование для нескольких команд разработки мы свели в одну памятку: админ выдаёт место на диске, в конфигураторе кто-то создаёт каталог или регистрирует имя, и через полгода без опроса неясно, где лежит релизное хранилище-ветка для системы. Текст для тимлида, администратора сервера разработки или ведущего, который отвечает за десятки хранилищ: хаос общей шары, ограничения crserver, практика веток и схема «команда, система, ветка», чтобы адрес набирали с клавиатуры, когда конфигуратор снова «забыл» путь.

От общей шары к зоопарку: как появляются хранилища

Типовая точка старта выглядела так. Несколько команд 1С просят «сетевую папку под хранилище», администратор расшаривает на файловом сервере каталог вроде 1C_storage, часто на том же хосте, где крутится разработческий кластер. Дальше каждая команда сама создаёт подкаталоги, иногда вкладывает одно хранилище внутрь другого, и границы ответственности размываются.

Файловое хранилище в диалоге конфигуратора «Хранилище конфигурации» задаётся УНС-путём или локальным путём на сервере, например \\fileserver\1C_storage\team_a\docflow. Запись в такую шару обычно открыта широкому кругу разработчиков. Кто-то копирует каталог хранилища «для эксперимента», кто-то переименовывает соседнюю папку, и риск задеть чужие данные оказывается выше, чем кажется на первый взгляд.

Отдельная боль - резервное копирование. После расшаривания папку часто не включают в отдельный регламент: живёт общий снимок виртуальной машины, а иногда нет и его. Восстановить случайно испорченное хранилище конфигурации без согласованного бэкапа каталога или тома мы уже не могли бы обещать команде.

Когда у одной системы заводят несколько хранилищ - основное, тестовое, «на завтра в прод» - без правил именования путаница dev, release и test становится нормой. Файловый доступ терпим, пока разработчиков двое и хранилище одно; при четырёх-пяти командах и десятках систем шара превращается в неконтролируемый зоопарк, даже если все участники добросовестные.

Мы фиксировали цепочку событий на таких площадках: расшарили каталог, появились «временные» подпапки, в одну из них переехало «стабильное» хранилище, owner не записали.

После такой хронологии искали уже не файлы, а смысл имён каталогов.

Сервер хранилищ: что улучшилось и что осталось неконтролируемым

Следующий шаг эволюции - сервер хранилищ 1С (служба crserver). Прямое удаление каталога с данными хранилища перестаёт быть главным способом «администрирования», появляются штатные операции блокировки пользователей и администрирования из конфигуратора.

Адрес при подключении другой: tcp://<хост>:<порт>/<имя_хранилища>, типовой порт - 1542. Имя в URI должно совпадать с тем, что зарегистрировано на сервере; путь к файлам на диске разработчик в строке подключения не видит, но при создании нового хранилища конфигуратор по-прежнему позволяет указать произвольный каталог на сервере. Никакой автоматической укладки «по полочкам команд» платформа не даёт.

Подключение конфигуратора к серверу хранилищ идёт по tcp к службе crserver; на схеме ниже упрощённая последовательность обмена.

Если на этом шаге версия протокола или платформы не сходится, дальше мы видели только ошибку несовместимости, а не список «последних хранилищ».

Когда на диске кончается место, администратор видит набор зарегистрированных имён и непонятные гигабайты в случайных путях. Без опроса тимлидов мы не отличали устаревшее fеатуре-хранилище от релизного. Мини-чеклист для сервера хранилищ, который я обычно прохожу вручную: выписать имена из администрирования сервера, сопоставить с матрицей «команда / система / ветка / версия платформы», проставить оwнер-тимлида, пометить устаревшие; мониторинг тут не заменяет разговор с командами.

Ещё жёстче связка с версией платформы. Сервер хранилищ обслуживает хранилища, созданные конфигуратором определённой линейки версий. Подключить хранилище, созданное более новым конфигуратором, к старому серверу нельзя: сначала обновление сервера хранилищ, а это затрагивает все хранилища на этом экземпляре. При несовпадении версии конфигуратора и версии, которой создано или обслуживается хранилище, подключение обрывается сообщением о несовместимости (формулировка зависит от релиза; смысл один - версии нужно выровнять).

Отсюда практический сценарий миграции: prod на одной версии платформы, разработка на более новой, параллельно два сервера хранилищ или два набора имён, и явная колонка «версия» в инвентаре. Смешать ветки dev и stable на одном сервере без учёта версии легко при «обновим конфигуратор у одной команды».

Хранилища-ветки и релизная «подливка»

Штатного ветвления хранилищ в платформе без СППР нет. Команды всё равно делают хранилища-ветки: в основном хранилище копят несколько фич, а в релиз уходит не всё. Для этого заводят второе хранилище - релизное, «подливочное»: в него вручную переносят только те изменения, которые нужны в ближайшем выпуске. Остальное остаётся в dev до созревания.

Фирма 1С близка к этой идее рекомендацией заводить отдельное хранилище под задачу. В СППР создание и снятие такого хранилища автоматизировано: задача закрыта - хранилище можно удалить по регламенту. У кого СППР в контуре разработки есть, дисциплина имен и жизненного цикла уже частично встроена в процесс.

Для остальных смысл этой статьи как раз в том, чтобы воспроизвести ту же дисциплину вручную или скриптами в рамках именования и инвентаря, не обещая полный ДевОрс-цикл. Git и EDT меняют способ хранения исходников, но пока часть команд живёт в конфигураторе и хранилищах конфигурации, правила веток и адресов остаются на совести тимлида.

Я обычно закладываю минимум два хранилища на систему в матрице: dev (ежедневная работа) и stable или release (подливка). Fеатуре-ветку под длинную задачу имеет смысл только если есть owner и дата снятия; иначе fеатуре-хранилища размножаются быстрее, чем их успевают удалять.

Параллельно в этот момент часто идут три линии: daily dev, ручная подливка в stable, prod ещё на старой версии платформы.

Если не держать версию платформы отдельной колонкой, адрес stable и dev начинают выглядеть взаимозаменяемыми, хотя серверы хранилищ разные.

Почему конфигуратор усугубляет хаос

Конфигуратор не ведёт для нас историю последних хранилищ. Сменили версию платформы, создали новую информационную базу под ветку, открыли другой ярлык - поля пути к хранилищу и пользователя хранилища часто оказываются пустыми. Платформа не подсказывает «вы вчера ходили сюда».

Привязка базы к хранилищу живёт в настройках информационной базы и в профиле запуска (строка подключения к ИБ, параметры конфигуратора). Канонический реестр адресов для команды живёт отдельно от привязки в ИБ: локальная база на ноутбуке может помнить один путь, а эталон релиза - другой. Когда конфигуратор «забыл», мы восстанавливали связку из вики, таблицы или файла; у части коллег помогал плагин Снегопата, который запоминает путь в своих настройках, но на него полагаться как на корпоративный стандарт нельзя.

Отсюда требование к схеме имён: адрес должен вычисляться из роли базы (команда, система, ветка) и набираться по памяти, без поиска в базе знаний. Если для подключения к stable нужно вспомнить, что папка когда-то называлась zup_1, правила уже проиграли.

Имена папок и адреса: где ломается договорённость

Бытовой диалог без выдуманной катастрофы, но с узнаваемой логикой. Тимлид спрашивает, где хранилище для 1С:Документооборот. Ответ: \\server\1C_storage\doc. Уточнение: нужно стабильное, откуда собирают релиз. Ответ уже другой: \\server\1C_storage\zup_1. Вопрос «почему Документооборот в zup_1» получает честное «там раньше был ЗУП, стёрли, переиспользовали каталог».

Второй сценарий - вложенность ролей. «Стабильная» ветка лежит внутри каталога, который по смыслу разработческий: ...\dev\new2 числится stable в переписке, но по пути это fеатуре-эксперимент. Новый человек подключается к dev и тянет в основную ветку то, что команда считала изолированным.

На сервере хранилищ провал другой формы: красивое имя в URI (tcp://srv-repo:1542/DO) и нечитаемый путь на диске, который при чистке диска никто не сопоставил с owner. Имя в tcp должно быть частью схемы, а не аббревиатурой «как привыкли».

Матрица: команда, система, ветка, версия платформы

Инструмент мысли для инвентаризации при нескольких командах и десятках систем - таблица с измерениями: команда разработки, система (продукт/конфигурация), ветка (dev, stable, feature), путь или тср-адрес, версия платформы сервера хранилищ, owner (тимлид), статус (актуально / устарело / к удалению).

Такую матрицу мы вели в wiki или таблице; главное - один канонический источник, а не разрозненные комментарии в чатах. Для файловых хранилищ в колонке «Адрес» - полный UNC; для сервера - только tcp URI, без смешения форматов в одной ячейке.

Чтобы не разъезжались строки матрицы и факт на сервере, раз в квартал или перед миграцией версии сверяли список имён на сервере хранилищ с таблицей и помечали сироты: имя есть на сервере, строки в матрице нет - кандидат на блокировку и опрос.

Если команда ведёт учёт хранилищ во внутренней базе на языке 1С, удобно собрать срез «что считаем актуальным» одним запросом к регистру сведений, где вы сами храните инвентарь (имена регистра и измерений - ваши, не типовые).

Запрос ниже выводит актуальные хранилища одной команды для сверки с сервером перед обновлением платформы.

ВЫБРАТЬ
    Инвентарь.Команда КАК Команда,
    Инвентарь.Система КАК Система,
    Инвентарь.Ветка КАК Ветка,
    Инвентарь.АдресПодключения КАК АдресПодключения,
    Инвентарь.ВерсияПлатформы КАК ВерсияПлатформы,
    Инвентарь.Тимлид КАК Owner
ИЗ
    РегистрСведений.ИнвентарьХранилищКонфигурации КАК Инвентарь
ГДЕ
    Инвентарь.Команда = &Команда
    И Инвентарь.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыХранилища.Актуально)
УПОРЯДОЧИТЬ ПО
    Инвентарь.Система,
    Инвентарь.Ветка

В результате смотрим на полный список адресов и версий для одной команды: если для stable указана версия новее, чем установлена на сервере хранилищ ррод-контура, миграцию нужно планировать до смены конфигуратора у разработчиков.

Системные правила: кто создаёт хранилища и как строить адрес

Изоляция по команде - первый принцип. У каждой команды свой префикс в имени хранилища или корневой каталог на сервере, права на создание новых хранилищ только у тимлида (или у администратора по заявке от тимлида). Разработчик подключается к уже существующим адресам из матрицы, а не создаёт новое имя в диалоге конфигуратора.

Настройки в разрезе системы: на одну продуктовую систему - несколько хранилищ (dev, stable, при необходимости feature с датой удаления). Создание и списание ведёт тимлид, в инвентаре явно помечаются устаревшие; удаление на сервере хранилищ - только после блокировки пользователей и бэкапа каталога или снимка тома/ВМ, согласованного с регламентом. Штатные операции администрирования хранилища в конфигураторе (блокировка, отключение пользователей) здесь не заменяют бэкап, но без блокировки копировать живое хранилище рискованнее.

Шаблон имени, который у нас хорошо ложился на tcp URI и на каталоги, выглядел так: <префикс_команды>_<краткое_имя_системы>_<ветка>, латиница, без пробелов, ветка из фиксированного набора dev, stable, feature<номер>. Пример: UCHET_DO_stable в URI tcp://repo-dev:1542/UCHET_DO_stable. Для файлового варианта тот же хвост в конце UNC: \\fileserver\1C_storage\UCHET\UCHET_DO_stable.

Правила должны быть настолько просты, что после очередного сброса диалога конфигуратора адрес восстанавливается из роли базы, а не из архива переписки. Если схема требует открыть корпоративную wiki ради каждого подключения, она слишком сложная.

Цикл, который мы повторяли после каждой миграции версии, сводился к инвентарю, согласованию имён, созданию только тимлидом, записи в матрицу, регламенту бэкапа и квартальной сверке с сервером.

Я сознательно не расписываю развёртывание Ansible, REST-API и «полный цикл» автоматизации: это возможное продолжение, но ядро управления - середина между общей шарой и CI/CD. Сейчас имеет смысл проверить у себя три вещи: есть ли единая матрица с колонкой версии, может ли произвольный разработчик создать новое хранилище без тимлида, и восстановите ли вы адрес stable по схеме имени без подсказки конфигуратора. Если на второй пункт ответ «да», зоопарк, скорее всего, уже растёт.