Подскажите по сабжу.

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

Пытаюсь собрать идеи как это можно реализовать и чтобы оно работало.

Понимаю что будут сложности но с помощью
https://ru.wikipedia.org/wiki/Git
и
https://wonderland.v8.1c.ru/blog/inkrementalnaya-vygruzka-konfiguratsii-v-xml/
это вполне можно реализовать.

Как это себе представляю что на сервере конфа разбирается в xml файлы.
Эти xml файлы выгружаются в некую систему "веб-конфигуратора" и там редактируются.
По команде/заданию они обратно загружаются и собираются в конфу 1С  для запуска и тестирования.

Для кода на ЯП 1С реализовать редактор проблем не вижу особых кроме времени (и денег).

Но что делать с редакторами форм и прочего?

Извращенцы.

(1) Угу групповая разработка

(2) Что групповая, то да. Но что разработка - это еще вопрос.

Чем вариант VPN + Удаленный рабочий стол не устраивает ?

(3) Через RDP очень неудобно любовью с конфой и базой заниматься одной.
Если же базу клонировать то оно потом глючит когда назад соединяется если отдельно любились.

Хочется что пока один разработчик что то пишет, другие используют старую конфу, затем пуллит свои наработки и профит другие сразу могут потестить как оно.
Если все ок то другие принимают и дальше работают.

Причем можно с разными релизами/версиями работать, доработки разных разрабов по разному с на копиях базы совмещать и смотреть что будет/происходит.

https://www.yandex.ru/search/?lr=213&offline_search=1&text=eclipse%20web%20developer%20tools

(4) Несколько разработчиков, нужен удобный инструмент причем без возни с локальными копиями базы/конфы или на сервере.

Т.е. все автоматом делается само скриптами по командам

(6) Думаешь можно совместить с http://v8.1c.ru/overview/release_IDE_beta/ ?

(0) все равно непонятно зачем.
запушил код на сервер, там собрал релиз и обновил базу  , под веб или рдп проверил.
надо, чужие изменения , обнови свою репу.

(9) Время, нужна оперативность теста влияния чужих доработок/изменений на свой код.

Т.е. чтобы не растягивать и не тратить время на согласования а тупо нужно тебе что то в чужой части - меняешь сам и Pull Request
- все прочие или только чья часть глянул и если ок то принял или сам поправил но так чтобы было как тебе надо в т.ч.

***Для кода на ЯП 1С реализовать редактор проблем не вижу особых кроме времени (и денег). ***

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

Придумали EDT, связали его с git, но зачем нам всё это? Почему бы свой велосипед не наковырять, да?

Хранилище предлагать, или надо полное "импортозамещение"?

А чем хранилище не угодило?

(11) +100
(0) Утопия.

(12) (13) Думал про хранилище и думал про терминальный сервер (в том числе с rdp клиентом в браузере) где развернута 1С и отдельные учетки со своими копиями баз для каждого разраба.

Но это не так удобно чем было бы в браузере кодить

(14) >Утопия.

Нет просто забежал вперед лет на 5, думаю сваяют это для фреша

(11) Попробуйте http://jsfiddle.net/ или https://github.com/mozilla/thimble.mozilla.org

Так что да я сразу написал что вопрос времени и денег.

(15) В броузере нужно котиков лайкать, а не кодить

(18) Вы предпочитаете лайкать котиков в конфигураторе 1С?

(19) Я котиков лайкаю там, где положено - в броузере.
И программы пишу там, где положено - в IDE

(15) сдается, что автор совсем того.. низко пал. Из мобильного браузера хочет, небось.

А чем EDT или хранилище конфигурации через http не устраивают? Для каких целей изобретается сей лисапед?

(5) "Хочется что пока один разработчик что то пишет, другие используют старую конфу, затем пуллит свои наработки и профит другие сразу могут потестить как оно.
Если все ок то другие принимают и дальше работают. "

Всё это прекрасно разруливается стандартным хранилищем конфигурации + некоторыми соглашениями между разработчиками

(22)(23) Тут больше вопрос удобства, особенно в части скорости подключения к разработке/доработке.

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

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

(25) Это не проблема, проблема что дальше делать с файлами, как их редактировать через браузер удобно

(26) Зачем браузер, загружаешь изменения в свою копию базы и вперёд.

(24) а что не так со скоростью подключения к разработке/доработке при использовании хранилища конфигураций?

(28) Невозможно параллельно вносить изменения в один и тот же модуль например.

(27) Да сейчас оно так и есть, но хочется чтобы не надо было держать базу на компе разработчика как даже устанавливать 1С.

Решение с работой по RDP конечно возможно, но хочется все в одном в комплекте с багтрекером, планировщиком, чатом и т.д.

(29) Нет это вполне возможно, если разные процедуры/функци

(29) это вопрос организации разработки, а не хранилища конфигурации

Напиши свою адинэс где можно разрабатывать в вебе

(32) Вот только не надо про сферических коней, единорогов и радугу))

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

(35) параллельно они не смогут. Если 15 разработчиков сразу.

(36) В хранилище смогут

(37) В хранилище целиком объекты метаданных захватываются, хотелось бы чтобы было по реквизитам захват, формам, а модули аж совместная разработка с захватом процедур/функций отдельных.

(38)+ Ну и еще фишка это тестовые данные общие и тестирование совместной работы обработок как в реальном режиме и на реальном оборудовании.

Т.е. когда разработчик запускает выполнить - открывается веб-клиент для текущей базы.

(38) "а модули аж совместная разработка с захватом процедур/функций отдельных." - это же трындец будет. Вася захватил реквизит сумма и процедуру при изменении суммы, петя захватил колчиество цену и тут Васе тоже понадобилась цена и процедуры ее изменения. Как они будут процедуру делить?

(40) Нет "захват" только для редактирования/изменения реквизита.
Пока он захвачен можно использовать в коде старое свойство реквизита с его старым значением при выполнении кода.

Получая предупреждение и в подсветке кода что реквизит захвачен и при выполнении.

По сути как блокировка объектов в режиме предприятия, но блокируется не весь объект а только отдельный реквизит/ТЧ.

(41)+ Я конечно понимаю что пока это утопия, но хочу удобный инструмент для одновременной совместной работы в онлайне.

Один захватил процедуру и правит ее, в это время другой захватывает для изменения реквизит используемые в процедуре.
Первый видит это (получает сообщение и подсветка в коде имени реквизита) и может тут же написать второму:
"ты что менять собрался? Просто увеличить разрядность или что?"
Если ответ да - продолжает кодить, если же ответ "нет хочу удалить или урезать или переименовать" - тут уже бросаем кодинг и начинаем обсуждать как это повлияет и т.д и т.п.

(16) Для фреша - стандартный механизм поставок.
Сама идея Фреш подразумевает невнесение каких либо изменений на местах.

(43) Это убьет основу на которой выросла 1С, с моментальными исправлениями/правками ошибком или доработками (после бэкапа) на живой базе.

Бизнес зараза хочет оперативность и даже готов пожертвовать надежностью и обычно согласен заплатить за оперативность дороже.

(44) Ну хз.
Там где я работал - главное что бы было надежно и за это готовы были платить.

А для оперативности - есть расширения

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

(45) Значит там было все очень стабильно и минимум изменений в конфе?

(46) Расширения это попытка и на елку влезть и ничего не оцарапать, пока не очень удачная.

(47) При мне в этерпрайз базе сделали динамическое и база рухнула - получили по жеппе нехило так те кто дал добро. (48) Нет естесственно 3 окна для обновления в день, но будьте любезны - без факапов

(50) По идее у меня мысля как раз сократить количество и качество факапов, за счет повышения степени коммуникативности между несколькими разработчиками

(51) Ошибаются все, абсолютно.
Без контроля и регламента шанс факапа очень сильно зависит от числа разработчиков

(51)+ Вплоть до того что в онлайне видеть что сейчас делают другие разработчики, просто открыв окошко/вкладку.

(53) Мне за 5 лет в 1с ни разу не понадобилось посмотреть что делает сосед.
Так себе киллер фича.
Смотрят как правило постфактум - а кто автор сего чудесного произведения?)
Тесты + ревью. ИМХО

(54) Если ты заранее будешь знать (в момент своей разработки) о приближающемся возможном факапе это же поможет?

Ну и сокращаем время на слияние разработок разных разработчиков если они пересекаются в чем то.

(55) ОФФ: Напиши Деду Морозу письмо. Авось, исполнится.

(55) То есть на разрабов ляжет еще и QA?
Перефразирую один из законов вселенной - каждый стремится достигнуть результата с минимально возможными затратами.
Захвачен можуль НДС? Так что я делаю - закупки. Модуль закупок свободен? - воткну туда.

(55) Не поможет от слова никак.

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

(59) >расход бумаги и тонера должен был упасть, а по факту - возрос

Идиоты надо было просто вычитать из зарплаты все расходы на бумагу и тонер ))

И пофиг надо оно или нет реально печатать, кому точно надо выдавать премию по концу месяца.

(59) Меня тоже бесит наш бух который все документы печатает вместо того чтобы работать с экрана.

Но зато ля экономит где не надо печатая на черновиках и убивая принтеры...

(60) Идиотизм - согласен.
Ладно бы такая штука была в одном месте - я это видел как минимум в 3х.
Но попробуйте хоть копейку вычесть с оклада законными средствами)
(61) Печать на стандартных ЧБ черновиках на стандартных ЧБ принтерах не убивает принтеры, я вам как человек с под 100 сертификатов по ремонту этой техники говорю.

А по теме сейчас уже на предыдущем месте работы одной из моих обязанностей было техническое и технологическое сопровождение 9ти очень неплохих разработчиков.
Все новое - бегаешь как попка попугай, чуть ли не на коленях умоляешь использовать.
В той же жире - ну сцуко вводите по факту затраченное время, нас на собраниях ипут, что задача в колонке находилась 5 минут, а ее ждали 3 дня.
Сделал гитхаб - все забили.
Тестирование - меня чуть на бутылку не посадили.
Стандарыт разработки от 1с (а там и 10 и 15 лет опытва есть люди) - многие в первый раз увидели, с горем пополам заставили.
Руководству все это не надо.
Разработчикам тоже, в должностных инструкциях этого нет (c).
Вот и бегаешь бьешься...

Руководству надо быстро и качественно.
Разработчикам - быстро и что бы мозги не ебали.
Навешивание любой новой обязанности, если оно не идет снизу - жопная боль с 2х сторон
- Скорость падает - начальство недовольно
- Прибавилось обязанностей - люди недовольны.
Забьешь на начальство - будут мозги клевать.
Забьешь на людей - увольняются, потом новых очень тяжело найти.

Я последние 3 месяца просто устал уже с этим бороться и в итоге пошел туда - где этого хотят....

(62) >Печать на стандартных ЧБ черновиках на стандартных ЧБ принтерах не убивает принтеры

1. Черновик не может быть более гладким и чистым чем новая бумага из пачки.
- более сильно царапает и пачкает все что можно и с чем касается.

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

(66)+ Использование черновиков всегда увеличивает расход тонера и износ механики.
Учитывая стоимость бумаги vs стоимость тонера и принтеров (а так же рабочего времени на исправление проблем), обычно выгоднее сдать черновики в макулатуру (пусть и за копейки) и купить чистой бумаги.

(0) Так прикрути к своему аналогу TeamViewer- а и не парься.

(66)
1) Бред. Я вам как человек работавший в том числе и в топовом сегмете говорю https://yadi.sk/i/EXHmi_0P4q7VHw
2) Скрепки и дырокол они могут и другими путями внутрь попасть. Вы себе даже не представляете как)
В хороших местах - при использовании черновиков - требуется убедится что нет посторонних предметов. Этого достаточно.
(67) А производители незнали и везде суют дуплекс.
Давайте про принтеры больше не надо.

(69) Человек который с подобным сертификатом зарабатывает на обслуживании вышедших из строя принтеров? ;) Ну ну.

(70) вы думаете новичков к такой технике сразу подпускают?)
И офисный сегмент тоже чинил.
Только я ушел из той области в 14 году.
Сама физика и механика процесса не менялась с момента изобретения. Единственный скачек там был - переход от аналоговой печати к цифровой.

А по факту - сухой электростатический перенос как был и остался.
Узел захвата, узел синхронизации, узел переноса, узел термозакрепления - есть везде.
Разница в количестве датчиков и навороченности.
Суть от этого не меняется.

(71) Я не буду спорить что использование очень хороших черновиков не убивает практически.
Но к сожалению это затраты рабочего времени на проверку и подготовку этих черновиков, а учитывая человеческий фактор, вытекает в пропущенные скрепки и ремонт принтера который сразу убивает всю "економию".

Сэкономили бумаги на 2000-3000 рублей - отремонтировали принтер на 5000 рублей, обычно результат такой.

(73) Затраты на ремонт идут по другой статье это раз.
Очень часто это безлимитный ремонт с жестким СЛА и фиксированной ценой. это 2.
Случаи когда на каком нибудь 1020 печатают 50к в месяц - это уже клиника, но встречается.

(73)+ И я признаю что я пристрастен в этом вопросе, потому что от экономии на бумаге ничего не получаю, но мне прибавляется работы при выходе из строя принтера, хотя зарплата не увеличивается.

(75) То что это нерационально - согласен.

(74) Блин вы понимаете что пытаетесь оправдать использование низкокачественных комплектующих или допустим хренового масла или топлива?

(77)+ Короче это рулетка в которой выигрывает обычно лишь казино а не игроки.

(77) Черновики - это не низкокачественная расходка)
За левый тонер или барабаны - слет с гарантии как раз плюнуть выписывали.
Черновки - модное в европе, и то что подхватили наши - уменьшение потребления бумаги без необходимости.
Фактор экономической целесообразности - за рамками и принимается на уровне руководства. Мы просты люди можем только ворчать и следовать.
(78) угу

(77) Единственное в чем слукавил, признаю - не всё можно 2ой раз прогнать. Загнутые листы, листы с острой кромкой (плохой разрез, может быть и заводским) - да не стоит. Но плохой разрез и при первом прогоне принести проблем.

(38) в хранилище отдельно захватывается объект, отдельно формы и отдельно макеты. И это даже неправильно, если, например, два человека будут колупать одну форму. Сразу вспоминается басня про лебедя, рака и щуку.

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

(53) зачем? История хранилища всегда покажет, кто и что изменял

(0) >>Но что делать с редакторами форм и прочего?

По большому счету, редактор упр. форм - тоже вопрос исключительно времени и денег. Не понятно, почему обязательно загвоздка в браузере, целевая платформа не Windows? А так, файлы можно править в VSC.

(82) Не далее как 3 недели назад один из клиентов так же сказал.

(0) Автор, бери Eclipse Che https://www.eclipse.org/che/, прикрути к нему модули от EDT, оно ж на Эклипсе, должно подойти. Делов на неделю, к Рождеству управишься.

(86) Ага. К Рождеству оно как раз запустится и распотрошит ERP

(87) Не, ERP оно распотрошит к майским праздникам, не раньше.

(86) такое уже кто-то делал?

(36) тогда надо добавить в требования еще болото, гамак и акваланг

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

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