Командная разработка в 1С через хранилище: от установки до резервных копий
Содержание
Хранилище конфигураций 1С — это общая база исходников, к которой подключают свои информационные базы несколько разработчиков. Каждый объект метаданных (справочник, документ, общий модуль) один человек «захватывает», правит у себя и «помещает» обратно. Хранилище запоминает каждую версию, автора и комментарий, поэтому любое изменение можно найти и откатить.
Работает механизм на уровне платформы 1С:Предприятие 8.3 и одинаково для любой конфигурации: БП, ЗУП, УТ, ERP или самописной. Все команды — в Конфигураторе, меню Конфигурация → Хранилище конфигурации. Ниже — как его развернуть, настроить права, вести версии и не потерять историю.
Как устроено хранилище конфигураций и что оно решает
Хранилище — отдельная файловая база, не связанная с данными учёта. В ней лежат только метаданные и код. Внутри каталога хранилища главный файл — 1cv8ddb.1CD, рядом служебные папки с данными версий и кешем.
Схема работы такая:
- 🗄️ Хранилище — эталон конфигурации и вся её история.
- 💻 Рабочая база разработчика — своя копия, подключённая к хранилищу. Изменения делаются только здесь.
- 🔒 Захват — блокировка объекта за одним человеком. Пока объект захвачен, другие видят его только для чтения.
- 📦 Помещение — отправка изменений в хранилище. Появляется новая версия с номером и комментарием.
- 🔄 Получение — загрузка в свою базу того, что поместили коллеги.
Что это даёт команде:
| Задача | Без хранилища | С хранилищем |
|---|---|---|
| Два разработчика правят один модуль | Затирают изменения друг друга | Второй ждёт, пока первый поместит |
| Найти, кто сломал проведение | Гадание по файлам .cf | История версий с автором и датой |
| Откатить неудачную доработку | Восстановление всей базы | Получение объекта нужной версии |
| Собрать поставку | Ручное объединение | Сохранение версии хранилища в .cf |
Хранилище нужно не только команде. Даже один разработчик выигрывает от истории версий: можно сравнить модуль «до» и «после» и увидеть, когда появилась ошибка.
Сервер хранилища или общая папка: как развернуть
Хранилище можно разместить двумя способами.
Файловый вариант. Каталог на общем сетевом ресурсе, путь вида \\fileserver\repo\Buh. Ставить ничего не нужно, но у всех разработчиков должны быть права на запись в папку. При обрыве сети во время помещения файл хранилища может повредиться.
Сервер хранилища (crserver). Отдельная служба, к которой клиенты обращаются по TCP. Файлы хранилища лежат только на сервере, у разработчиков к ним прямого доступа нет. Это надёжнее и быстрее при удалённой работе.
| Вариант | Когда подходит | Риски |
|---|---|---|
| Сетевая папка | 1–2 разработчика в одной локальной сети | Повреждение файла при обрыве, широкие права на папку |
| Сервер хранилища по TCP | Команда, удалённые сотрудники | Нужно следить за службой и портом |
| Доступ по HTTP через веб-сервер | Разработчики за пределами сети, без VPN | Нужна публикация и защищённое соединение |
Установка сервера хранилища
- Запустите установщик технологической платформы на сервере и отметьте компонент «Сервер хранилища конфигураций 1С:Предприятия».
- Создайте каталог для хранилищ, например
D:\Repo. - Зарегистрируйте службу из папки
binплатформы командой от имени администратора:
cd "C:\Program Files\1cv8\8.3.25.1445\bin"
crserver.exe -instsrvc -port 1542 -d D:\Repo -usr .\svc1c -pwd ПарольСлужбы
crserver.exe -start
- Откройте на брандмауэре входящий порт
1542(это порт по умолчанию, его можно сменить). - Проверьте, что служба запущена, в оснастке
services.msc.
Номер версии в пути подставьте свой. Учётная запись службы должна иметь полные права на каталог D:\Repo, иначе создание хранилища завершится ошибкой доступа.
Версия сервера хранилища должна совпадать с версией платформы, из которой подключаются разработчики. При обновлении платформы у команды обновите и crserver, иначе подключение не пройдёт.
Создание хранилища конфигурации и подключение разработчиков
Хранилище создаёт один человек — тот, кто станет его администратором.
- Откройте эталонную базу в Конфигураторе.
- Выберите
Конфигурация → Хранилище конфигурации → Создать хранилище…. - Укажите адрес: для сервера —
tcp://srv-1c/Buh(путь берётся относительно каталога-dслужбы), для папки — сетевой путь. - Задайте имя и пароль администратора хранилища. Это не пользователь базы, это отдельная учётная запись хранилища.
- Дождитесь, пока конфигурация целиком поместится в хранилище. На больших типовых это занимает от десятков минут.
Подключение второго и следующих разработчиков:
- Создайте у разработчика пустую информационную базу (или возьмите копию рабочей).
- Откройте её в Конфигураторе:
Конфигурация → Хранилище конфигурации → Подключиться к хранилищу…. - Введите адрес, логин и пароль, выданные администратором.
- Платформа предупредит, что конфигурация базы будет заменена конфигурацией хранилища. Согласитесь.
- После загрузки выполните «Обновить конфигурацию базы данных».
Для разработчика лучше база с урезанными данными: обновление структуры на копии рабочей базы в сотни гигабайт будет идти часами при каждом получении изменений.
Захват, помещение и версии в хранилище 1С
Ежедневный цикл разработчика укладывается в пять действий.
- Получить актуальную версию: в окне хранилища
Получить из хранилищадля всей конфигурации. - Захватить нужные объекты: правый клик по объекту в дереве →
Хранилище → Захватить в хранилище. Флажок «Рекурсивно» захватывает объект вместе с подчинёнными. - Внести изменения и проверить их в режиме отладки.
- Поместить объекты:
Поместить в хранилище, обязательно с комментарием. Флажок «Оставить объекты захваченными» нужен, если работа продолжается. - Отменить захват того, что трогали зря, чтобы не держать объекты.
Комментарий к помещению — главный инструмент поиска в истории. Пишите номер задачи и суть: «ЗАД-418: контроль остатков при проведении реализации». Комментарий «правки» через полгода ничего не скажет.
Как пользоваться историей
Конфигурация → Хранилище конфигурации → История хранилища… показывает все версии. Из этого окна можно:
- 🔍 открыть версию и посмотреть состав изменённых объектов;
- ⚖️ сравнить две версии между собой или версию с текущей конфигурацией;
- 💾 сохранить конфигурацию
нужной версии в файл
.cf; - 🏷️ установить метку на версию, например «Релиз 2.4 для рабочей базы».
Метки — удобный способ отмечать, что именно ушло в рабочую базу. По ним потом быстро находится состояние на момент выкладки.
Ветвление в хранилище конфигураций: как работают без веток
В хранилище нет веток в привычном смысле Git. История линейная: одна последовательность версий. Команды решают это организационно.
Отдельное хранилище на ветку. Основная разработка идёт в одном хранилище, исправления для рабочей базы — во втором. Второе создают из конфигурации, сохранённой по метке релиза. Срочный фикс помещают туда, а затем переносят в основное через Сравнить и объединить.
Хранилище для каждого крупного проекта. Долгая доработка (например, новый блок учёта на три месяца) живёт в своём хранилище. В основное её переносят одним объединением после приёмки.
Расширения конфигурации . Доработки, которые можно вынести в расширение, держат в отдельном хранилище расширения. Основная конфигурация меньше конфликтует при обновлении типовой.
| Подход | Плюсы | Минусы |
|---|---|---|
| Одно хранилище, метки на релизы | Просто, всем понятно | Срочный фикс приходится делать поверх незаконченной работы |
| Основное + хранилище исправлений | Можно выпустить фикс в любой момент | Двойная работа при переносе изменений |
| Хранилище на проект | Изоляция долгих доработок | Тяжёлое объединение в конце |
Перед объединением конфигураций сохраните текущую конфигурацию хранилища в файл. Ошибка в настройках сравнения может удалить объекты, и откат через историю займёт время.
Права пользователей хранилища и защита исходников
Пользователей заводит администратор: Конфигурация → Хранилище конфигурации → Администрирование…. У каждого пользователя хранилища свой логин и пароль, не связанные с пользователями информационной базы и Windows.
Права назначаются флажками:
- 👤 Захват объектов — можно блокировать и изменять объекты. Без этого права пользователь только читает и получает версии.
- 📝 Изменение состава версий — можно править комментарии и метки версий.
- 🛠️ Административные функции — управление пользователями и настройками хранилища.
Практика распределения:
- разработчикам — только захват;
- ведущему разработчику — захват и изменение версий;
- административные функции — одному-двум людям, не на каждодневной учётной записи;
- аналитикам и тестировщикам — пользователь без прав, только чтение.
Защита на уровне сервера
Право «только чтение» не мешает выгрузить всю конфигурацию. Поэтому выдавайте логины в хранилище лишь тем, кому код действительно нужен. Для сервера хранилища закройте порт 1542 от внешней сети и пускайте удалённых разработчиков через VPN. Сетевую папку хранилища не открывайте на запись всем доменным пользователям.
Когда разработчик уходит из команды, удалите или заблокируйте его пользователя. Если за ним остались захваченные объекты, администратор сбрасывает ему пароль, подключается под его именем и отменяет захват.
Хранилище 1С и Git: связь с внешними системами контроля версий
Хранилище закрыто внутри 1С: нельзя сделать pull request, запустить проверку кода или посмотреть изменения в браузере. Поэтому многие команды дублируют историю в Git.
Выгрузка версий через пакетный режим
Конфигуратор умеет работать с хранилищем из командной строки. Это основа любой автоматизации:
"C:\Program Files\1cv8\8.3.25.1445\bin\1cv8.exe" DESIGNER /F "D:\Bases\Build" ^
/ConfigurationRepositoryF "tcp://srv-1c/Buh" ^
/ConfigurationRepositoryN "build" /ConfigurationRepositoryP "Пароль" ^
/ConfigurationRepositoryUpdateCfg -force ^
/DumpConfigToFiles "D:\Git\Buh" ^
/Out "D:\Logs\build.log"
Скрипт получает последнюю версию хранилища в служебную базу и выгружает конфигурацию в XML-файлы. Дальше каталог коммитится в Git. Для ежедневной сборки такой скрипт ставят в планировщик заданий.
Синхронизация «версия за версией»
Чтобы в Git попала вся история с авторами и комментариями, используют готовые инструменты на OneScript, например gitsync. Он читает отчёт по хранилищу, по очереди получает каждую версию и делает отдельный коммит от имени автора помещения.
Служебная база для выгрузки должна быть отдельной. Не подключайте к ней разработчиков и не захватывайте в ней объекты: пользователь build нужен только для чтения.
Обслуживание хранилища конфигураций: копии и оптимизация
Хранилище растёт с каждой версией. За несколько лет на типовой конфигурации каталог разрастается до десятков гигабайт. Без обслуживания падает скорость получения и истории.
Резервное копирование
- Раз в сутки сохраняйте конфигурацию хранилища в
.cfчерез пакетный режим (/ConfigurationRepositoryDumpCfg). Это быстрая страховка последней версии. - Делайте копию всего каталога хранилища — только она сохраняет историю.
- Копируйте каталог, когда никто не помещает изменения: ночью или с остановкой службы crserver.
Остановка службы crserver обрывает работу всех разработчиков с хранилищем. Помещение, начатое в этот момент, не завершится. Останавливайте службу вне рабочего времени и заранее предупредите команду.
Проверьте восстановление хотя бы раз: разверните копию на тестовом сервере и откройте историю. Копия, которую ни разу не поднимали, — не копия.
Оптимизация и проверка
- 🧹 В окне администрирования хранилища есть команда оптимизации хранения данных. Она уплотняет файлы и ускоряет работу, запускайте её после крупных помещений.
- 🩺 Файл
1cv8ddb.1CDможно проверить утилитойchdbfl.exeиз папкиbinплатформы. Работайте только с копией и только при остановленной службе. - 📉 Следите за свободным местом на диске сервера: нехватка места во время помещения — частая причина повреждения.
Типичные сбои хранилища и что с ними делать
Большинство проблем связаны с сетью, версиями платформы и «забытыми» захватами.
Ещё одна частая ситуация — разработчик отключился от хранилища и подключился заново, потеряв незавершённые изменения. Перед отключением всегда сохраняйте конфигурацию в файл: после повторного подключения её можно сравнить и объединить с конфигурацией хранилища.