Поделитесь опытом разработки через EDT, какие преимущества есть по сравнению с конфигуратором?
Насколько удобно или неудобно, когда приходится что-то "поправить на горячую и сделать динамическое обновление"?
Планирую переход, так как есть необходимость перехода в git и отказа от хранилища. Кроме этого, необходимость связывания коммитов с задачами в Jira

Можно выбить больший бюджет на железо
Или отмазаться - "потому что тормозит"

(0) Это открывает функциональность git со всеми вытекающими последствиями. Преимущества git по сравнению с хранилищем сможете проанализировать самостоятельно?

(2) да

(2) Чтобы работать с git не нужен EDT
Прекрасно можно через Конфигуратор и выгрузка в файлы/загрузка из файлов

(4) для этого необходимо дополнительные действия и настройка  ПО. При этом возникают сложности с привязкой закоммиченых задач. Выгрузка в файлы и загрузка занимает время.

(5) Ты с EDT не работал да?
Там фактически вызывается Конфигуратор чтобы тоже выгрузить/загрузить ))

(6)+ Разработка через Конфигуратор - быстрее отладка, медленней работа с git
Работа через EDT - медленней отладка (особенно первый раз это "часы" на ERP), быстрей работа с git

(5) не работал.
(6) через edt динамическое обновление конфигурации также можно выполнить?

(8) ты путаешь
когда EDT применяет конфу на базу - оно вызывает Конфигуратор и демонически применяет по сути он

(9)+ фактически это как файлом cf конфу обновлять ))

(9) это как-то неявно для разработчика происходит, "под капотом" EDT?
Еще вопрос: работа с конструктором запросов также присутствует и удобна? Если брать требования к железу, то удобство пользования EDT на уровне конфигуратора?

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

(0) Несколько лет работаем в EDT + git + GitLab.

Преимущества:
* git + cicd;
* контроль качества кода;
* код, тесты, документация, внешние обработки в одном репозитории, корректировка в одном окне и коммите;

Недостатки:
* Медленная на больших конфигурациях, разработчикам нужно ставить топовые ПК.
* Глючево EDT

- Динамическое обовление удобно.
- Каждый коммит привязываем к тикету ServiceDesk через тег с номером задачи в комментарии #000000

(13) для хранения репозитория кода использовали гитхаб или что-то локально разворачивали?

(14) Локальный GitLab

(14) community или enterprise вариант? Какие плюсы/минусы гитлаба можешь отметить?

(16) community

Нас устраивает, но есть пару неудобств бесплатной версии:
- Merge request approvals только в платной
- неудобное обновление через VPN

(17) спасибо!

У меня самый главный вопрос к адептам GIT:

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

(19) Зависит от методики доработки/правки
При правильной косяков минимум

(20) а времени сколько занимает примерно? Ну например 3 прога фигачили 3дня  один документ

(21) На самом деле никак это не делается.
И все адепты git-а в этом отношении не то чтобы откровенно пи.. а слегка приукрашивают :)
Кто первый коммит отправил тот свободен, остальные забирают его коммит и начинают вкорячивать туда свои поделки, кто второй успел отправить пошел от радости за пивом.
А последний забирает новый коммит и начинает свое вкорячивать по новой.
Потому в "трушных" языках и мантра - каждый классик в отдельный файлик, никаких функций больше одного экрана.
Чтобы каждый по максимуму правил только свои файлики и в крайнем случае свои части этих файликов.

(19) само по себе странно править одну форму двумя разрабами параллельно. Кажется конфигуратор в такой ситуации не лучше.
Мы одновременно не правим. Вся команда вкурсе кто чем занимается - ежедневные утренние 15минутки.
Косяки редко, но случаются. В этом случае (22). Первый свободен, второй получает гемор.

(21) не нужно допускать таких ситуаций. Пусть правят по очереди.
Например 1-й сделал кнопку красной, 2-й сделал туже кнопку синей. Что должно получится в результате слияния? Фиолетовый?

(23) "Мы" это кто?

(22) Ну в принципе логично. В 1С тоже видать так зашли. Поэтому у них куча процедур вызывающие другие процедуры.

(23) Мда, с Git не работал, но думал что ветки это что то более удобное. А получается что это хуже чем обычное хранилище из конфигуратора, в нем хотя бы принципиально не может быть такого как в (22) и не нужно чтоб каждый знал кто чем занимается, все и так видно кто с чем работает.

(27) Нет сложности преувеличены
Преимуществ при GIT разработке больше чем недостатков
Чем ждать пока освободят в Хране проще договориться в Гите что трогать будет а что нет в одном модуле/форме

(0) поправить на горячую и сделать динамическое обновление"?

Для этого лучше расширения, а с ними едт работает плохо.

(0) "Кроме этого, необходимость связывания коммитов с задачами в Jira"

Выгружай коммиты из гноилища в гит через гитсинк и будет гит Блэйр, привязка к задачам в джире, сонаркуб и CI CD.

*гит блэйм

(25) Мы, это отдел разработки в котором я работаю.
(29) а чем расширение лучше? При включении расширения, ловили такиеже проблемы как при динамическом обновлении.

Импортировал конфигурацию в EDT, настроил GIT и связал с github.
Отмечу следующие моменты:
1)    Нет возможности исправить свойства сразу у нескольких элементов на форме. Это необходимо в случае добавления таблицы на форму и установке в заголовках колонок выравнивания по центру. Времени на эти действия в EDT требуется больше, пропорционально количеству колонок.
2)    Нет возможности установить цвет формы/поля скопировав и вставив значения из палитры свойств элемента.
3)    Медленная работа с формой по сравнению с конфигуратором в случае добавления или перемещения элементов. Создаётся впечатление, что при вышеуказанных действиях движок «пробегает» по всем модулям для повторной проверки кода. Формы несколько «лагают» при разработке, при этом я работаю на машине с SSD, 8 ядер и 16 гб ОЗУ.
4)    Запросы через конструктор открываются приемлемо.
5)    Обновление и запуск из EDT происходит чуть медленнее конфигуратора, но не критично. Однако, в случае реструктуризации и зависшем сеансе пользователя не увидел возможности в EDT принудительно завершить проблемный сеанс
6)    Сам подход к разработке из EDT и необходимости конфигуратора для выгрузки/загрузки изменений, создаёт впечатление, что EDT это некий костыль поверх монументального и хорошо сделанного конфигуратора. Вот если бы в сам конфигуратор добавить git без костылей, то этот инструмент стал бы существенно удобней в работе.
7)    Медленная работа с проектом в EDT огорчает, причём не только старт, сколько любые действия после индексации контекста. Сравниваю с сопоставимыми по размеру кодовой базы проектами в Idea, запуск медленный, но далее скорость вполне приемлемая.

Существуют ли настройки/плагины позволяющие улучшить работу в EDT, без потери удобства для разработчика в сравнении с конфигуратором?

(34) Это ты еще не пробовал в EDT подключится к Git, проект клонировать, ветку создать и из EDT накатить на пустую базу 1С для отладки
Или на уже существующую но старой версии с данными
Причем конфа ERP/КА/УТ11 - вот тогда поймешь что такое "чуть медленнее"

(34) Какая же это гадость EDT и Git

Не понимаю, зачем люди занимаются таким мазохизмом

(36) git очень удобная вещь  в случае распределенной команды . При этом, не нужно плодить в тексте комментарии кто и зачем менял кодовую базу, так как возможность указания номера задачи при коммите полностью решает эту проблему. Также, удобнее смотреть изменения. Несколько легче вопрос с тестированием, на уровне объектов, открытия/закрытия форм.
Плюсов много, однако реализация EDT плоха.

(37) Есть у меня заброшенный проект прокладки - "эмулятора хранилища конфигурации" для Конфигуратора
Чтобы научить Конфигуратор работать "напрямую" с Git

(38) каков в целом механизм работы? Как идет связка коммита и пользователя?

(38)+ Где захват объекта фактически вызывает создание ветки ))
А помещение в хран - просто коммит

(39) Это все еще в стадии продумывания
Фактически реализован прокси (http) на golang для встраивания между реальным храном и Конфигуратором, для перехвата и подмены (использую чтобы на версию платформы не ругался и разное чекал типа комменты требовал и номера задач)

Предполагал еще внешний веб-интерфейс для работы с git и ветками/эмулятором

Так уже есть решение. Вполне рабочее и удобное https://infostart.ru/1c/articles/2014827/
И свои хотелки можно дописывать

(42) Охренеть, не http а tcp
Пусть там и не сильно отличается вероятно

(42) ознакомился, спасибо. Похоже, что этот вариант будет более пригоден для работы чем EDT.

(44) Так это тоже просто прокси сервер (но tcp а не http)
С Git оно не умеет, только с хранилищем