1С:EDT — новая среда разработки для ведения крупных проектов

Основной средой для разработки в 1С является Конфигуратор. Это удобный и проверенный инструмент, включающий в себя огромное количество возможностей, облегчающих работу программиста. Среди них контекстная подсказка с возможностью настройки шаблонов, конструктор запросов, конструктор форм, режим сравнения и объединения конфигураций, режим замера производительности при отладке и многое другое.

Что такое 1С:EDT?

В 2015 году компания 1С выпустила новую среду разработки — 1С:EDT (Enterprise Development Tools). 1С:EDT содержит большинство возможностей Конфигуратора (не все), и в добавок позволяет использовать единое рабочее пространство для работы с несколькими конфигурациями в рамках единого проекта, вести групповую разработку в Git «из коробки», имеет встроенный веб-сервер для отладки мобильных приложений, предлагает расширенный (по сравнению с Конфигуратором) набор инструментов для разработки и поддерживает разработку и использование технологии плагинов Eclipse.

Первые релизы 1С:EDT были ознакомительными, работать в них было не удобно. По мере выхода новых версий ошибки устранялись, функциональность продукта повышалась. Это позволило применять EDT на практике. Сразу оговоримся, перейти на работу исключительно в EDT и полностью отказаться от использования Конфигуратора у нас не получилось.

Во-первых, мы не можем отказаться от Конфигуратора по причине функциональных ограничений EDT: в нём не поддерживаются изменение обычных форм и изменение правил поддержки и поставки. Так что при доработках старых типовых конфигураций типа «Управление Торговлей 10.3» или «Управление производственным предприятием 1.3» без Конфигуратора не обойтись. При доработках современных продуктов Конфигуратор тоже будет требоваться для включения возможности внесения изменений в объекты типовых конфигураций.

Вторая причина, по которой мы не планируем отказываться от использования Конфигуратора и переходить на работу исключительно в EDT — это повышенные (по сравнению с Конфигуратором) системные требования. Например, рекомендуемые требования к аппаратному обеспечению для такой конфигурации как «1С ERP 2.5» — 16 Гб оперативной памяти, процессор IntelCore i7 (не ниже поколения 3), SSD диск. На самом деле, требования не выглядят «заоблачными» и мы выделяем достаточные ресурсы для комфортной работы в EDT, но только когда разработка ведётся на наших серверах. Если разработка ведётся на сторонних серверах (заказчика, подрядчика), то приходится исходить из тех возможностей, которые готовы предоставить администраторы серверов.

Последняя и самая главная причина, по которой мы продолжаем использовать Конфигуратор, заключается в том, что Конфигуратор в виде компоненты включён в комплект установки основной программы. В момент установки 1С:Предприятия вы по умолчанию получаете возможность запускать программу в режиме конфигуратора.

В случае с 1С:EDT это не так, её придётся устанавливать отдельно. При работе в Конфигураторе вы работаете с конфигурацией, которая привязана к конкретной базе данных. В EDT вы работаете без привязки к конкретной базе данных и должны загрузить конфигурацию в рабочий проект, а по окончанию работы — выгрузить её обратно.

Таким образом, когда речь идёт о выполнении сравнительно небольших работ с базами заказчиков, Конфигуратор остаётся более удобной средой разработки, нежели 1С:EDT.


В каких случаях выгодно использовать 1С:EDT?

Преимущества использования EDT раскрываются при групповой разработке. Групповая разработка без использования EDT ведётся при помощи хранилища конфигурации. Разработчики по мере необходимости захватывают объекты конфигурации из хранилища, вносят в них изменения и возвращают в хранилище. В рамках одного хранилища с одним объектом работает один программист. Обычной является ситуация, когда программист не может приступить к работе с модулем, потому что его коллега успел захватить этот модуль раньше.

При распределении задач, руководителю группы разработки или руководителю проекта должен по возможности не давать конкурирующие задачи в рамках одного хранилища. На практике часто применяют систему из нескольких хранилищ. К моменту очередного релиза конфигурации из этих хранилищ объединяются в финальную версию конфигурации.

Легко представить, сколько проблем может возникнуть при такой организации процесса. Объединение конфигураций с изменениями в одних и тех же объектах приходится проводить в ручном режиме. Изменения в хранилище вносятся последовательно и полноценное тестирование становится доступно только после создания финальной версии релиза.

Если в финальной версии выявляются ошибки, скорее всего, вы не сможете оперативно отказаться от части внесённых изменений, даже если точно знаете, какая часть доработок должна быть отключена. Понадобится сделать патч или пересобрать финальную версию заново.

Участникам групповой разработки необходимо протоколировать историю изменений. Чаще всего история разработки — это сочетание истории объектов хранилища и набора технических заданий на разработку, зафиксированных, например, в Jira.

В идеале, задачи должны быть пронумерованы, а номера задач должны указываться разработчиками при помещении очередных изменений в хранилище конфигурации. На практике бывает по-разному, и участники разработки не всегда корректно протоколируют доработки, особенно это касается проектов с участием нескольких организаций.

Как 1С:EDT упрощает групповую разработку?

Во-первых, появляется возможность одновременного использования одного объекта разными разработчиками. По мере готовности эти ветки объединяются с основной веткой конфигурации. Когда Git не может чисто объединить различные изменения в рамках одного объекта, конфликт разрешаются вручную при помощи редактора сравнения и объединения.

Во-вторых, в EDT удобнее производить тестирование. Как правило, очередной релиз включает в себя новый функционал и исправление выявленных багов предыдущих релизов. Релиз-менеджер должен успеть протестировать все доработки к сроку выпуска релиза. К релизу допускается лишь стабильно работающий функционал, остальные доработки из списка ожидаемых переносятся на следующий релиз.

Как правило, под разработку каждой новой функциональности выделена отдельная ветка. По мере готовности разработчик сообщает о готовности к тестированию, его ветка объединяется со специально выделенной веткой тестирования, в которой накапливаются изменения очередного релиза. Проводится тестирование, по результатам которых, изменения допускаются к релизу или возвращаются на доработку. Объекты конфигурации, используемые в доработке, уже обособлены в рамках ветки соответствующей функциональности.

Благодаря этому релиз-менеджер избавлен от необходимости выборочного получения объектов, как это происходит при работе с хранилищами, в котором ведётся параллельная разработка нескольких фич. Мы просто собираем релиз как конструктор, где в роли деталей выступают ветки с работоспособным стабильным кодом.

В-третьих, EDT предоставляет гораздо более подробную историю изменений. История изменений доступна непосредственно в тексте программного кода. Вы выделяете интересующий фрагмент и получаете не только список всех коммитов, в которых этот фрагмент редактировался, но и возможность сравнения текстов модуля по каждому из них. Причём доступ к данным истории изменений очень быстрый, гораздо быстрее, чем при обращении к истории объектов хранилища.

Подводя итоги

1С:EDT — это полноценная среда разработки, более сложная и требовательная к ресурсам, чем привычный конфигуратор. В добавок, программисту понадобится время на освоение работы в EDT. Но эти вложения окупаются при групповой разработке крупных проектов.





Читайте также:

Управленческий учет — это определенная система сбора, хранения, структурирования и интерпретации информации, которая помогает менеджменту компании проводить анализ деятельности и принимать управленческие решения.

Остались вопросы?

ФИО*
E-mail*
Телефон*
Введите ваш вопрос
Наверх