Групповая разработка в 1С 8.3 через хранилище: устройство, подключение, захват и версии
Содержание
Хранилище конфигурации 1С — это общая база версий, в которой несколько разработчиков ведут одну конфигурацию. Создаётся и настраивается оно в Конфигураторе через меню Конфигурация → Хранилище конфигурации → Создать хранилище, а остальные участники подключаются к нему командой Подключиться к хранилищу. Объект меняет только тот, кто его захватил; остальные видят замок и ждут, пока изменения поместят обратно.
Типичная ситуация: двое программистов дорабатывают одну базу Бухгалтерии, правят один и тот же общий модуль и затирают друг другу код при выгрузке .cf. Хранилище решает именно эту задачу — оно не даёт двум людям одновременно менять один объект и хранит каждую версию с автором, датой и комментарием.
Как устроено хранилище и что в нём лежит
Хранилище — отдельная от информационной базы сущность. Физически это каталог с файлом 1cv8ddb.1CD и служебными папками. В нём лежат все версии конфигурации, список пользователей хранилища и сведения о захватах.
У каждого разработчика своя информационная база, подключённая к хранилищу. Схема работы такая:
- 📥 разработчик получает актуальную версию объектов из хранилища в свою базу;
- 🔒 захватывает объекты, которые будет менять, — в хранилище отмечается, что они заняты им;
- ✏️ правит их у себя и отлаживает в своей базе;
- 📤 помещает изменения обратно — появляется новая версия, захват снимается.
Пока объект захвачен, другие участники могут его получить и посмотреть, но изменить у себя не могут: в дереве метаданных он показан как недоступный для редактирования. Это пессимистическая блокировка — конфликтов слияния здесь нет, их предотвращают заранее.
Хранилище версионирует только конфигурацию. Данные — документы, справочники, остатки — в нём не хранятся. Резервную копию рабочей базы делают отдельно.
Три способа доступа к хранилищу
| Способ | Строка подключения | Когда подходит |
|---|---|---|
| Файловый | D:\Repo\Buh или \\srv\Repo\Buh | 1–3 разработчика в одной локальной сети |
| Сервер хранилища (TCP) | tcp://srv/D:\Repo\Buh | команда, удалённые сотрудники, стабильная работа |
| HTTP через веб-сервер | http://srv/repo/repo.1ccr | доступ из интернета, когда открыт только порт 80/443 |
Файловый вариант самый простой, но при работе по сети с общей папкой выше риск повредить файл хранилища при обрыве связи. Для команды от трёх человек лучше сразу ставить сервер.
Создание хранилища конфигурации и подключение разработчиков
Шаг 1. Подготовьте эталонную базу
Возьмите базу с той конфигурацией, которую будете вести. Если конфигурация типовая и стоит на поддержке, решите заранее: включаете ли возможность изменения. Без неё захватить объекты не получится.
Сделайте выгрузку Администрирование → Выгрузить информационную базу в файл .dt. Создание хранилища и первое помещение меняют служебные данные базы — копия нужна обязательно.
Шаг 2. Создайте хранилище
- Откройте базу в Конфигураторе, затем откройте дерево конфигурации (
Конфигурация → Открыть конфигурацию). - Выберите
Конфигурация → Хранилище конфигурации → Создать хранилище. - Укажите каталог хранилища или адрес сервера
tcp://…. - Задайте имя и пароль администратора хранилища. Это отдельная учётная запись, она не связана с пользователями информационной базы.
- Подтвердите. Платформа поместит в хранилище всю конфигурацию как первую версию, а база станет подключённой.
На больших конфигурациях вроде ERP первое помещение идёт долго — от десятков минут. Окно Конфигуратора в это время лучше не трогать.
Шаг 3. Заведите пользователей
Откройте Конфигурация → Хранилище конфигурации → Администрирование. На закладке пользователей добавьте каждого разработчика и отметьте права:
- 🔑 Захват объектов — может менять конфигурацию;
- 🗂️ Изменение версий — может править комментарии и метки чужих версий;
- 🛠️ Административные функции — управляет пользователями и захватами.
Учётку «только чтение» делают без права захвата: например, для базы тестировщика, которая регулярно обновляется из хранилища.
Шаг 4. Подключите базы разработчиков
Каждый разработчик разворачивает у себя копию базы
из .dt и выполняет Конфигурация → Хранилище конфигурации → Подключиться к хранилищу. Платформа сравнит конфигурацию базы с хранилищем и предложит заменить её содержимым хранилища — соглашайтесь, иначе подключённая база будет расходиться с общей версией.
Один пользователь хранилища — одна информационная база. Если подключить вторую базу под тем же именем, первая перестанет считаться подключённой, а её захваты повиснут.
Сервер хранилища crserver
Сервер хранилища — отдельный компонент платформы, он ставится из того же дистрибутива и работает как служба Windows. По умолчанию слушает порт 1542. Запуск вручную для проверки:
"C:\Program Files\1cv8\8.3.24.1548\bin\crserver.exe" -port 1542 -d "D:\Repo"
Ключ -port задаёт порт, -d — корневой каталог, внутри которого лежат хранилища. Полный список ключей, в том числе для установки службы, выводит сам crserver.exe при запуске со справочным ключом. Версия сервера хранилища должна совпадать с версией платформы у разработчиков.
Для HTTP-доступа на веб-сервере публикуют файл с расширением .1ccr — это небольшой XML, в котором указан адрес TCP-сервера хранилища:
<?xml version="1.0" encoding="UTF-8"?>
<repository connectString="tcp://localhost:1542"/>
Разработчик подключается уже по адресу http://…/repo.1ccr.
Хранилище или синхронизация через сравнение конфигураций
Без хранилища команда обычно живёт так: каждый правит свою копию, а потом изменения переносят через Конфигурация → Сравнить, объединить с конфигурацией из файла. Это рабочий путь для редких доработок, но при плотной разработке он ломается на ручном слиянии.
| Критерий | Хранилище конфигурации | Сравнение и объединение .cf | EDT + Git |
|---|---|---|---|
| Блокировка | Захват объекта, второй ждёт | Нет, конфликты разбирают вручную | Нет, слияние по файлам |
| История | Каждая версия с автором и комментарием | Только если сами храните .cf | Полная история коммитов |
| Порог входа | Низкий, всё в Конфигураторе | Минимальный | Высокий: новая среда, Git |
| Параллельная работа над одним модулем | Невозможна | Возможна, но объединение трудоёмкое | Возможна, с ветками |
| Где удобно | Команда 2–15 человек на одной конфигурации | Разовые доработки, перенос расширений | Крупные проекты, ревью кода, CI |
Хранилище хорошо там, где важна дисциплина и простота: никто не перетрёт чужую работу, а откатиться можно на любую версию. Его слабое место — длительные захваты: если коллега взял общий модуль на неделю, остальные стоят.
Работа с версиями: история, метки и откат
Каждое помещение создаёт новую версию с номером. Историю открывают через Конфигурация → Хранилище конфигурации → История хранилища. В ней видно, кто, когда и с каким комментарием поместил изменения.
Что можно сделать с любой версией из истории:
- 🔍 открыть состав изменений и сравнить её с текущей конфигурацией хранилища или с другой версией;
- 💾 сохранить конфигурацию этой версии в файл .cf — так собирают поставку для рабочей базы;
- 🏷️ установить метку, например «Релиз 2.4 — ушёл в продуктив»;
- 📄 получить отчёт по изменённым объектам.
Как откатить неудачное изменение
Прямой команды «удалить версию» для обычной работы нет. Откат делают так:
- В истории найдите последнюю удачную версию и сохраните её в .cf или сравните с текущей.
- Захватите объекты, которые нужно вернуть.
- Перенесите в них старое состояние через сравнение и объединение.
- Поместите в хранилище с комментарием «Откат изменений версии N».
Так история остаётся честной: видно и ошибку, и её исправление.
Пишите комментарий к каждому помещению. Строка «Задача 412: доработка печатной формы счёта» через полгода сэкономит поиск по сотне безымянных версий.
Автоматическое обновление тестовой и рабочей базы
Тестовую базу удобно обновлять из хранилища по расписанию пакетным запуском Конфигуратора:
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F "D:\Bases\Test" /N "Админ" /P "" ^
/ConfigurationRepositoryF "tcp://srv/D:\Repo\Buh" ^
/ConfigurationRepositoryN "test" /ConfigurationRepositoryP "pass" ^
/ConfigurationRepositoryUpdateCfg -force /UpdateDBCfg /Out "D:\Logs\update.log"
/ConfigurationRepositoryUpdateCfg получает конфигурацию из хранилища, /UpdateDBCfg применяет её к базе. Пароли в такой файл кладут только для служебной учётки без права захвата.
Рабочую базу к хранилищу обычно не подключают. В неё переносят .cf, сохранённый из нужной версии, через Конфигурация → Сравнить, объединить или загрузку целиком, в окно регламентных работ. Обновление структуры рабочей базы требует монопольного доступа — пользователей нужно заранее предупредить и завершить их сеансы.
Ошибки при работе с хранилищем и как их устранить
Конфигурация → Хранилище конфигурации → Открыть хранилище) и посмотрите, кто держит объект. Попросите поместить или отменить захват. Если сотрудник уволился или недоступен, администратор хранилища снимает захват в окне хранилища — незавершённые правки этого сотрудника при этом теряются.Никогда не копируйте каталог хранилища, пока к нему подключены пользователи или запущен сервер. Копия может оказаться повреждённой. Останавливайте службу в нерабочее время, копируйте, запускайте снова.
Правила командной работы с хранилищем конфигурации
Само хранилище не спасает от хаоса, если у команды нет договорённостей. Вот что работает на практике:
- Захватывайте узко. Не берите всю ветку «Документы», если правите один документ. Чем меньше захват, тем меньше ждут коллеги.
- Помещайте часто. Законченный кусок задачи — в хранилище в тот же день. Захват дольше пары дней — повод обсудить задачу.
- Перед захватом получайте. Платформа предлагает получить актуальную версию объекта при захвате — не отказывайтесь, иначе поместите правку поверх устаревшего кода.
- Общие модули дробите. Огромный модуль на 10 000 строк станет узким местом. Разделите его по смыслу, чтобы два человека могли работать параллельно.
- Используйте расширения. Доработки типовой конфигурации, которые можно сделать в расширении, не требуют захвата основной конфигурации. Расширение тоже можно подключить к своему хранилищу.
- Метки на релизах. Каждую поставку в рабочую базу помечайте меткой в истории. Тогда собрать прошлую версию — дело одной минуты.
- Отдельная учётка для автоматики. Скрипты и тестовые базы ходят в хранилище под пользователем без права захвата.
- Бэкап хранилища — по расписанию. Каталог хранилища — такой же ценный актив, как рабочая база. Потеря файла означает потерю всей истории.
Если хранилище не подходит
Когда команда выросла, а захваты стали мешать ежедневно, присмотритесь к 1С:EDT с Git. Переход постепенный: конфигурацию выгружают в файлы, ведут ветки и сливают изменения, а хранилище можно оставить для старых проектов. Для одного разработчика хранилище тоже не лишнее — ради истории версий и отката.