Случилось страншное... Поделитесь опытом.

[Злоп]

Конфигурация.
Несколько разработчиков.
Как организовать совместную разработку конфигурации...?
Стопудово думаю что такое асы-77 делали.

[trad]

Если нужно версионирование, то gcomp + некое хранилище, у каждого разработчика своя копия md.
Если не нужно версионирование, то просто у каждого разработчика своя копия md.

ps
сам я такой практики на 77 не имею, совместная разработка только в 8

[Злоп]

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

[trad]

типа так

[Злоп]

Молчание сообщества свидетельствует о том, что клюшечники - единоличники, всё в одно лицо делают..? или могут тянуть большую контору в одиночку? ;-)

[Arbuz]

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

[Злоп]

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

[Arbuz]

И как же оне будут "видеть"? В терминах конфигуратора, пжлста.
А так, по планировщику или по нейронной реакции майнтейнера gcomp'ом разбираешь и пушишь в гит.

[Харлампий Дымба]

Года до 20го очень активно использовал совместную разработку: где-то на Селезнёвке 1С ваяла свои типовые, а где-то дома и на работе - я параллельно ваял свои. Потом всё это за пару-тройку часов неторопливо сливалось в один мдшник.
Рабоче-крестьянский способ:
ТиповаяДо1
ТиповаяДо2
ТиповаяПосле1
ТиповаяПосле2
Моя

Объединяем ТиповаяДо1 с ТиповаяПосле1 (1), а ТиповаяДо2 с Моя (2).
Смотрим, какие изменения не пересекаются, и объединяем замещением ТиповаяПосле2 с Моя, получаем ТиповаяМояПосле.
Также замещаем те доработки, которые в Моя значительны, а в ТиповаяПосле2 - малы, потом возвращаем замещенные куски в ТиповаяМояПосле глядя в (1).
Остальное - правим ТиповаяМояПосле глядя в (2).

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

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

А если по делу, то:

сборка и контроль релизов должны выполняться специально обученным(и) мейнтейнером

подписываюсь.
А уж инструмент - выбирай сам, что проще окажется - типовой функционал, Gcomp..

[Злоп]

Получается ТиповаяПосле - это разраб1, а я - это я Разраб2...
что-то сильно мутно.
чтобы обновляться - приходится ждать пока ТиповаяПосле (разраб1) выкатит готовый свой вариант? а это вообще не вариант...
надо подумать...
\

[Arbuz]

Можно сделать скрипт для OpenConf чтобы разбирал md'шник при каждом сохранении конфигурации. И пушил в гит. Но кто-то должен будет отслеживать изменения, делать коммиты и мёржить ветки, буде оне таки. Также надо будет собирать (меж)итоговые релизы и доставлять их до разрабов/в прод.

[Злоп]

надо подумать еще...

[Харлампий Дымба]

что-то сильно мутно.

Что-то я плохой объясняльщик, видимо. Суть в том что параллельная работа нескольких разрабов ничем не отличается от обновления типовой доработанной конфигурации.
Сравниваешь, что сам (второй разраб) наработал.
Сравниваешь, что 1С (основной разраб) понаделала.
Сливаешь вместе: где нет пересечений - замещением, где невозможно - руками. Не знаю, зачем пишу - уверен, опыт доработки и поддержания обновления типовых у тебя и так есть.
Волшебной 100% объединялки нет - если оба разраба параллельно меняют логику одного модуля - всё равно придётся контролить руками.

Смутно помню, что МОД от ПиБИ для обновлений модулей использовал какой-то свой механизм, типа вставки и анализа тэгов [МОД] и [/МОД] в тексте модуля. Но уверен - это не вариант.

[alyuev]

У нас 3 человека (почти 4). Все со своими отдельными конфигураторами. Когда надо слить в общий - просто просим выйти из основного и занимаем его на время переноса. А про внешние отчеты и обработки и говорить нечего. Просто предупреждаем, что "занял такой-то отчет". Из общего конфигуратора (т.е. базы, откуда уже отправляется в рабочую базу) - МДшник и отчеты копируются скриптом. МДшник копируется в папку для MDChanger-а. Т.е. подмена по сути на лету. Только перезайти пользователю нужно. Понтяно, что если нужна реструктуриация - тогда всех выгоняем.

[Злоп]

У нас 3 человека (почти 4). Все со своими отдельными конфигураторами. Когда надо слить в общий - просто просим выйти из основного и занимаем его на время переноса. А про внешние отчеты и обработки и говорить нечего. Просто предупреждаем, что "занял такой-то отчет". Из общего конфигуратора (т.е. базы, откуда уже отправляется в рабочую базу) - МДшник и отчеты копируются скриптом. МДшник копируется в папку для MDChanger-а. Т.е. подмена по сути на лету. Только перезайти пользователю нужно. Понтяно, что если нужна реструктуриация - тогда всех выгоняем.

Это хорошо когда редактируются независимые объекты?
А если каждый например еще и глобальник добавляет и правит?