Всем привет!
Работаем с ЗУП, стандартная конфигурация. Изменений требуется много, всё реализуется через расширения.
До сих пор было 3 разработчика, у каждого своё расширение.
В чем плюс: когда требуется обновить релиз ЗУП, то каждый разработчик тестирует своё расширение, адаптирует его к новому релизу.
Каждый отвечает только за свои доработки.
В чем минусы:
1. Разработчик увольняется, его расширение становится бесхозным. В итоге его начинают как-то делить между собой оставшиеся программисты. Со временем приходит новый разработчик, заводит своё расширение...
2. Одни и те же объекты конфигурации присутствуют в разных расширениях, смотря какой разработчик какую задачу делает. Для 3 расширений это ещё терпимо, но если расширений будет много, то мне кажется это сильно затруднит логику применения расширений, соответственно может сказаться на производительности.

В связи с тем, что штат разработчиков в ближайшее время будет увеличиваться, прошу совета, кто как строит командную работу?
Мне видится использование хранилища расширений конфигурации. Расширения делятся не по разработчикам, а по проектам. Это нужно для того, чтобы косяк одного проекта не вызывал косяки при работе другого. В итоге в нашем случае это будет 2 расширения в ЗУП. Каждый разработчик в хранилище расширений захватывает нужные объекты и вносит изменения.
Но вопрос: как накатывать новые релизы ЗУП?
Если сейчас каждый разраб тестирует своё расширение, то когда расширение станет общим, каким образом допустим 5 разработчиков будут его тестировать? Каждый что-то менял в каком-то документе/справочнике, писал модули... Как-то проблематично поделить между всеми. И потом проблематично найти ответственного за ошибки.

Для этого вроде есть хранилище.

Сделать отдельную базу, в которой тестировать всё.

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

(1) Ну я и пишу, что вижу работу через хранилище.
(2) Конечно для тестирования отдельная база
(3) "Допустим нет расширений" - но у нас то они есть)  Ну вот когда 2 разработчика, то особых проблем нет. Сейчас каждый знает кто что делал, пересечений мало. Но и то путаница возникает иногда. Я спрашиваю совета в том случае, когда разрабов много. Согласны ли, что расширение под каждого разраба - это неправильный путь? Согласны ли, что хранилище расширений - это правильно?

(0) 1. Убрать текучку разработчиков
2. Писать одно расширение через хранилище

И да я искренне не понимаю что вы там в ЗУПе (какой версии?) нахренокодили?

(4) и все-таки... расширения не всегда были. Ну вот не было бы расширений, как тогда ставится разработка?

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

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

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

Неоходимо синхронизировать содержимое расширений друг с другом.
А не просто раздавать объекты из брошенного расширения оставшееся от одного разраба другому разрабу.

Либо все поле разработки должно быть разделено подсистемами, настолько, насколько это возможно и тогда включение объекта в какое-то из расширений.

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

(0)
1) Сделать одно расширение и работать в нем через хранилище.
2) Выделить ответственного за обновление релиза ЗУП(самого опытного, старшего прога и желательно тестировщика), чтобы проверял работоспособность доработок и объектов после обновления.
3) Ну и наверное придется в сторону юнит-тестирования думать, чтобы автоматизировать работу тестировщика.

(8) +

(5) Ну ЕРП дорого было,вот на базе ЗУП его самонаписали.Если у Вас столько разрабов и доработок,найдите ведущего прога,он знает что делать.

(4) 1.начиная с 8.3.13 реализовано хранилище для расширения (для каждого расширения своё хранилище) со стандартным функционалом хранилища...

Вы меня не поняли, я не говорю о том, что вот раньше не было расширений и всё работало, а теперь расширения, и мы не знаем как работу организовать.
Я пишу о том, что раньше у нас было 2-3 разраба, а теперь в связи с новыми проектами штат увеличивается. И просто прошу совета по организации процесса. Т.е. нет у нас опыта работы в большой команде, с расширениями или без. А то что мы работам через расширения - это просто как факт, потому и вопрос связан с тем как нам теперь в новом большом составе с расширениями работать.

(5) Много внешних систем. Но это к вопросу не относится

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

(8) "Выделить ответственного за обновление релиза ЗУП" - вот проблематично. Очень много доработок. Когда в начале года обновления сыплются постоянно, и все очень нужные, у нас просто все задачи стоят, т.к. всё время уходит только на адаптацию расширений к новому релизу. А если ещё и один человек это будет делать... Насчет тестировщика да, планируем. Спасибо за дельный совет.

(10) "Если у Вас столько разрабов и доработок,найдите ведущего прога,он знает что делать." - как объяснил выше, у нас будет много разрабоов. Нет пока опыта такого

(0) "До сих пор было 3 разработчика, у каждого своё расширение." - плохое способ разделения.
Делить нужно либо по функционалу, либо вообще не делить.

Да блин ставьте вы комменты в стиле // 08.03.22. Вася. Задача 12345 +
Проверяют свой функционал, споткнулись на моменте в таком коменте, Пнули васю.

И да, разлеление на расширения/свои модули - такая дичь. Потом открываешь конфу, а там 20 раз один и тот же код в разных модулях, в том числе "ВасинМодульВызовСераера", кто такой Вася знает только посудомойка, так как раьотает там 20 лет, в отличии от полностью обновленного штата it.

(13) (14) Согласен полностью, понимаю что всё неправильно у нас, вот и пришел за советом.

(16) Из практически доступных советов -- опыт использования Хранилища конфигурации имеется?

Как выше уже написали, в Хранилище можно поместить каждое расширение по отдельности.

В целом, опять же выше написали, записывать объекты в разные расширения нужно не по принципу : это у нас пишет Вася, а вот это - Коля, Петя, Витя.

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

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

(17) Опыт использования хранилища конфигурации имеется, в других организациях. Здесь не применяли ещё. С хранилищем расширений разберемся.
В общем всем спасибо. Мои мысли из первого поста подтвердили:
"Мне видится использование хранилища расширений конфигурации. Расширения делятся не по разработчикам, а по проектам. Это нужно для того, чтобы косяк одного проекта не вызывал косяки при работе другого. В итоге в нашем случае это будет 2 расширения в ЗУП. Каждый разработчик в хранилище расширений захватывает нужные объекты и вносит изменения"
Волновал вопрос, как накатывать новые релизы ЗУП. Мысли здравые прозвучали, спасибо. Но всё же это будет геморрой)