При ведении крупных проектов на базе типовых решений, таких как 1С:ERP Управление предприятием, возникает задача доработки конфигурации силами команды программистов без снятия типовой конфигурации с поддержки. Доработки форм, модулей объектов и добавление нового функционала переносятся в расширения конфигурации. Однако при участии нескольких специалистов встает вопрос синхронизации изменений и предотвращения конфликтов редактирования метаданных. Разберем основные подходы к организации совместной разработки расширений.
Использование штатного хранилища конфигурации для расширений
Начиная с платформы 8.3.12, платформа 1С:Предприятие поддерживает отдельное хранилище конфигурации для каждого расширения. Это позволяет организовать привычный процесс коллективной разработки с захватом объектов.
Рассмотрим ключевые особенности работы со штатным хранилищем расширений:
Независимость от основной конфигурации: хранилище расширения создается автономно. Основная конфигурация базы при этом может оставаться на полной поддержке поставщика или быть подключена к собственному отдельному хранилищу.
Подключение к хранилищу: подключение выполняется через список расширений конфигурации. В контекстном меню конкретного расширения доступно стандартное подменю работы с хранилищем конфигурации.
Захват и помещение объектов: разработчики работают по классической схеме — захватывают заимствованные объекты, формы или модули расширения, вносят изменения и помещают их обратно в хранилище расширения.
Организация совместной разработки через Git и выгрузку в исходные тексты
Если в команде принят рабочий процесс на базе систем контроля версий (VCS), эффективным решением становится использование Git. Платформа 1С предоставляет механизмы пакетной выгрузки и загрузки структуры расширения в набор текстовых и XML-файлов исходных кодов.
Проанализируем шаги настройки конвейера работы через командную строку платформы:
Выгрузка расширения в файлы: для помещения изменений расширения в локальный репозиторий Git выполняется пакетная выгрузка с ключом -Extension:
Фиксация изменений и слияние веток: разработчики работают в отдельных ветках Git, используя стандартные механизмы ветвления, код-ревью и слияния. Для полноценной разработки в формате исходных кодов также применяется среда 1C:Enterprise Development Tools (1C:EDT).
Загрузка расширения из файлов в базу: после слияния изменений в ветку сборки выполняется загрузка файлов обратно в информационную базу:
Архитектурное разделение доработок на несколько расширений
При параллельной работе над разными функциональными блоками (например, блок производства, складская логистика, интеграции) попытка вести всю разработку в одном общем расширении приводит к блокировкам объектов в хранилище или частым конфликтам слияния. Выясним правила грамотной декомпозиции проекта:
Разделение по назначению и областям: платформа поддерживает назначение расширений (Исправление, Адаптация, Дополнение). Разделяйте проект на функциональные подсистемы, выделяя под каждую задачу отдельное расширение.
Управление зависимостями: платформа позволяет настраивать список зависимостей одного расширения от другого. Это дает возможность создать базовое расширение с общей нормативно-справочной информацией и прикладные расширения с конкретной логикой.
Применение префиксов: для исключения пересечения имен метаданных обязательно задавайте уникальные префиксы для процедур, функций, общих модулей и реквизитов каждого расширения (например, ПРБ_, СКЛ_).
Корректное использование аннотаций: при переопределении одного и того же типового метода в разных расширениях аннотациями &Перед, &После, &Вместо важно учитывать порядок их применения и обязательно вызывать ПродолжитьВызов() во &Вместо, чтобы не прерывать цепочку вызовов других модулей.
Риски и ограничения при работе с расширениями данных
Рассмотрим важные технические нюансы, которые необходимо учитывать при командной разработке расширений:
Сохранность данных: если расширение содержит собственные таблицы или реквизиты, отключение или удаление расширения из рабочей базы приводит к безвозвратному удалению созданных им физических таблиц в СУБД. Релизы и обновления структуры данных требуют строгого регламента резервного копирования.
Контроль совместимости при обновлении конфигурации: при обновлении типовой конфигурации поставщика структура заимствованных объектов может измениться, из-за чего расширение перестанет применяться. В процесс коллективной разработки необходимо включать этап автоматизированной проверки применимости расширений на тестовой базе перед выпуском релиза в рабочую среду.