Конфигурация.
Несколько разработчиков.
Как организовать совместную разработку конфигурации...?
Стопудово думаю что такое асы-77 делали.
Если нужно версионирование, то gcomp + некое хранилище, у каждого разработчика своя копия md.
Если не нужно версионирование, то просто у каждого разработчика своя копия md.
ps
сам я такой практики на 77 не имею, совместная разработка только в 8
то есть у каждого разработчика - своя конфигурация.
майстрячит в конфигурации своей.
потом каждый разраб разбирает Gcomp конфигу
и потом эти несколько разобранных mdшников сливаются в одну?
типа так?
типа так
Молчание сообщества свидетельствует о том, что клюшечники - единоличники, всё в одно лицо делают..? или могут тянуть большую контору в одиночку? ;-)
Не, раз уж подразумевается совместная разработка, когда один не тянет, то сборка и контроль релизов должны выполняться специально обученным(и) мейнтейнером. А там ещё и тестовый контур... и всякие аджаилы со скрамами... но так-то и до ретроспективных спринтов можно докатиться.
какие-то еще такие страшные слова..
пара разработчиков. они и мерджеры и тестеры итд.
глобальный модуль чтобы собирать
и видеть хотя бы какие объекты другие затронуты
И как же оне будут "видеть"? В терминах конфигуратора, пжлста.
А так, по планировщику или по нейронной реакции майнтейнера gcomp'ом разбираешь и пушишь в гит.
Года до 20го очень активно использовал совместную разработку: где-то на Селезнёвке 1С ваяла свои типовые, а где-то дома и на работе - я параллельно ваял свои. Потом всё это за пару-тройку часов неторопливо сливалось в один мдшник.
Рабоче-крестьянский способ:
ТиповаяДо1
ТиповаяДо2
ТиповаяПосле1
ТиповаяПосле2
Моя
Объединяем ТиповаяДо1 с ТиповаяПосле1 (1), а ТиповаяДо2 с Моя (2).
Смотрим, какие изменения не пересекаются, и объединяем замещением ТиповаяПосле2 с Моя, получаем ТиповаяМояПосле.
Также замещаем те доработки, которые в Моя значительны, а в ТиповаяПосле2 - малы, потом возвращаем замещенные куски в ТиповаяМояПосле глядя в (1).
Остальное - правим ТиповаяМояПосле глядя в (2).
Я так думаю, что многие таким или похожим образом обновляли сильно доработаные типовые.
Не представляю, как много надо наработать и насколько редко обновлять, чтобы сборка представляла сложность. Нет, если конечно два разраба параллельно делают одну и ту же задачу, но каждый свои путем, то сложности будут. Но зачем?
А если по делу, то:
Цитата: Arbuz от 15 октября 2024, 15:23сборка и контроль релизов должны выполняться специально обученным(и) мейнтейнером
подписываюсь.
А уж инструмент - выбирай сам, что проще окажется - типовой функционал, Gcomp..
Получается ТиповаяПосле - это разраб1, а я - это я Разраб2...
что-то сильно мутно.
чтобы обновляться - приходится ждать пока ТиповаяПосле (разраб1) выкатит готовый свой вариант? а это вообще не вариант...
надо подумать...
\
Можно сделать скрипт для OpenConf чтобы разбирал md'шник при каждом сохранении конфигурации. И пушил в гит. Но кто-то должен будет отслеживать изменения, делать коммиты и мёржить ветки, буде оне таки. Также надо будет собирать (меж)итоговые релизы и доставлять их до разрабов/в прод.
надо подумать еще...
Цитата: Злоп от 16 октября 2024, 15:22что-то сильно мутно.
Что-то я плохой объясняльщик, видимо. Суть в том что параллельная работа нескольких разрабов ничем не отличается от обновления типовой доработанной конфигурации.
Сравниваешь, что сам (второй разраб) наработал.
Сравниваешь, что 1С (основной разраб) понаделала.
Сливаешь вместе: где нет пересечений - замещением, где невозможно - руками. Не знаю, зачем пишу - уверен, опыт доработки и поддержания обновления типовых у тебя и так есть.
Волшебной 100% объединялки нет - если оба разраба параллельно меняют логику одного модуля - всё равно придётся контролить руками.
Смутно помню, что МОД от ПиБИ для обновлений модулей использовал какой-то свой механизм, типа вставки и анализа тэгов [МОД] и [/МОД] в тексте модуля. Но уверен - это не вариант.
У нас 3 человека (почти 4). Все со своими отдельными конфигураторами. Когда надо слить в общий - просто просим выйти из основного и занимаем его на время переноса. А про внешние отчеты и обработки и говорить нечего. Просто предупреждаем, что "занял такой-то отчет". Из общего конфигуратора (т.е. базы, откуда уже отправляется в рабочую базу) - МДшник и отчеты копируются скриптом. МДшник копируется в папку для MDChanger-а. Т.е. подмена по сути на лету. Только перезайти пользователю нужно. Понтяно, что если нужна реструктуриация - тогда всех выгоняем.
Цитата: alyuev от 18 октября 2024, 12:12У нас 3 человека (почти 4). Все со своими отдельными конфигураторами. Когда надо слить в общий - просто просим выйти из основного и занимаем его на время переноса. А про внешние отчеты и обработки и говорить нечего. Просто предупреждаем, что "занял такой-то отчет". Из общего конфигуратора (т.е. базы, откуда уже отправляется в рабочую базу) - МДшник и отчеты копируются скриптом. МДшник копируется в папку для MDChanger-а. Т.е. подмена по сути на лету. Только перезайти пользователю нужно. Понтяно, что если нужна реструктуриация - тогда всех выгоняем.
Это хорошо когда редактируются независимые объекты?
А если каждый например еще и глобальник добавляет и правит?
Варианы есть:
- FormEx: доп.глобальники, разделенные по разработчикам.
- Классы 1с++, в глобальнике только заглушки.
Это не спасет при смене АПИ (процедур и функций), но часть проблем убрет.
Не работал так. Как-то бы напарник, кромсал мою обработку вдоль и поперек, приходилость вникать и патчить мою, до соответствия... Так себе удовольствие.
Не нравится мне такая идея с ДГ и классами.
Это расползание функционала в разные стороны.
.
буду думать...
Работали в 3-4 лица над одной конфой. Связка gcomp + CVS(тогда был). Щас можно git взять, или mercurial.
Особых проблем с конфликтами правок в коде не было. Кода были пересечения, то просто объединяли их kdiff'ом, с небольшим приложением мозга.
Проблемы есть при добавлении метаданных - широко известная проблема с внутренними ИД объектов :)). Решалась просто - метаданные параллельно не правили.
Схема простая: забрал из репозитария, скомпилировал, сделал свои дела, разобрал, положил в репозитарий (в этом месте разруливаешь возникшие конфликты).
Тут проблема в том, что надо себе хорошо представлять эту схему. Что, куда, как и когда. Если никогда этим не пользовался, то это несколько напряжно.
Цитата: Arbuz от 31 октября 2024, 16:49Тут проблема в том, что надо себе хорошо представлять эту схему. Что, куда, как и когда. Если никогда этим не пользовался, то это несколько напряжно.
Вот я как раз про это.
У нас три разраба и 4 разных конфигурации, которые пилятся. Конфы сделанные из ТиСов. Если про глобальник, то имеется один базовый глобальник с наборами функций для всех конфигураций, а в наследнике уже свои специализированные глобальники. Из 1сного глобальника перенаправления делаются для изменяемых процедур и функций, как выше сказано.
Модули этих глобальников (да все классы в общем то) можно налету подменять, при загрузке конфы грузятся из конфигурации (@MD) или из файла, система определяет при старте. Это для УРБД сделано и для версионности при обновлении и удалении неактуальных.
У каждого свои тестовые конфигурации для разработки и демонстрации, все изменения сливаются в один МДшник (девелопная версия и можно кодревьювить), новые объекты метаданных создаются там же и загружаются в тестовые через загрузку (не часто надо, потому нормально). В девелопной версии никто не сидит, зашёл – обновил – вышел. И конфа не для запуска вообще.
За правильность не ручаюсь.
Вообще мне стыдно, но написал это всё чтобы спросить: хочу обновить 1с++ с 2.5.0.7 до 3.2.4.1 (кое что нужно), а её не видно в Сервис – Параметры – «Настройка 1С++», всё работает, классы грузятся. Гуглить что-то не помогает.
Цитата: Mugface от 25 декабря 2024, 09:23хочу обновить 1с++ с 2.5.0.7 до 3.2.4.1 (кое что нужно), а её не видно в Сервис – Параметры – «Настройка 1С++», всё работает, классы грузятся
Помощь — О программе
За пару часов переводил конфигурации с 1c++ 2.5.* на 3.*
Изменения небольшие, это быстро...
P.S. Некоторые глюки придется поискть и устранить.
Это не так сложно, как кажется.
Цитата: Злоп от 15 октября 2024, 12:38Молчание сообщества свидетельствует о том, что клюшечники - единоличники, всё в одно лицо делают..? или могут тянуть большую контору в одиночку? ;-)
да всё просто ))
кто старше и круче тот работает в своей копии конфы, остальные в нее накатывают свои изменения
дико? ну мы же на 77 )))
Попробовал потестировать 3.2.4.1 вместо 2.5.0.7 и столкнулся с проблемой: при разрушении класса наследника в версии 3.2.4.1 "теряется" сам базовый класс. И не всегда, а ровно через раз. В 2.5.0.7 этой проблемы нет.
Сделал конфигурацию с 1С++ dll-ками, при загрузке спросит какую версию загрузить и откроет обработку с кнопкой по которой появляется ошибка если нажимать кнопку. Не могу понять где у меня ошибка. Может подскажете где я туплю, спасибо.
https://disk.yandex.ru/d/Kh-7-a58TBNxog
что значит "теряется"?
посмотрел что значит "теряется"
А почему не хочешь Сам().ФункцияБазовогоКласса() ?
Цитата: trad от 04 февраля 2025, 10:30посмотрел что значит "теряется"
А почему не хочешь Сам().ФункцияБазовогоКласса() ?
Потому что в наследнике может быть своя ФункцияБазовогоКласса (название неудачное для примера) со своим дополнительным для класса функционалом. И через Сам() вызовется она. А мне нужно вызвать ФункцияБазовогоКласса() из базы, а потом в наследнике доделать свои дополнительные действия. В приложенном примере Сам() решит проблему, это я стормозил. Но при наличии ФункцияБазовогоКласса() в наследнике будут у меня проблемы.
Тесть из примера "_ОсновнойБазовыйКласс" базовый, у него может быть несколько наследников со своими функциями ФункцияБазовогоКласса или без неё.
Может как-то так?
Базовый = вирт().ПолучитьБазовыйКласс("ODBCRecordSet");
Базовый.Отладка(ВключитьОтладку);