Вышла версия 0.4.0. Что нового:
- Добавлена поддержка EDT 2025.2 (ранние версии EDT не поддерживаются)
- Исправлены мелкие ошибки
Вышла версия 0.3.0. Что нового:
- Добавлена поддержка когда конфигурация и ее расширения в одном репозитории (ранее только в разных репозиториях).
- Настройки плагина теперь хранятся в разрезе "Проект" (ранее было "ИБ + Проект")
- Команда вызова формы настроек перемещена в контекстное меню Проекта на панели "Разработка" (ранее располагалась в контекстном меню Задачи). Описание панели "Разработка" см. https://its.1c.ru/db/edtdoc#content:10229:hdoc
- Команда вызова формы настроек добавлена в контекстное меню Проекта на панели "Навигатор"
Вышла версия 0.2.0. Что нового:
- Добавлена поддержка расширений конфигураций
- Исправлена ошибка помещения дополнительных индексов из EDT в ИБ
- Устранены мелкие недочеты и немного ускорена операция помещения
- Настройки плагина теперь хранятся в разрезе "ИБ + Проект" (ранее было "ИБ")
- Добавлена новая настройка "Помещать даже если конфигурации различаются"
Скачать новую версию можно с https://github.com/ZigRinat85/PluginEDT. Ссылка находится в разделе README
Для кого будет полезно
-
1С-программистам, предпочитающим вести разработку конфигураций в EDT
Многие проекты по внедрению и разработке решений на платформе 1С ведутся с использованием хранилища конфигурации. На таких проектах есть возможность работать в EDT - с помощью 1С:ГитКонвертер. Описание схемы работы можно найти на сайте ИТС. Однако такая схема требует принятия решения "сверху" и формирования определенной инфраструктуры на проекте. И если руководство проекта приняло решение не использовать схему с 1С:ГитКонвертер, то у разработчика не остается выбора, кроме как вести разработку в Конфигураторе.
Плагин представленный в этой публикации дает возможность для принятия решения "снизу", то есть разработчик из проектной команды сам волен принимать решение где ему вести разработку: в Конфигураторе или в EDT. Данный плагин расширяет функциональность EDT и позволяет выполнять операции по захвату объектов в хранилище конфигурации и загрузке своих модификаций в Основную конфигурацию Информационной базы (далее ИБ), подключенной к хранилищу.
-
разработчикам собственных плагинов для EDT
Исходный код данного плагина является открытым. Использованные публичные сервисы, интерфейсы, классы, методы и расширения для кого-то могут оказаться полезным при разработке собственного функционала в EDT. На мой взгляд с учетом специфичности данных плагинов есть не так много документации и примеров реализации, которые можно использовать в качестве учебного пособия для начинающего разработчика плагинов
Концепция решения
Термины и сокращения
База хранилища (БХ) – информационная база, подключенная к Хранилищу конфигурации 1С. База хранилища привязана к Ветке хранилища. Рекомендуется файловая ИБ без данных.
В БХ разрешены следующие операции:
- получение изменений из подключенного Хранилища конфигурации 1С
- сравнение Основной конфигурации с Конфигурацией базы данных с целью проверки корректности загрузки из Ветки разработки с помощью данного плагина
- помещение изменений, загруженных из Ветки разработки с помощью данного плагина, в подключенное Хранилище конфигурации 1С
Ветка хранилища (ВХ) – ветка git’а в EDT, коммиты которой отображают состояния Базы хранилища. Одна Ветка хранилища соответствует одному Хранилищу конфигурации 1С. Как правило она в единственном экземпляре. Имя ветки можно давать любое.
В ВХ разрешены следующие операции:
- импортирование изменений Базы хранилища, полученных из Хранилища конфигурации, в EDT в Ветку хранилища
- слияние из Ветки разработки изменений после загрузки и помещения модификации Ветки разработки в Хранилище конфигурации
Ветка разработки (ВР) – ветка git’а в EDT, коммиты которой отображают разработку по некоторой новой модификации конфигурации, которую осуществляет разработчик в рамках поставленной ему задачи. Одна Ветка разработки соответствует одной задаче на модификацию конфигурации. Веток разработки может быть несколько, например для параллельной разработки нескольких задач. Имя ветки можно давать любое.
В ВР разрешены следующие операции:
- разработка в EDT модификации в рамках поставленной задачи
- слияние из Ветки хранилища изменений, полученных из Хранилища конфигурации
- загрузка модификации в рамках поставленной задачи в Базу хранилища, с помощью данного плагина
База разработки (БР) – информационная база для разработки новой модификации. База разработки привязана к Ветке разработки.
В БР разрешены следующие операции:
- тестирование и отладка модификаций в рамках Ветки разработки
Схема работы
Модель ветвления:
Общее описание процесса работы
- Заходим в БХ в режиме конфигуратора и получаем все или необходимые изменения из Хранилища конфигурации. Применяем изменения в Конфигурацию базы данных, чтобы конфигурации были идентичные. Закрываем конфигуратор.
- Импортируем полученные в п.1 изменения в проект EDT. Важно при этом убедиться, что извлечена ВХ. Фиксируем полученные изменения в коммите ВХ.
- Создаем новую ВР из ВХ для новой модификации. Извлекаем ВР. Создаем новую БР и привязываем ее к новой ВР.
- Ведем разработку модификации по задаче. И обязательно фиксируем все изменения в коммитах ВР. Можно создавать несколько коммитов.
- Перед тем как загрузить изменения из п.4 в БХ, установим настройки. Для этого в панели Навигатор встанем на элемент проекта и в контекстном меню вызовем «Хранилище конфигурации-Настройки».
Если есть проекты расширений конфигурации, то вызвать форму настроек можно также и в панели Разработка: встанем на элемент проекта и в контекстном меню вызовем «Хранилище конфигурации-Настройки».
Указываем параметры подключения к Хранилищу конфигурации как обычно это делаем в Конфигураторе. Настройки сохранятся в разрезе Проекта и повторно их вводить не потребуется.
5.1 Настройка «При изменении .mdo всегда захватывать подчиненные формы/шаблоны» управляет стратегией захвата объектов в хранилище. Дело в том, что в модели конфигурации EDT и модели захвата объектов Хранилища есть различия. Это касается изменений полей «Синоним» и «Комментарий» у форм/шаблонов. В модели ЕДТ эти данные хранятся в файлах .mdo, что соответствует родителю формы/шаблона. В модели Хранилища конфигурации, чтобы поместить эти изменения нужно захватить и поместить именно форму/шаблон. Однако по файлу .mdo сложно отследить какие именно формы/шаблоны были изменены, а может и не было таких изменений. Плагин выполняет захват форм/шаблонов только в том случае, если были изменены файлы форм/шаблонов в модели ЕДТ. Но если в ВР не зафиксировано таких изменений, а изменены только «Синоним» или «Комментарий», то в таком случае есть два подхода. Первый – не ставить галочку данной настройки и перенести данные изменения в хранилище конфигурации вручную. Второй – установить галочку данной настройки, в таком случае при любом изменении файла .mdo будет производиться попытка захвата всех подчиненных форм и шаблонов. На мой взгляд первый подход лучше, потому что изменения полей «Синоним» и «Комментарий» без изменений самих форм/шаблонов – редкое явление. Зато при попытке захвата всех подчиненных форм/шаблонов разработчик часто будет сталкиваться с ситуацией, что какие-то из них будут захвачены другим разработчиком.
5.2 Настройка «Помещать даже если конфигурации различаются» разрешает или блокирует помещение на этапе 6.3 если Основная конфигурация и Конфигурация базы данных различаются - Загрузим изменения из п.4 в БХ. Для этого в панели Разработка встанем на элемент разработки БХ и в контекстном меню вызовем «Хранилище конфигурации-Поместить в хранилище». Важно при этом убедиться, что извлечена именно ВР.
Плагин загружает изменения по следующему алгоритму:
6.1 Производится анализ различий ВР и ВХ, определяется список измененных файлов в модели EDT. Незафиксированные в коммит изменения не будут учитываться при определении этого списка.
6.2 По полученному списку файлов определяется список объектов модели Хранилища для захвата в Хранилище конфигурации в БХ. Происходит попытка захвата требуемых объектов, с учетом настройки из п.5.1
6.3 Во время захвата объекты, которые были изменены другими разработчиками, будут получены в БХ и возникнет отличие Основной конфигурации и Конфигурации базы данных. Чтобы не затереть изменения других разработчиков, с помощью выданного плагином диалога необходимо прервать загрузку файлов в БХ, извлечь ВХ, выполнить п.2, извлечь ВР, выполнить слияние с ВХ при необходимости разрешив конфликты, зайти в конфигуратор БХ, применить Основную конфигурацию в Конфигурацию БД. После этого вновь повторить п.6
6.4 Происходит загрузка измененных объектов в БХ
6.5 Происходит обновление файла ConfigDumpInfo.xml для ВХ, который хранится в рабочей области проекта EDT. Типовая команда «Импортировать конфигурацию…» в EDT использует этот файл для определения измененных объектов, которые требуется импортировать в EDT из ИБ(см. ИТС DumpConfigToFiles -configDumpInfoForChanges). В текущем пункте файл обновляется, чтобы в будущем при выполнении п.2 избежать избыточного импорта загруженных объектов из п.6.4, т.к. они уже есть в проекте. - Выполним проверку загруженных объектов. Для этого откроем БХ в Конфигураторе, выполним сравнение Основной конфигурации с Конфигурацией БД
- Если все в порядке, то применяем Основную конфигурацию в Конфигурацию БД и выполняем помещение в Хранилище конфигурации. Закрываем конфигуратор.
- Извлекаем ВХ и выполняем слияние с ВР.
На первый взгляд может показаться, что схема сложная, но выполнив пару раз становится ясно и логично. Тем более основное время разработчик занимается разработкой модификации и лишь время от времени помещает в хранилище.
Инструкция по установке плагина
- Скачать плагин c https://github.com/ZigRinat85/PluginEDT. Ссылка находится в разделе README
- В EDT выбрать пункт меню "Справка-Установить новое ПО"
- Снять галочку "Группировать элементы по категориям" и нажать кнопку "Добавить". В открывшемся диалоге нажать кнопку "Архив..." и выбрать файл плагина. В поле "Имя" укажите любое имя для данного плагина
- После этого в списке появится плагин, его нужно выбрать и нажать "Далее", подтверждаем все запросы и нажимаем "Готово"
Ограничения
- Данный плагин поддерживает работу и с конфигурацией и с расширениями.
- Тестирование плагина проводилось в ОС Windows 11. Работа в других операционных системах не проверялась, хотя теоретически возможна.
- Поддерживаются EDT 2024.2, EDT 2025.1, EDT 2025.2
- Плагин распространяется по принципу "как есть" ("as is"). Пользователь несет полную ответственность за использование данного плагина.
- В случае если расширение находится в отдельном от конфигурации репозитории, то в типовом функционале EDT при работе с расширениями конфигурации, чтобы выполнить импорт изменений из хранилища именно для расширения нужно извлечь как Ветку Хранилища Расширения так и Ветку Хранилища Конфигурации
- В случае если расширение находится в отдельном от конфигурации репозитории, то в типовом функционале EDT чтобы ветка была связана с ИБ, нужно обязательно ветку создать через панель Разработка и там ей явно указать ИБ. Поэтому при создании репозитория расширения первая ветка создастся без связки с ИБ. Она не нужна, даем ей фиктивное имя, потом на ее основании создаем через панель Разработка Ветку Хранилища и Ветку Разработки. В общем виде панель Разработка будет выглядеть так(если есть хранилище как в конфигурации так и в расширении, проекты конфигурации и расширения находятся в отдельных репозиториях)
Послесловие
Это мой первый опыт в создании плагина для EDT. При разработке я опирался на официальные обучающие ресурсы https://edt.1c.ru/dev/ru/.
Отдельное спасибо хочется сказать Дмитрию Мармышеву за цикл статей //infostart.ru/1c/articles/1311121/, в которых максимально подробно по шагам расписан процесс разработки плагинов. Мне кажется, без этих статей я бы не смог написать свой первый плагин, потому что документация на официальном ресурсе хоть бесспорно тоже имеет большую ценность, однако рассчитана на тех, у кого есть опыт в разработке в Eclipse. Всем, кто решил написать свой первый плагин, рекомендую начать с того, чтоб повторить по шагам все, что в этих статьях.
Вступайте в нашу телеграмм-группу Инфостарт
