Методологией разработки, тестирования и формирования рабочего приложения в Axapta

[Anais]

С некоторых пор интересуюсь методологией разработки, тестирования и формирования рабочего приложения в Axapta. Как известно, процесс это сложный, мерзкий и с большим количеством подводных камней. Главным образом из-за отсутствия нормальных механизмов слияния объектов/кода. Если разработчики находятся географически в разных местах - ситуация усложняется. Если при этом и постановщики/тестеры (все или некоторые) находятся не там, где разработчики - то сложность еще возрастает.
Лично мне известны и опробованы в бою минимум четыре различных способа работы с модификациями в системе, именуемой Axapta. И ни один из них (кроме, может быть, работы в одно лицо ) я не могу назвать _вполне защищенным от ошибок Axapta и человеческого фактора_.
В связи с этим вопрос к уважаемому сообществу. А как вы работаете на проектах? Где разрабатываете, где тестируете: на локале, в общем приложении? Кто и каким образом формирует рабочее приложение? Какие используете слои и как вы их используете? Пишите ли ФД на заявки бизнес-постановщиков? Почему пишете/не пишете и в каком случае?
Еще интересует мнение тех, кто считает, что разработчики "могут работать в офисе" - каким образом в этом случае строиться процесс разработки и тестирования?

[mazzy]

Для начала вопрос: вы бестпрактис читали и ваши способы совпадают или отличаются от бестпрактисовских?

[Valia]

а кто сказал что жить легко?

[MironovI]

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

[Anais]

Цитата:

Изначально опубликовано mazzy
Для начала вопрос: вы бестпрактис читали и ваши способы совпадают или отличаются от бестпрактисовских?

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

[Anais]

Цитата:

Изначально опубликовано Valia
а кто сказал что жить легко?

А никто не требует легкости. Хочется найти наиболее оптимальный вариант по соотношению цена/качество.

[mazzy]

Цитата:

Изначально опубликовано MironovI
Что самое плохое в удаленной работе - так это слежка за тем чтобы при загрузке изменения не перетерли друг друга...

Та-а-ак. Началось...

Кто-нибудь бестпрактис читал?
Кто знает о патч-слоях? (вижу несколько рук поднялось)
А кто знает об old-слоях? (очень надеюсь, что это я слепой и убогий)
А кто пользуется автоматическим сравнением слоев по всему приложению?

Ребяты, ну сколько можно, а? RTFM, из конца то в конец.

[Anais]

Цитата:

Изначально опубликовано MironovI
Что самое плохое в удаленной работе - так это слежка за тем чтобы при загрузке изменения не перетерли друг друга и у каждого разработчика была актуальная апликуха... ... ...Ну вроде и все меры.. недостаток у такой схемы один и очевидный - необязательность, которую приходится компенсировать увещеваниями и устрашениями, но лучше пока ничего не придумали..

Да, необязательность - это тема Файло на ftp - это мысль А как тестируете? Кто рабочее приложение собирает?

[George Nordic]

Анна!

Позвольте сразу предупредить о проблеме, связанной со слоями/сборкой:
http://www.axforum.info/forums/showt...0384#post70384

Уважением,
Георгий.

P.S. Привет Сергею (Pavs)

[MironovI]

Я для себя уяснил одну весчь - конкурентная разработка это не тема - если я буду заниматься склеиванием разработок то буду тратить на это львиную долю своего времени - проще отдельного человека взять в штат.. кроме того ничего автоматического на эту тему еще не придумано хоть вконец обчитайся FM..

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

В аксе есть штатный механизм блокировки объектов - это когда все работают в одной разработческой базе, а вот при удаленной разработке и был придуман этот файлец с блокированными объектами.. Необязательность - главная проблема, но при большом желании конечно можно написать автоматическую блокировку объектов с синхронизацией через тот же FTP шный файл, поковырявшись в dict классах и работой с ftp через аксу.. Обидно что такого механизма нет в стандартной аксе, а писать его.. ну.. только не в качестве факультатива, мож контору убедю когда-нить выделить меня под такой отвлеченный проект

[MironovI]

И да - забыл про человеческий вариант Терминальный сервак для всех удаленных разработчиков и тестеров - проще и логичнее некуда. Но тут рогами и копытами может встать СБ клиента, я для борьбы с ними уже писал шифрование базы даж, хе Вот чтобы таких проблем не было - надо на этапе заключения договора оговаривать необходимость развертывания этого самого терминала.. На отсутствие технической возможности, я думаю, конторе, которая покупает Аксапту жаловаться стыдно

[Anais]

MironovI, а тестируют свежеразработанные и еще не принятые модификации ваши консультанты/пользователи на каком приложении(ях)?

[MironovI]

Цитата:

Изначально опубликовано Anais
MironovI, а тестируют свежеразработанные и еще не принятые модификации ваши консультанты/пользователи на каком приложении(ях)?

На тестовой базе, которую периодически поднимают из рабочей. Вообще классическая методология такова:
Три базы - Разработческая, Тестовая, Рабочая. Но у нас она выглядит так - Тестовая - куда заливаются присланные проекты - она же разработческая для прогеров которые сидят у клиента.. и собственно рабочая куда все это попадает после тестирования. А у удаленных прогеров свои копии баз и прикладух, прикладухи они синхронизят очерез ftp, свежий бэкап в архиве тоже периодически выкладывается на ftp либо едет с оказией..

[Anais]

А на тестовую кто поднимает? И как тестируют консультанты в офисе? Или они в офисе вообще не бывают

[Anais]

Mazzy, вы меня конечно, извините, но при чем тут слои патчей и old? Разве они дают возможность автоматически склеить форму, пришедшую с исправлениями одновренменно от двух разработчиков, да еще и выполненную ими на устаревшей версии приложения? Все упрется в "Use the compare tool to spot the differences, and take the needed action." Может, я чего-то упускаю, но как только закончится _сравнение_ сливать все равно придется _руками_.
Речь шла не о том, как грамотно сравнить и слить. А как в условиях слияния, данным нам Axapta, построить процесс разработки и тестирования с наименьшими потерями (а)исправлений и (б)времени на весь процесс разработки (начиная с написания Заявки). Когда разработчиков больше, чем 1. Лучше, когда среди них разработчиков, "впервые увидевших систему", больше, чем 1.

ЗЫ
Я действительно хочу понять. Может, я чего-то упускаю? Может, есть какой-то чудесный способ красиво обойти все эти пороги... А мы, глупые, все сравниваем по 33 раза и потом сливаем.

ЗЗЫ
Способ "не программируйте" я уже знаю. Не всегда удается...

[MironovI]

Цитата:

Изначально опубликовано Anais
Mazzy, вы меня конечно, извините, но при чем тут слои патчей и old? ..

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

[Anais]

Нда, если безвылазно сидять у клиента - тест один и упрощенка... MironovI, спасибо большое за ответы.

[korolf76]

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

[belugin]

Собственно, у меня такие мысли: можно либо снизить вероятность конфликтов, либо использовать некий инструмент для их разрешения.

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

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

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

Инструменты для разрешения конфликтов есть и довольно давно используются (в системах контроля версий), но они не интегрированы с аксаптой. Можно интеграцию VSS портировать на что-нибудь, хорошо поддерживаюшее ветки и работающее через http (например subversion), это перенесет задачу разрешения конфликтов на уровене xpoшников (хотя помощь инструментария, навреное, будет существенная). Еще немного непонятно, каким образом заставить разработчиков коммитить изменения как можно чаще -- я, например, не нашел способа сесть на событие "изменение компонента" или не давать изменять не взятые на исправление компоненты

[Anais]

Делать надстройки умно с точки зрения переноса модификаций на следующие SP и HF от Майкрософт. Для решения, тоже, наверное не дурно. Из тех же соображений. Но это сколько ж продумать надо. Особенно, если учесть, что пользователи все равно потом захотят все видеть в одной базовой форме накладные расходы - да...
А в рамках одного проекта под одного клиента - зачем?

VSS хорош, когда все в одной точке географически. Он дает сохранять версии и дает возможность откатиться назад на какую-то точку. Но не даст решения задачи пересечения объекта при разработке разными разработчиками в последовательно-параллельном режиме. При поднятии модификации в рабочее приложение нужно будет либо резать куски от "другой" модификации либо поднимать их обе одновременно.

"я, например, не нашел способа сесть на событие "изменение компонента" или не давать изменять не взятые на исправление компоненты" Это ужасно. Я надеялась, есть возможности. То есть я пока надеюсь

belugin, вы разрабатываете все в офисе или на клиенте? А тестирование где и как проводите?