Кросс-слойная разработка

[OliaM]

Насколько по вашему опыту актуальна разработка (модификации) в нескольких слоях одновременно? Или вы придерживаетесь разработки в одном слое (к примеру USR)?
Если в нескольких - какие слои предпочтительны для ведения разработки? Спасибо заранее.

[George Nordic]

Мы ведем разработку в usr слое. Потом поднимаем на тестовую базу на cus слой. Потом - на боевую. В таком случае, можно накатить на usr слой модификацию и сравенить с cus.

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

[OliaM]

Георгий, получается, что все остальные (нижележащие) слои можно не трогать?

А вы пробовали работать со слоем BUS? По идее, add-ons должны размещаться в этом слое.

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

[raz]

Хочется заметить, что для разработки в этих слоях надо иметь соответсвующие лицензии, которые кажется доступны только партнерам. Если мы говорим о законном использовании. Ну а для партнеров вроде как есть документы, в котрых написано как вести такую разработку.

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

[Михаил Андреев]

Цитата:

Изначально опубликовано raz
Для конечных же пользоваетелй доступны только два слоя USR и USP.

Не только. Ещё доступны слои CUS и CUP для тех, кто выкупил лицензию "X++ - Source Code". Только на эти слои вход через пароль.

[RVS]

Недавно пробовал подобное (для разделения "своих" и "чужих" модификаций). Типа, наши разработчики - на VAR, разработчики клиента - на CUS, пользователи (и прочие консультанты ) - на USR.

Изначально идея была - разделение ответственности, во-первых, и возможность откатить (просто - снести) изменения, ненароком сделанные пользователем - во-вторых.

Результат печален... По крайней мере, для форм выполняется правило: если форма модифицирована на слое USR, то изменения, сделанные после этого с CUS (или даже VAR) все равно попадают на USR...

В результате от идеи пришлось отказаться. Как ни печально это было.

Axapta 3.0 CIS SP3, трехзвенка, тонкие клиенты.

2 RAZ :

Цитата:

Ну а для партнеров вроде как есть документы, в котрых написано как вести такую разработку

Ни разу не видел. Хотя работаю у партнера. Можно поподробнее, что за документы?

[Михаил Андреев]

2 RVS.

М-дааа. "Учите матчасть".
Слои очень полезны, если уметь ими пользоваться. При установке проекта на более низкий слой неизбежно сравнение слоёв изменённых объектов. А если программист с кривыми руками, то и глобальная компиляция может потребоваться. Увы. Но слои здесь ни при чём.

[RVS]

Цитата:

"учите матчасть"

Да знаю я ее... И не понаслышке

Цитата:

При установке проекта на более низкий слой неизбежно сравнение слоёв изменённых объектов.

Святая истина. Только речь не о переносе проектов, а об одновременной (параллельной, то есть) разработке в одном Application программистами, работающими на разных слоях. Далее - см. выше.

[raz]

Цитата:

Не только. Ещё доступны слои CUS и CUP для тех, кто выкупил лицензию "X++ - Source Code". Только на эти слои вход через пароль.

Что то я не припомню, что бы вместе "X++ - Source Code" шли пароли доступа к редактированию CUS и CUP. Хотя может это нам не присылали.

[BOAL]

для разработки на двух слоях одновременно нужно иметь клоны приложений, одно мастер (токо КАП слой), другое сборка (КАП + ЮСР) и тока так.
Разработка КАП ведется токо на мастере и передается в сборку целиком. А там поднимается на ЮСР, если пересечения были.

Этого можно не делать, если пересечений минимум или нет вовсе. Иначе - про одно приложение можно забыть...

У нас три слоя счас... на каждое приложения куча ярлыков-входов. Разработка очень тормозиться, особенно обновление боевой версии.
Если Вам это для "пальцы погнуть", то не парьтесь - делайте все в одном слое, потом быстрее выделить все нужное (тк есть проблема сброса ИД у полей и таблиц - при смене слоя).
Если обойтись одним слоем нельзя (выделение сквозной бизнес логики, хитрый суппорт версий и тп), то привыкайте работать по методе, быть аккуратными и терпеливыми.

[komar]

Цитата:

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

Что то я не припомню, что бы вместе "X++ - Source Code" шли пароли доступа к редактированию CUS и CUP. Хотя может это нам не присылали.

Разве нужен пароль?


to BOAL: мне как-то знающие люди говорили, что экспорт-импорт объектов со значениями идентификаторов побеждает проблему сброса оных.

[Vadik]

2 all: см. AX-300-TIP-046-v01.00-RU.pdf

[Михаил Андреев]

2 BOAL:

А зачем вести разработку сразу на ДВУХ слоях? Иметь лишние проблемы с синхронизацией объектов, изменённых на разных слоях?

2 vadik:
Я бы лучше рекомендовал Modification transfer.chm. Очень хорошо описана процедура апгрейда и нюансы интеграции разных объектов.

2 komar:

Цитата:

to BOAL: мне как-то знающие люди говорили, что экспорт-импорт объектов со значениями идентификаторов побеждает проблему сброса оных.

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

[BOAL]

Цитата:

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

to BOAL: мне как-то знающие люди говорили, что экспорт-импорт объектов со значениями идентификаторов побеждает проблему сброса оных.

К сожалению эти люди видать никогда не делали сборку (Кас-Юср) сами

Да это будет работать какое-то время...
но иметь в КАС слое номера 50001 из ЮСР черевато... потом .аод файлик никуда не подсунуть.

Михаил Андреев совершенно прав.
Вести такую разработку тяжко и в большинстве случаев незачем.
Но в нашем случае приходится

"Мыши плакали, кололись, но продолжали грызть кактус"

[DTD]

Цитата:

Сообщение от Михаил Андреев

Я бы лучше рекомендовал Modification transfer.chm.

Пoдскажите где этот файл лежит на partnersource, а заодно и AX-300-TIP-046-v01.00, нe могу найти