Распределенная разработка

[Goldy]

Здравствуйте дамы и господа !
Ситуация : есть компания внедренец аксапты и есть компания заказчик. Под нужды заказчика дорабатывается функционал аксапты обеими сторронами, но в разных городах и соответственно на разных приложениях. Все доработки надо сводить между собой. Задания будут даваться так чтобы используемые различными сторонами в доработке объекты не пересекались, но все равно есть шанс что они пересекутся.
Вопрос : Как лучше вести разработку на одном слое обеим сторонам или на разных ? И как лучше в итоге срестить между собой эти разработки ? При советах по слоям приводите пожалуйста аргументы ибо ту или иную позицию прийдется как то аргументировать и отстаивать
Заранее спасибо

[mit]

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

[Goldy]

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

[mit]

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

[Goldy]

Просто при разных слоях при ошибке код не потрется и потом при помощи сравнения слоев можно отыскать (хоть и не просто) где что, а вот если слой один то код потрется и тогда труба ! Правда консультанты утверждают что перкрытые в верхних слоях объекты будут вести себя неадекватно так что требуется именно ответ по слоям
спасибо

[db]

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

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

[Goldy]

Понятно что ни слои ни XPO сами не решат все проблемы,(терминалку к сожалению не потянут наши каналы), но при каком способе работы со слоями возникшуюж проблему бкдет решить проще ? спасибо

[mit]

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

[db]

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

при таком раскладе если возникнут какие сомнения по поводу первого файла можно всегда подсмотреть во втором

[Goldy]

Прошу прощения за некоторое непонимаени со своей стороны, но ручной способ это 2 разных слоя или 1 ?

[odr]

У нас разработка ведется так же. Есть команда поддержки на клиенте. Большие доработки заказываем у консультантов. Опыт почти года работы показал, что не существенно в каких слоях ведется разработка (только если при разборе кто виноват). Мы ведем все в USR. А вот сборка - существенный момент. Доработки от консультантов получаем проектом, а потом на месте сравниваем с текущим слоем, ну и тестим потом основательно (все это естественно не на боевой базе). То есть по-сути смотрим и понимаем то, что заливаем в базу. Расхождения мелкого характера поправляем сами, крупные непонятки исправляем совместно на месте. Установка на боевую базу проводится целиком протестированным модифицированным слоем. Ну соответственно, с архивированием старого, работающего слоя. Да, все наши доработки мы храним тоже проектами, так что проблемы потери кода у нас не существует. Если же вы хотите просто вести разработку в двух местах, не контролируя код, попадающий в работающую базу, то где бы вы не вели разработку, у вас будут большие проблемы.

[mit]

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

[George Nordic]

Да, согласен - это дело ведущего разработчика.

На одном проекте, где я принимал участие, дело действительно решалось удаленным доступом. Ребята, сидевшие на терминалке, ругались, конечно, но код писали. Более того, частично они писали на локале, пересылали проекты на терминал, поднимали их на usp слой и сами поднимали на usr.

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

Тема неоднократно обсуждалась, думаю, Вы найдете информацию для размышлений.
И не забывайте про папочку old - mit Вы очень правильно подсказал.

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

[mit]

да, кстати сборщик проекта и возможные потери будут дороже, чем стоит 1 канал. подумайте насколько экономически целесообразна разработка на разных площадках.
ps цыртикс вам поможет!

[Goldy]

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

[Valia]

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

[mit]

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

[Goldy]

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

[db]

Цитата:

Сообщение от George Nordic

И не забывайте про папочку old - mit Вы очень правильно подсказал.

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

Лучше забудьте, или готовьтесь не верить глазам своим

Функции сравнения со старым приложением глючные. Дело в том, что метод TreeNode::AOTgetProperties() возвращает неверную информацию о свойствах элемента старого приложения, если значениями этих свойств являются имена элементов AOT. Например, у Вас в старом приложении есть расширенный тип данных Type1 с идентификатором 50005. И в старом же приложении поле Field1 в некоторой таблице с этим расширенным типом данных. Если теперь запросить через новое приложение методом TreeNode::AOTgetProperties() свойства этого поля в старом приложении, то расширенный тип данных у него будет с именем имеющим идентификатор 50005, но в новом приложении


Ошибка в ядре, поправить самим никак.
Запрос висит в сервисной системе 3 года. Шансов что исправят практически никакик. Хотя попробую сегодня перерегистрировать.

Удачного дня и правильных слоев

[db]

вот пошаговая инструкция к глюку с old слоем
1. создаем edt type1
2. создаем таблицу table1 с полем field1 на основе типа type1
3. выходим из аксапты и копируем все aoi и aod в папку old
4. заходим заново и переименовываем type1 в type111
5. сравниваем table1 и old\table1 - как ни странно НИКАКИХ различий нет (должен быть другой EDT)
6. вспоминаеие все матные слова и забываете про папку old