Добрый день, господа.
Сегодня в нашем коллективе зашла речь про переход на новую среду разработки — 1C:EDT.
Текущие цели: вести несколько веток для гита; в гите хранить внешние обработки и отчеты; автоматизировать тестирование.
До сего момента у нас уже есть связь с git посредством GitSync.

Поделитесь опытом перехода на EDT, если он был.

Кстати, знаете, сколько лет 1С:Enterprise Development Tools?
10 лет! Просто удивительно! Вроде вот только вышла...

Заодно решил прикрутить голосовалку, чтобы иметь представление о текущем положении дел по этому вопросу.

Спасибо за внимание.

Вообще то уже 12 лет ЕДТ. Покорми оленей

Сама фирма "1С" ведёт разработку в EDT с 2018 года
https://infostart.ru/1c/articles/2299156/

Среда разработки 1С(Enterprise Development Tools) была выпущена компанией 1С в 2015 году.

https://www.gigansk.ru/blog/1s-edt-novaya-sreda-razrabotki-dlya-vedeniya-krupnykh-proektov/

Неудачный эксперимент от 1с.

EDT это сферический конь в вакууме. Если не указаны параметры как объем задач, количество разработчиков, и т.п. применение или неприменение этой среды ни о чем не скажет.
Одно дело, когда команда из 15 человек поддерживает вусмерть переписанную ЕРП, в которой ведется учет всего на свете (от курса акций до обеспеченности туалетными ершиками всех сортиров мегакорпорации). А другое дело, когда пара студентов лепят для типовых БП внешние печатные формы для Приходных накладных.

>>в гите хранить внешние обработки и отчеты
зачем для этого EDT? выгрузку обработки из базы, индексацию изменений, коммит и пуш можно делать и без него
добавьте пункт "используем гит, не используем EDT"

(6) Если говорить про нас, то сейчас разработчика непосредственно 1С - трое и небольшое количество подрядных организаций.
Основная конфигурация 1С:ЕРПУХ. Производство.

(8) Да. Вы правы. Надо было такой пункт сделать. Но отредактировать нет возможности.

(8) (10) Я добавил

Можно было бы ещё и про хранилище пункт.

(12) гноилище... Добавил

(0) >> цели: вести несколько веток для гита; в гите хранить внешние обработки и отчеты; автоматизировать тестирование.
(9) >> сейчас разработrа 1С - трое и небольшое количество подрядных организаций.

Тема "зачем для этого EDT?" остаётся нераскрытой.
Как именно (по ожиданиям) EDT поможет вам достичь поставленных целей?
Чего такого нет в конфигураторе, но есть в EDT, что принципиально и кардинально повысит вашу производительность труда? А может даже решит что-то, что не нерешаемо иначе, кроме как с EDT?

(0) для поддержки типовых с учётом низкой квалификации имеющихся разработчиков избыточна
конфигуратор + хранилище
продуктивные террабайтные базы, сильно кастомизированное ERP

(14) У менеджеров есть видение концепции CI/CD.
EDT единственный канонический инструмент от разработчиков, который входит в эту концепцию.

(15) 👍
>> для поддержки типовых ... избыточна
>> конфигуратор + хранилище

(16) >> У менеджеров есть видение...

Как (в Вашем понимании) видение менеджеров связано с производительностью труда разработчиков?
Как (чем) удовлетворение "хотелок" менеджеров поможет разработчикам?

(16) >> есть видение концепции CI/CD

Как это видение противоречит 1С-овскому хранилищу конфигурации? Типа "немодно"?

Я конечно душнила редкостный. Но не обижайтесь. Я действительно хочу понять - а нафига оно вам надо? На конкретных примерах. Типа было "вот так" и мы страдали, а станет "вот этак" и к нам придёт счастье.
Обожаю жанр "было-стало".

(16) раз нужно - переходи, ни каких катастроф не будет, разработчики привыкнут за пару месяцев

(0) Если у тебя одновременно реализуется в конфигураторе 10 разных задач, и при этом они в коде пересекаются, то собрать релиз в который должна попасть только одна задача из этих 10 становиться очень трудоёмко. Особенно если это делает не тот разработчик, который эту задачу реализовал. EDT перекладывает сборку релиза на программиста, он не видит чужие задачи, он всегда работает только с копией конфигурации, которая сейчас находится в продуктиве. Правда могут быть конфликты когда в релиз входит 2-е задачи, и их код пересекается, и еще противоречит друг-другу, то тут придется одному из двух программистов разбираться с этим конфликтом и копировать код второй задачи к себе.
Это нечастые ситуации, но самые неприятные, именно это увеличивает трудоемкость задач. У меня один раз была доработка, по которой был создан запрос на вытягивание (т.е. все готово и оно ждет, когда перенесут в релиз), но его почему-то долго не вливали в релиз, что-то тестировали и согласовывали. За это время много раз менялся модуль в котором были мои доработки, из-за этого мой код становился неактуальным, мне приходилось его постоянно актуализировать. Это не просто кнопка "получить из хранилища", это надо разобраться в чужом коде, чтобы его не поломать и объединить со своим. А потом опять кто-то изменить этот код в релизе и все по новой.
Но не все так страшно, плюсов для больших компаний наверное больше:
1. Сборки релизов проще, если из 100 задач которые сейчас находятся в разработке надо включить в релиз только задачи №1,№5,№7, то сборку система сделает автоматом (если конечно нет конфликтов)
2. Код-ревью проще делать
3. Проще отслеживать изменения, например для безопасников, если надо контролировать ролевую модель.
4. Всякие автоматизации (код-ревью, автоматические проверки, авто сборки релизов и прочие возможности)

Если по теме из (0), то для целей "в гите хранить внешние обработки и отчеты" не вижу смысла усложнять себе жизнь EDT. Если поток задач небольшой, то в конфигураторе со всеми его недостатками наверное разработка будет идти быстрее.

Так, балуемся с EDT понемножку. Для ознакомления.

(19) 20-30 задач поместили в хранилище, потом в ходе тестирования внесли по 2-3 правки по каждой задаче, поместили в хранилище.
Потом говорят перенесите рандомные 3 задачи в прод. Если отчеты или обработки - то ок, а если общие модули пересекаются в задачах - можно что-то пропустить.

мне попалась задача на распределении с хранилищем
и я понял, что я уже не помню с чем его едят )))

Уважаемый Станислав убери пункт "Не используем GIT".
Он тут явно лишний.
Спасибо.

(8) > выгрузку обработки из базы, индексацию изменений, коммит и пуш можно делать и без него
- где почитать?

(11) спасибо. у нас в гите код-ревью конфа и доп обработки. и сброчная линия в гитлабе. есть предпрод база которая пытается обновиться до рабочей, если там упало, рабочая не обновляется. тестов нет(но надо), пока хватает.
(16) а менеджеры понимают что нужен на постоянку девопс следить на всем этим хозяйством?

За внешние обработки и отчеты и двор - стреляем в упор.

Нет лучшего способа внести хаос - чем загадить базу внешними отчетами и обработками.

Контора маленькая, упр.база живет в облаке. Даже программиста по минимуму используют, а вы тут про едт всякие...

(0) А статистику потом 1С продашь?

(29) Поделитесь опытом. Что используете?
ГитСинк?

(25) >> 20-30 задач поместили в хранилище, потом в ходе тестирования внесли по 2-3 правки по каждой задаче, поместили в хранилище.

Эмммм.... Но 1С говорит нам, что жить с хранилищем следует не так.
В концепции 1С, ситуации, когда в хранилище прода попало 20-30 не протестированных задач, невозможна. В хранилище прода доработки попадают только после завершения тестирования.
До завершения тестирования у каждой задачи своё отдельное хранилище, жизненный цикл которого от начала разработки по задаче (в этот момент оно идентично проду) до окончательного переноса в продуктив всех изменений по этой задаче (включая исправлений ошибок, выявленных при тестировании).

>> говорят перенесите рандомные 3 задачи в прод. ... если общие модули пересекаются в задачах - можно что-то пропустить.

Если разработка ведётся всё таки в едином хранилище, то модули пересекаться не должны (объект захватывается в хранилище только кем-то одним и в идеале не должен помещаться в хранилище до окончания разработки).
Если разработка ведётся по методике 1С, то каждая задача живёт в отдельном хранилище и процесс "перенесите рандомные 3 задачи в прод" не является одномоментным, а всё таки последователен - сначала первая задача, потом - вторая, после - третья. В таком случае действительно специалисту, делающему окончательную сборку релиза, придётся включать голову и быть предельно внимательным. Но и в EDT с Git это нетривиальная задача. Полный автомат может и накосячить.
Хотя сама постановка вопроса "перенесите рандомные 3 задачи в прод" выглядит, как какой-то бардак.

EDT не щупал. слышал что тормозное и монструозное поделие.
GIT вроде хорошо и удобно.

(35) тормозит у меня только, когда запущено две версии 2024 и 2023, явы разные, памяти кушают много
в остальном - все норм
единственно вспомнил - в версии 2023 роли не всегда корректно отображали объекты и при создании новых макетов ходил в конфигуратор, вот две проблемы
в остальном нравится

(33) используем примерно треть от https://infostart.ru/1c/articles/1881435/  , мы не такие крутые как озон)

(34) Могу только пожелать удачи разработчикам на "1С:ЕРПУХ" с таким подходом, это сколько места надо в СХД и времени при подготовке хранилища под новую задачу.
И я имел в виду 20-30 задач в хранилище разработки\тестирования. И чем такой подход 1С отличается от обычных веток GIT, которые не требуют создавать полный слепок первоначальной конфигурации?

"Полный автомат может и накосячить."
Согласен, там тоже будут матюки при слиянии веток.

используем Git )))))))))

(37) сколько занимает времени запуск клиента 1с для отладки, после сохранения доработок? там же вроде пересобирать конфигурацию из файлов надо было

Используем хранилище, но скоро будет Git через GitSync, теоретически можно будет пробовать работать и в EDT, кто как захочет.

Тут конфа.

Используем SVN. Поскольку такого варианта нет, то ставлю GIT.
Используем для расширений, внешних отчетов, обработок.

(44) "Используем SVN" - а кодите в емаксе?

(45) Давно это было. Как сломается, перейдем на GIT.

(41) зависит от степени доработок, приложение обычно одно делаю на все ветки, первый запуск может минуты 1,5-3,  потом какие то секунды(до 30)

(27) Убрал

Хранилище

ЕДТ это для серьёзных пацанов которые кодят серьезные вещи

(50) *Можно пару примеров серьезных вещей*?
А то я всё хочу чем-то серьезным заняться, но всё достается ерунда какая-то в основном...
Интересно, как другим так везет.

(51) 1С:ERP-УХ подойдёт? см. (2)

Спасибо, почитал, хорошая статья.

Когда-то было так (аж впятером одновременно что-то мостырили), а теперь уже и этого много.

Для коллективной разработки - используем хранилищ

Пока так.

Проголосую

Для нас наиболее оптимальным вариантом стало хранилище - git-sycn-> gitlab-jenkins.

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

edt - идея хорошая, реализация плохая.

В процессе дискуссий наша команда пришла к выводу развивать текущее решение с GitSync-ом.
Переход на EDT отложили на дальнюю перспективу.

И результаты голосования были ожидаемы.
Всем спасибо.

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

Вон в Go взяли и прикрутили к VS Code плагин, все работает нормально, уже 4й год сижу в нем.
В 1С слишком сложно реализовать в виде плагина? Надо весь тулчейн переписывать?
Очень странная логика, взять тяжеловесное нечто и сделать это нечто проводником к cli конфигуратора.

(61) EDT это же десяток модулей для Eclipse(Java).
Загрузка и выгрузка через конфигуратор или его коммандный режим.

Почему нет голосовалки -
Нет ничего проще, чем перейти на EDT, сам пробовал уже 125 раз!

(63) Расскажите про "Глючево EDT"

(63) круто! дадите подробности: продуктовая или внутренняя разработка? сколько разработчиков в команде? используется ли СППР? кто мерджит ветки?
просто есть ощущение что EDT для больших или очень продвинутых команд

(62) в том то и дело, еще и на джаве. ну такое...
когда работал 1Сником, пытался в EDT, но так и не понял зачем.
в конфигураторе все то же самое и быстрее работает.

EDT мертворожденное ~говнище~ дитя фирмы 1С. Столько бабла и часов влито, а без конфигуратора 1С не работает.
Нигде не использую.
У разных клиентов по разному где то хран, где то GIT под задачи.

Нафиг оно мне, одному?)
ТурбоКонф рулит)

37% + 4% достаточно показательно

(67) Да нормальный процесс, когда корпорация берет бесплатный opensource и доделывает его под свои нужды...

Проблема же не в EDT, а в том что 1С пропустила точку когда произошло монополизация софта контроля версии и все стало Git (начало лет 8-9 назад) и продолжало упорно толкать свое хранилище.
А переход к git(основан на изменениях файлов) и спровоцировал переход от бинарного работы в конфигурации к разложению по файлам(модуль формы и т.д. - Выгрузить конфигурацию в файлы)

И да ломка от философии потребления (1С нам все должна) она такая...

У нас 1С ERP, EDT здесь не живет ;)

(71) Ну, в результате стало же видно, что схема получилась малопригодная...

(70) >> достаточно показательно

Показательно?... Возможно.
Вопрос как эту показательность интерпретировать.

Особенность EDT в том, что он изначально не позиционировался (и сейчас не позиционируется) как замена или альтернатива конфигуратору. Типа как что-то такое к чему надо стремиться.

Те потенциальные преимущества, которые он может дать, изначально нафиг не нужны в огромном количестве случаев. А те недостатки и проблемы, которые он привносит, значительно усложняют процесс. Нелепо и бессмысленно разворачивать у заказчика EDT ради написания раз в год по одному отчёту и рисования печатных форм.

Короче. К чему это я...
EDT имеет весьма специфическую и ограниченную сферу применения, где его использование будет осмысленным, оправданным и даёт команде разработчиков какие-то конкретные преимущества.

Скольким разработчикам из числа тех, кто проголосовал "Не используем EDT", он даже в теории нафиг не нужен?

Гораздо интереснее мнение тех, кому EDT мог бы  быть полезен, но они почему-то не переходят на него. А так же тех, кто пользовался EDT, но потом почему-то отказались.

Но оч хочу в EDT уйти.
Как временно вернувшийся с джавы не представляю себе жизнь без полноценных ide и гита.
и да. дико убивают кучи комментов "здесь говнокодил вася" в коде. метки гита куда приятнее.

(75) легче обратно в джаву, чем на EDT пересесть.
в Java есть Idea Community Edition + git вместо хранилища конфигураций + github вместо инфостарта.
и все бесплатно, еще и ЗП выше и требований меньше.
я бы даже не задумывался.

[10 лет! Просто удивительно! Вроде вот только вышла...]

Проверено временем!)

(75) EDT заметно прожорливее родительского Eclipse

Так я не понял, надо EDT ставить или нет?

(79) >> ...надо EDT ставить или нет?

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

(78) Естессна ))) Эклипс - всего лишь платформа. Любая ИДЕ на его базе - набор плагинов, а они-то и есть основные пожиратели ресурсов.

(76) таки и планирую назад вернуться. временный камбэк в 1С - не более, чем "для поддержания штанов" на время поднятия уровня инглиша. И да. На комьюнити и работал, бэкендеру это монструозное неповоротливое чудовище ультимэйт ни к чему.

(77) За 10 лет + еще сколько до выхода работали - 1с смогла бы уже конфигуратор свой, новый, написать. EDT явно провальный проект.

Как - то так. некоторые у нас на предприятии уже перешли на ЕДТ

(83) вот тут не могу не согласиться.
на самом деле, конфигуратору не так уж много и надо вкуснях для повышения удобства и скорости разработки.

(82) а в РФ на джаве нет работы? странно

(85) мне конфигуратор напоминает Delphi первых версий. я в 14 лет что-то писал даже на дельфях, забыл все.

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

Установили EDT как увидели новость про выход 1С:Напарника) будем погружать в тру разработку

заказчик планирует.

(89) кстати, да, Напарник тоже заинтересовал.

на текущий момент

(89) больше мешает, недавно отключил непрерывное завершение кода - лепит по большей части чушь, не попадая в объекты конфигурации
пару раз поверил - пришлось переписывать, плюнул и отключил

+93 пробовал заставить написать процедуру - дольше "уговаривал" и не добился результата, чем ее было написать