Стоит ли переходить на 1C:EDT: опыт внедрения, преимущества для CI/CD и сравнение с Конфигуратором

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием IT и автоматизация бизнеса
← На главную

Переход на новую среду разработки — это всегда серьезный шаг, требующий анализа затрат и потенциальной выгоды. Рассмотрим подробнее, что представляет собой 1C:Enterprise Development Tools (EDT), и выясним, в каких случаях его внедрение действительно оправдано, а когда лучше остаться на классическом Конфигураторе.

Основные цели перехода и анализ инструментов

Разберем типичные цели, которые ставят перед собой команды при переходе на EDT:

  1. Ведение параллельной разработки в нескольких ветках Git. Это критично для крупных проектов, где одновременно реализуются десятки независимых задач. Понимание того, какие ветки нужны и как выстроить процесс, дают приемы быстрой работы в EDT/Git.
  2. Хранение внешних обработок и отчетов в Git. Позволяет версионировать вспомогательные инструменты так же, как и основную конфигурацию.
  3. Автоматизация тестирования и CI/CD. Это позволяет упростить себе жизнь при внедрении CI/CD для 1С, создавая конвейер непрерывной интеграции для автоматической сборки и проверки кода.

Проанализируем ситуацию: если ваша команда состоит из 1–3 человек, работающих над небольшими правками, связки Конфигуратор + GitSync может быть вполне достаточно. В таком случае для контроля качества можно использовать статический анализатор кода проектов на чистом 1С. Однако для сложных систем, таких как 1С:ERP или 1С:ERP. Управление холдингом, возможности EDT становятся более актуальными.

Преимущества 1C:EDT перед Конфигуратором

Рассмотрим по шагам, какие функциональные возможности предоставляет EDT для профессиональной разработки:

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

2. Глубокий рефакторинг. Инструменты EDT позволяют безопасно переименовывать методы, переменные и объекты метаданных. Система автоматически находит и исправляет все ссылки по всему проекту. В Конфигураторе аналогичная операция зачастую требует ручного поиска и чревата ошибками.

3. Интеллектуальная проверка кода. Среда выполняет статический анализ «на лету», подсвечивая неиспользуемые переменные, потенциальные ошибки обращения к объектам и нарушения стандартов разработки. Для более детального аудита полезно проводить регулярный анализ конфигураций, расширений, отчетов и обработок на наличие ошибок, что значительно сокращает время на отладку.

4. Использование ИИ-помощников. Современные версии поддерживают 1С:Напарник — встроенный ИИ-ассистент, который помогает генерировать код по описанию и объясняет работу существующих процедур. Посмотрим на пример того, как ИИ может помочь в написании стандартного обхода выборки:


// Пример генерации кода ассистентом
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
    // Логика обработки каждой позиции
    Сообщить(Выборка.Наименование);
КонецЦикла;

Методология работы: Хранилище vs Git

Разберем по шагам, как меняется процесс разработки при переходе от Хранилища 1С к связке EDT + Git. В традиционной схеме с Хранилищем часто возникает проблема «захвата объектов», когда один разработчик блокирует общий модуль на длительное время. В EDT применяется Feature-branch workflow:

  1. Разработчик создает отдельную ветку в Git под конкретную задачу.
  2. Вносит изменения локально, не затрагивая других.
  3. После завершения работы и успешного прохождения тестов выполняется Merge Request (запрос на слияние) в основную ветку.
  4. Техлид проводит Code Review непосредственно в интерфейсе Git-сервера (например, GitLab или Bitbucket), что невозможно при использовании только Хранилища.

Технические требования и производительность

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

Проанализируем ситуацию с запуском отладки: при первом запуске EDT может потребоваться 2–3 минуты на полную сборку информационной базы из файлов. Однако последующие инкрементальные обновления происходят значительно быстрее (до 30 секунд), так как система переносит только измененные модули.

Практический пример организации процесса в крупной команде

Посмотрим на реальный кейс успешного использования EDT в команде из 15 человек на проекте БитФинанс:

Код, документация и автотесты хранятся в одном репозитории. На каждую фичу создается отдельная ветка. Дважды в неделю готовые задачи вливаются в релизную ветку. Перед вливанием в master (основную рабочую ветку) автоматически запускается конвейер сборки:


# Пример упрощенного скрипта сборки в CI/CD
1. Экспорт конфигурации из исходников в .cf
2. Загрузка в тестовую базу
3. Запуск дымовых тестов (Vanessa Automation)
4. Проверка кода через SonarQube

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

Работа с расширениями и внешними объектами

Важно отметить, что работа с расширениями в последних версиях EDT (2023.x, 2024.x) стала значительно стабильнее. Среда корректно отслеживает связи между объектами основной конфигурации и расширения, позволяя использовать рефакторинг и для них. Внешние отчеты и обработки также хранятся в проекте как отдельные папки с файлами, что позволяет видеть историю изменений каждой строки кода в Git.

Заключение

Подведем итог: переход на 1C:EDT оправдан, если вы стремитесь к современным стандартам разработки, используете CI/CD, Code Review и сложную систему ветвления. Если же ваша разработка носит линейный характер и ресурсы компьютеров ограничены, стоит рассмотреть промежуточный вариант — использование GitSync для выгрузки изменений из Хранилища в Git для истории, продолжая кодить в привычном Конфигураторе.

← На главную