AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.07.2002, 14:03   #1  
LedgerVoucher is offline
LedgerVoucher
Участник
 
12 / 10 (1) +
Регистрация: 20.06.2002
? Как вести параллельную ( || ) разработку
Возникла следующая проблема.
Как организовать параллельную разработку в двух приложениях таким образом, чтобы объединение не занимало много времени и сил.
Старый 01.07.2002, 16:42   #2  
art is offline
art
Участник
 
46 / 10 (1) +
Регистрация: 11.06.2002
Адрес: Москва
На сколько я знаю единственный инструмент для параллельной разработки, который есть в AOT-е - это блокировка на уровне объектов, т. е. можно заблокировать целиком форму, класс, таблицу ...
Старый 01.07.2002, 17:34   #3  
LedgerVoucher is offline
LedgerVoucher
Участник
 
12 / 10 (1) +
Регистрация: 20.06.2002
Вы немного меня не поняли .... разработка ведется в разных приложениях. И все бы было хорошо, если бы объекты разработки не пересекались..... Вопрос в том как в этом случае упростить и ускорить объединение этих приложений. Т.е. цель - получить в результате одно и рабочее приложение.
Старый 02.07.2002, 09:21   #4  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Вы немного меня не поняли .... разработка ведется в разных приложениях.
А зачем это нужно ? Или разработчики разнесены территориально и в принципе не могут работать в одном приложении ?


Цитата:
И все бы было хорошо, если бы объекты разработки не пересекались..... Вопрос в том как в этом случае упростить и ускорить объединение этих приложений
Единственное решении, которое вижу я - это не позволять разработчикам, чтобы изменяемые ими объекты пересекались. Но это уже больше административные меры.
Старый 02.07.2002, 10:21   #5  
Dron AKA andy is offline
Dron AKA andy
Moderator
 
944 / 253 (10) ++++++
Регистрация: 27.03.2002
Адрес: Москва
А почему не Вы не используете простой и в то же время достаточно мощный инструментарий сравнения объектов? Ведь если изменения в один и тот же объект внесли в обоих приложениях, как иначе корректно совместить эти изменения?
__________________
Андрей.
Старый 02.07.2002, 11:58   #6  
art is offline
art
Участник
 
46 / 10 (1) +
Регистрация: 11.06.2002
Адрес: Москва
Можно еще вести разработку в разных слоях USR и USP, тогда предидущее предложение с механизмом сравнения двух текстов (слоев) будет еще проще...
Старый 02.07.2002, 17:08   #7  
LedgerVoucher is offline
LedgerVoucher
Участник
 
12 / 10 (1) +
Регистрация: 20.06.2002
-> Андре
1. Действительно разработчики работают в независимых приложениях
2. Запретить модифицировать одни и теже объекты достаточно сложно. Хотя разработка и ведеся по разным направлениям, но при этом достаточно часто одновременно в разных приложениях изменяются одни и теж формы или классы (для разных целей).
Как объединять эти два приложения быстро и эффективно???
-> Dron AKA andy
Механизм сравнения дествительно эффективная штука, но для небольшого объема. При увеличении объема, процесс сравнения и создания корректного кода значительно усложняется, и сильно увеличивается затраченное на это время.
-> art
Со слоями таже трудность, даже если разработка ведется в разных слоях при "склеивании" слоев опять же надо тратить время на их сравенение и создание из двух кусков одного.
Старый 07.07.2002, 20:23   #8  
undercover is offline
undercover
Участник
 
8 / 10 (1) +
Регистрация: 22.12.2001
Опыт показывает, что оптимальный способ - выделять мастерверсию приложения и, по возможности, в порядке очереди, всем участвующим в разработке разработчикам поднимать на нее модификации со своих локальных версий. При этом _обязательно_ пользоваться инструментом сравнения слоев. Таскать версию между группами разработчиков не рекомендуется - каша получится. Если разработчик работает удаленно - то его модификацию поднимает свободный разработчик из числа тех, кому доступна мастерверсия. Мастерверсии нужено эммитировать с присвоением порядкового номера. Бэта версии - не должны быть доступны консультантам во избежании казусов и истерик.
Старый 08.07.2002, 12:00   #9  
LedgerVoucher is offline
LedgerVoucher
Участник
 
12 / 10 (1) +
Регистрация: 20.06.2002
Конечно Вы правы. Это неплохой вариант, но при одновременном изменении одних и тех же объектов в двух группах разработчиков, будет необходимо осуществлять "обратную связь", т.е. мастерприложение (созданное из двух разных) необходимо отдавать этим двум группам разработчиков (для того чтобы расхождение в разработке были минимальны). В свою очередь востановление этого мастерприложения у разработчиков на местах, будет занимать некое продолжительное время - что плохо.
Возможно в решении этой проблемы помогло бы детальное документирование проделанных изменений, но опять же на это тратится определенное время и не все разработчики с удовольствием идут на это, да и не всегда смогут задокументировать все изменения полностью. И опять же что документировать? Измененный код??? Элементы АОТ???
Тут другая проблема, в каком виде документировать изменения, чтобы это максимально помогло бы разработчикам при сравнении слоев и их склеивании???
Старый 09.07.2002, 16:10   #10  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Lightbulb
Я, в свое время, придумал следующий хитрый способ объединять версии: воспользоваться внешней утилитой сравнения, к примеру, мы пользуемся Araxis. Можно взять windiff из MS VS. Сценарий следующий:
1. проекты экспоритруем в файлы из проектных версий, желательно, чтобы в проекты входили одинаковые элементы.
2. сравниваем экспоритрованные файлы и объединяем их в один файл. Код экспортного файла вполне читаемый, поэтому проблемм возникнуть не должно. 3.Полученный, объединенный файл импортируем в тестовую версию.
4. Компилируем, проверяем, переносим метки и настройки и т.д.
Старый 11.07.2002, 18:14   #11  
undercover is offline
undercover
Участник
 
8 / 10 (1) +
Регистрация: 22.12.2001
Учитывая специфику системы (в т.ч. несовершенство средств разработки) 99% предложеных методик ведения кооперативной разработки будут далеки от идеала. Однако, это вариант позволояет установить баланс между скоростью разработки и сложностью его реализации. Он требует аккуратности от разработчиков, чем, к сожалению, большая часть последних не страдает
Г-н LedgerVoucher совершенно верно обратил внимание на документирование проектов. У меня, к примеру, есть такая мечта: иметь человека хорошо знающего ф-ть системы и имеющего хороший опыт программирования, который бы в Rational Rose рисовал склетон классов и все остального. Более того, были попытки проделывать эту операцию как на этапе анализа, так и перед этапом первого тестирования проекта. И в первом и во втором случае временные потери не оправдываются. Согласитесь, ведь если сборкой версии занимается достаточно опытный разработчик, знающий все горячие клавиши и быстро рулящий мышью, он, вероятнее всего, не будет пользоваться предложенной ему диаграмой. Ему проще поискать в коде текст коментариев, относящихся к проекту и сравнить слои приложения (usr и usp). Помоему, так.
Есть вариант вести список модифицированных элементов репозитария в экселе. Еще можно много чего придумать. Стоит ли?
imо, напрашивается вывод - сажать за сборку версии опытного разарботчика - относительно безболезненное решение.
__________________
---------
underCover
Старый 15.07.2002, 15:32   #12  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
macklakov

Я, в свое время, придумал следующий хитрый способ объединять версии: воспользоваться внешней утилитой сравнения, к примеру, мы пользуемся Araxis. Можно взять windiff из MS VS. Сценарий следующий:
1. проекты экспоритруем в файлы из проектных версий, желательно, чтобы в проекты входили одинаковые элементы.
2. сравниваем экспоритрованные файлы и объединяем их в один файл. Код экспортного файла вполне читаемый, поэтому проблемм возникнуть не должно. 3.Полученный, объединенный файл импортируем в тестовую версию.
Хм. То есть вы вручную редактируете текстовый файл проекта, а затем закачиваете его в Аксапту. Насколько это надежный способ. Не было ли случаев, когда в результате ручной правки проекта, его структура оказывалась испорченной и он отказывался закачиваться в Аксапту ?
Старый 15.07.2002, 19:06   #13  
LedgerVoucher is offline
LedgerVoucher
Участник
 
12 / 10 (1) +
Регистрация: 20.06.2002
И опять же, надо чтобы таким объединением рулил человек который знает кто чего написал и зачем (особенно в пересекающихся объектах) - а это не всегда возможно в разнесенных проектах. Тогда нужна документация по каждому внесенному изменению, а это опять рождает ряд трудностей. Если документация подробная - то объединять легко, но писать саму документацию долго. А если документация простая, то наоборот объединять долго.
Теги
слои

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
В каких слоях вы можете вести разработку? (можно выбрать несколько вариантов ответа) mazzy DAX: Прочие вопросы 4 26.02.2009 11:01
Как лучше всего вести лог? mazzy DAX: Администрирование 12 27.08.2007 16:12
Лицензия на разработку vdiomin DAX: Программирование 0 15.04.2005 11:21
Как не дать экспортировать разработку из Аксапта 2.5? Pavlo AKA Panok DAX: Администрирование 5 18.11.2003 22:46
Как вести учет договоров mick_777 DAX: Программирование 13 07.08.2003 16:12
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.