Как вести параллельную ( || ) разработку

[LedgerVoucher]

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

[art]

На сколько я знаю единственный инструмент для параллельной разработки, который есть в AOT-е - это блокировка на уровне объектов, т. е. можно заблокировать целиком форму, класс, таблицу ...

[LedgerVoucher]

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

[Андре]

Цитата:

Вы немного меня не поняли .... разработка ведется в разных приложениях.

А зачем это нужно ? Или разработчики разнесены территориально и в принципе не могут работать в одном приложении ?

Цитата:

И все бы было хорошо, если бы объекты разработки не пересекались..... Вопрос в том как в этом случае упростить и ускорить объединение этих приложений

Единственное решении, которое вижу я - это не позволять разработчикам, чтобы изменяемые ими объекты пересекались. Но это уже больше административные меры.

[Dron AKA andy]

А почему не Вы не используете простой и в то же время достаточно мощный инструментарий сравнения объектов? Ведь если изменения в один и тот же объект внесли в обоих приложениях, как иначе корректно совместить эти изменения?

[art]

Можно еще вести разработку в разных слоях USR и USP, тогда предидущее предложение с механизмом сравнения двух текстов (слоев) будет еще проще...

[LedgerVoucher]

-> Андре
1. Действительно разработчики работают в независимых приложениях
2. Запретить модифицировать одни и теже объекты достаточно сложно. Хотя разработка и ведеся по разным направлениям, но при этом достаточно часто одновременно в разных приложениях изменяются одни и теж формы или классы (для разных целей).
Как объединять эти два приложения быстро и эффективно???
-> Dron AKA andy
Механизм сравнения дествительно эффективная штука, но для небольшого объема. При увеличении объема, процесс сравнения и создания корректного кода значительно усложняется, и сильно увеличивается затраченное на это время.
-> art
Со слоями таже трудность, даже если разработка ведется в разных слоях при "склеивании" слоев опять же надо тратить время на их сравенение и создание из двух кусков одного.

[undercover]

Опыт показывает, что оптимальный способ - выделять мастерверсию приложения и, по возможности, в порядке очереди, всем участвующим в разработке разработчикам поднимать на нее модификации со своих локальных версий. При этом _обязательно_ пользоваться инструментом сравнения слоев. Таскать версию между группами разработчиков не рекомендуется - каша получится. Если разработчик работает удаленно - то его модификацию поднимает свободный разработчик из числа тех, кому доступна мастерверсия. Мастерверсии нужено эммитировать с присвоением порядкового номера. Бэта версии - не должны быть доступны консультантам во избежании казусов и истерик.

[LedgerVoucher]

Конечно Вы правы. Это неплохой вариант, но при одновременном изменении одних и тех же объектов в двух группах разработчиков, будет необходимо осуществлять "обратную связь", т.е. мастерприложение (созданное из двух разных) необходимо отдавать этим двум группам разработчиков (для того чтобы расхождение в разработке были минимальны). В свою очередь востановление этого мастерприложения у разработчиков на местах, будет занимать некое продолжительное время - что плохо.
Возможно в решении этой проблемы помогло бы детальное документирование проделанных изменений, но опять же на это тратится определенное время и не все разработчики с удовольствием идут на это, да и не всегда смогут задокументировать все изменения полностью. И опять же что документировать? Измененный код??? Элементы АОТ???
Тут другая проблема, в каком виде документировать изменения, чтобы это максимально помогло бы разработчикам при сравнении слоев и их склеивании???

[macklakov]

Я, в свое время, придумал следующий хитрый способ объединять версии: воспользоваться внешней утилитой сравнения, к примеру, мы пользуемся Araxis. Можно взять windiff из MS VS. Сценарий следующий:
1. проекты экспоритруем в файлы из проектных версий, желательно, чтобы в проекты входили одинаковые элементы.
2. сравниваем экспоритрованные файлы и объединяем их в один файл. Код экспортного файла вполне читаемый, поэтому проблемм возникнуть не должно. 3.Полученный, объединенный файл импортируем в тестовую версию.
4. Компилируем, проверяем, переносим метки и настройки и т.д.

[undercover]

Учитывая специфику системы (в т.ч. несовершенство средств разработки) 99% предложеных методик ведения кооперативной разработки будут далеки от идеала. Однако, это вариант позволояет установить баланс между скоростью разработки и сложностью его реализации. Он требует аккуратности от разработчиков, чем, к сожалению, большая часть последних не страдает
Г-н LedgerVoucher совершенно верно обратил внимание на документирование проектов. У меня, к примеру, есть такая мечта: иметь человека хорошо знающего ф-ть системы и имеющего хороший опыт программирования, который бы в Rational Rose рисовал склетон классов и все остального. Более того, были попытки проделывать эту операцию как на этапе анализа, так и перед этапом первого тестирования проекта. И в первом и во втором случае временные потери не оправдываются. Согласитесь, ведь если сборкой версии занимается достаточно опытный разработчик, знающий все горячие клавиши и быстро рулящий мышью, он, вероятнее всего, не будет пользоваться предложенной ему диаграмой. Ему проще поискать в коде текст коментариев, относящихся к проекту и сравнить слои приложения (usr и usp). Помоему, так.
Есть вариант вести список модифицированных элементов репозитария в экселе. Еще можно много чего придумать. Стоит ли?
imо, напрашивается вывод - сажать за сборку версии опытного разарботчика - относительно безболезненное решение.

[Андре]

Цитата:

macklakov

Я, в свое время, придумал следующий хитрый способ объединять версии: воспользоваться внешней утилитой сравнения, к примеру, мы пользуемся Araxis. Можно взять windiff из MS VS. Сценарий следующий:
1. проекты экспоритруем в файлы из проектных версий, желательно, чтобы в проекты входили одинаковые элементы.
2. сравниваем экспоритрованные файлы и объединяем их в один файл. Код экспортного файла вполне читаемый, поэтому проблемм возникнуть не должно. 3.Полученный, объединенный файл импортируем в тестовую версию.

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

[LedgerVoucher]

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