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

[Anais]

korolf76, коменнтам - да Формы и репорты - проблема. А еще любые обекты кроме кода (например, поля таблиц, EDT и др.). Есть еще такая фишка как файл описания модификации. По нему мало-мальски можно ориентироваться потом кто что и когда сделал.
"причем некоторые бывают тиражируемые, некоторые под конкретного клиента" - это все в одном приложении разработки? А тестировать потом как? А в билд заливать...

[belugin]

Цитата:

Изначально опубликовано Anais
А в рамках одного проекта под одного клиента - зачем?

Если много однотипных модификаций - может быть легче их разрабатывать.

Цитата:

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

VSS - это не самая совершенная система контроля версия есть еще subversion, gnu arch, cvs и многое еще. см. доки по ним по ключевым словам ветки (branches) слияние (merge).

Цитата:

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

Сейчас в офисе, раньше на клиенте, но тогда большая часть команды тоже была на клиенте -- в полный рост проблема не вставала.

[rumpleteazer]

Размышляя давно над поднятым вопросом, я думал о возможности использования Clear Case для управления конфигурацией системы. Все объекты хранить в Clear Case'е в виде XPO, а рабочее приложение осуществлять через сборку из репозитария Clear Case (возможно и вероятно придется написать небольшую интеграцию с Аксптой, для автоматической сборки). Все разработчики получают текущии версии объектов из Clear Case. Возникает вопрос совместной работы нескольких человек с одним и тем же объектом, но тут прав тот кто первым забрал объект для изменений, остальные пока могут работать с копией, но после того, как первый человек закончит разработку будут вынуждены точно так же забирать объект для изменения и мерджить свои модификации в измененную версию объекта. В Clear Case я глубоко не копался, поэтому это все на уровне размышлений и идей.


To Mazzy: переодически встречаю в системе old-слои, но не доходят руки разузнать что это и откуда они берутся. Не проясните вопрос или надо RTFM?

[belugin]

Посмотрите
http://erpkb.com/Axapta/KakCravnit'DvaPrilozhenija

[Anais]

Вот какие еще вопросы у меня родились.
Кто-нибудь пробовал схемы КРОМЕ "Общий программинг" - "Общий тест" - "Рабочее приложение"?
Кто-нибудь пробовал схемы КРОМЕ "работа над одной модификацией в рамках одного проекта Axapta и импортирования этого проекта (xpo) сначала в Тест а потом в Рабочее"?

Если да, то отказались ли Вы от них в итоге? Почему?

[Anais]

Цитата:

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

А всего сколько было разработчиков?

[belugin]

3-4

[Anais]

Хм. У меня бывало до 7-8. Если учесть, что одни из них (как правило, свои и субподряд) работают быстро, а другие (как правило, те, что "от клиента") мучают любую мелочь неделями - то проблема не просто в полный рост вставала. Она уже задолбала торчком торчать

[mazzy]

Цитата:

Изначально опубликовано Anais
Mazzy, вы меня конечно, извините, но при чем тут слои патчей и old? Разве они дают возможность автоматически склеить форму, пришедшую с исправлениями одновренменно от двух разработчиков, да еще и выполненную ими на устаревшей версии приложения?

А чего это, разрешите поинтересоваться, руководитель проекта допускает одновременную разработку формы?
Еще раз: вы читали Best Practice, раздел Design guidelines for cost-efficient upgrades?
Что там насчет форм говорится?

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

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

[mazzy]

Цитата:

Изначально опубликовано rumpleteazer
To Mazzy: переодически встречаю в системе old-слои, но не доходят руки разузнать что это и откуда они берутся. Не проясните вопрос или надо RTFM?

Ссылку дал Максим Белугин здесь
http://www.axforum.info/forums/showt...0510#post70510

[rumpleteazer]

To belugin :
Спасибо за информацию по old-слоям.

To Mazzy:
Спасибо, что сказали куда посмотреть, а то я сначала стормозил и не понял, что ответ Максима Белугина был мне

[Anais]

Цитата:

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

Большая красная кнопка - мечта А хочу найти оптимальный способ работы . Или несколько оптимальных - применимых к разным случаям жизни.

[korolf76]

Для Anais:

"korolf76, коменнтам - да Формы и репорты - проблема. А еще любые обекты кроме кода (например, поля таблиц, EDT и др.)."
- в случае таблиц написали мы утилитку которая все изменения в лог записывает.
Получается в логе история всех изменений (поля, методы, связи, индексы...).
Аналогично можно для дизайно, но несколько сложней и руки не доходят.
Потом на основании лога и заполняется файл модификации автоматически.

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

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

[Anais]

2 korolf76.
У нас заполняют полно, потому что это проверяется третьим человеком (мною ) Но гиморно это, конечно - по себе знаю. А может, дадите код утилитки? Если доработаем до дизайна - будет Вам алыверды

[korolf76]

пока дать не могу.
но принцип такой:
после завершения модификации, запускается утилита,
которая поднимает предыдущее состояние из Log, и с помощью TreeNode
сравнивает с текущим. Изменения дописываются в Log.

[belugin]

korolf76, а как оно узнает, что что-то было изменено?

[MironovI]

Цитата:

Изначально опубликовано mazzy

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

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

[belugin]

Цитата:

Изначально опубликовано mazzy

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

А мне кажется, что хотят получить инструменты для сведения веток, хотя бы на уровне старой доброй CVS

[korolf76]

Сравниваю состояние в логе с текущим состоянием.
Например, создали таблицу, добавили два поля,
в логе - инфа о полях. Добавляем третье,
запускаем утилиту, она с помощью TreeNode определяет, что
в таблице три поля, причем два в логе уже есть, а одного нет.
Третье и добавляется в лог. Примерно, в общих чертах, так.

[Anais]

Вообще-то хочу в имеющихся условиях получить максимально защищенную от ошибок _схему работы_.
Все, что используется, не лишено недостатков. А то то поле при слиянии потеряется. То недоопишут что-нить разработчики, так что при подъеме срежешь что-нить совсем НЕ лишнее. То забудут объект в проект подложить и на формах/таблицых кривули появляются. То перетрут своими модификациями в тесте чужие разработки (у нас зачастую разработчики в разных местах и субподрядчики имеются). Да мало ли чего еще... Пробовали локальный программинг/тест, общий пробовали и не раз. Один раз после исполнения огромнейшего пула разработки просто объявили Тест Рабочим приложением (на этапе глубокой разработки, ессно), проверили все и приняли as is, ничего никуда не поднимая. Во всех методах есть свои недостатки и преимущества. Ищу оптимальный, хочу знать мнение общества.

"инструменты для сведения веток на уровне" штука, конечно, хорошая. БольшУю часть проблемы можно ими снять. Но уж больно много в Axapta _объектов_ (не кода). И слияние, как ни крути, ИМХО, все равно гиморным окажется.