Готовишься к экзамену?
Полнофункциональный тренажер @bot_1cnik_bot с полноценным обучением, режимом экзамена и подробной статистикой.
При групповой разработке расширения конфигурации
она должна быть размещена в хранилище с расширяемой конфигурацией
Неправильно: Расширение в 1С - это отдельная конфигурация, и его изменения должны фиксироваться независимо от основной. Если пытаться «держать вместе», смешиваются версии и усложняется сопровождение: обновление основной конфигурации и развитие расширения перестают быть разделяемыми процессами.
она должна быть размещена в отдельном хранилище (но там могут находиться и другие расширения различных расширяемых конфигураций)
Неправильно: Одно хранилище конфигурации предназначено для одной конфигурации (одного проекта), а не для набора разных расширений. Смешивание расширений разных проектов приводит к потере изоляции, конфликтам структуры и невозможности корректно управлять версиями каждого расширения отдельно.
она должна быть размещена в отдельном хранилище (но там могут находиться и другие расширения одной расширяемой конфигураций)
Неправильно: Даже если расширения «для одной базы», они остаются разными конфигурациями и должны версионироваться отдельно. Общее хранилище для нескольких расширений усложняет разграничение прав, выпуск версий и контроль зависимостей, а также повышает риск случайно затронуть не то расширение.
она должна быть размещена в отдельном хранилище
Правильно: Каждое расширение считается отдельной конфигурацией, поэтому для коллективной разработки ему создают собственное хранилище (или отдельный репозиторий в системе контроля версий). Это обеспечивает независимое версионирование, упрощает сопровождение и снижает риск конфликтов с основной конфигурацией.
Пояснение
В 1С расширение - это не «папка с доработками», а самостоятельная конфигурация, которая подключается к основной и переопределяет/дополняет ее объекты. Поэтому в командной разработке правильный подход - хранить расширение отдельно от расширяемой конфигурации.
Как это выглядит на практике:
1) Основная конфигурация (типовая или доработанная) живет в своем проекте/хранилище и обновляется по своим правилам.
2) Расширение живет в отдельном проекте/хранилище: разработчики получают/фиксируют изменения только расширения, не затрагивая напрямую базу.
3) При тестировании или выпуске расширение подключают к базе как файл расширения (или через механизм управления расширениями), проверяют совместимость с текущей версией основной конфигурации и только затем распространяют.
Почему так удобнее:
- Независимые версии: можно выпускать новые версии расширения без «перепривязки» к каждой фиксации основной конфигурации.
- Проще обновлять типовые: обновление основной конфигурации не смешивается с историей изменений расширения.
- Меньше конфликтов: разработчики не блокируют друг друга изменениями в разных расширениях или в базовой конфигурации.
Пример рабочего сценария: у вас есть типовая конфигурация и одно расширение «Интеграции». Основная конфигурация обновляется раз в квартал, а расширение - еженедельно. Если расширение в отдельном хранилище, вы спокойно развиваете интеграции, а при обновлении типовой просто проверяете совместимость и при необходимости дорабатываете расширение, не трогая историю и структуру основной конфигурации.