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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.05.2009, 09:00   #1  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Обновление рабочего приложения: проектами или слоем?
****** Выделено из темы Изменение идентификаторов(id) полей ******

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

Последний раз редактировалось Dron AKA andy; 17.06.2009 в 10:10.
Старый 21.05.2009, 09:22   #2  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,688 / 405 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от Logger Посмотреть сообщение
Это до тех пор пока вы проектами все обновляете. А когда объем доработок большой, а время простоя базы не более часа в неделю - то приходится слоем обновлять - для таких случаев актуально чтобы id-ники выделялись в одном месте и не менялись.
для таких целей заводят еще одно приложение (копия рабочего) на который накатывают проектами, а потом его слой копируют (в определенное время) на рабочее
Старый 21.05.2009, 11:05   #3  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,490 / 1060 (38) ++++++++
Регистрация: 22.07.2003
Адрес: МО
Цитата:
Сообщение от Logger Посмотреть сообщение
Это до тех пор пока вы проектами все обновляете. А когда объем доработок большой, а время простоя базы не более часа в неделю - то приходится слоем обновлять - для таких случаев актуально чтобы id-ники выделялись в одном месте и не менялись.
Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

ЗЫ. Даже очень большой проект можно накатить через *.xpo
Есть ли у кого-нибудь такая штучечка?

Последний раз редактировалось raz; 21.05.2009 в 11:31.
Старый 21.05.2009, 12:03   #4  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от raz Посмотреть сообщение
Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.
Понятно. А расскажите поподробнее что может быть плохого ?

Цитата:
Сообщение от raz Посмотреть сообщение
ЗЫ. Даже очень большой проект можно накатить через *.xpo
Есть ли у кого-нибудь такая штучечка?
Спасибо.
Это все правильно. Но если проектов 15, даже не очень больших, то по-моему проще слоем. Не забывайте про ограничение по времени простоя базы. Лучше в таком случае сделать как ice предложил. Правда все равно может потребоваться иногда лечить идентификаторы.
Старый 21.05.2009, 13:30   #5  
raz is offline
raz
NavAx
Аватар для raz
NavAx Club
Лучший по профессии 2014
Лучший по профессии 2009
 
1,490 / 1060 (38) ++++++++
Регистрация: 22.07.2003
Адрес: МО
Цитата:
Сообщение от Logger Посмотреть сообщение
Понятно. А расскажите поподробнее что может быть плохого ?.
После накатки приложения нужно синхронизировать, вот тут и вылазят проблемы с разными идентификаторами. Можно ненароком потерять данные в несовпадающих полях.

Цитата:
Сообщение от Logger Посмотреть сообщение
Это все правильно. Но если проектов 15, даже не очень больших, то по-моему проще слоем. Не забывайте про ограничение по времени простоя базы. Лучше в таком случае сделать как ice предложил. Правда все равно может потребоваться иногда лечить идентификаторы.
Тут согласен. Делаем текущую копию реального приложения, переносим на нее попроектно при помощи *.xpo новые наработки (с инкрементной компиляцией). Полученное приложение накатываем вместо рабочего. Синхронизируем.
Старый 16.06.2009, 15:17   #6  
Bishop is offline
Bishop
Участник
 
89 / 60 (3) ++++
Регистрация: 12.08.2004
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
Это до тех пор пока вы проектами все обновляете. А когда объем доработок большой, а время простоя базы не более часа в неделю -
то приходится слоем обновлять - для таких случаев актуально чтобы id-ники выделялись в одном месте и не менялись.
Цитата:
Сообщение от raz Посмотреть сообщение
Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.
Очень смелое утверждение!

У меня абсолютно противоположное мнение. В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки. А если все же дело доходит до проектов (в крайних случаях), то экспорт/импорт только с идентификаторами.
И вот почему:
1) Не все клиенты покупают лицензии на разработку, и опция "инкрементная компиляция" у них отсутствует.
2) Не у всех клиентов есть лицензии на разработку в тех слоях, в которых ведет разработку партнер. Если у вас разработка в VAR, а в рабочем приложении
все "лежит" на CUS или USR - это, как минимум, выглядит криво.
3) Как обновить проектом удаленную (переименованную) в разработке форму/таблицу/класс/...?
4) Если рабочее приложение развернуто на нескольких АОСах (да еще и с балансировщиком), обновление проектом может привести как раз к ОЧЕНЬ большому геморрою (особенно при наличии новых таблиц/полей, как показала практика).
5) При различиях в идентификаторах таблиц и полей невозможно (в общем случае) корректно подменить данные приложения разработки из рабочей базы при помощи резервного копирования и восстановления (а такая необходимость иногда возникает).
6) В "стандарте" нет инструментов, позволяющих проверять, что проект включает все "затронутые" объекты, и это "проверяется" лишь на этапе импорта.

В добавок к этому, обновление проектами ухудшает качество разработки, т.к. всегда можно "быстренько все подправить", если что...
За это сообщение автора поблагодарили: Dron AKA andy (2).
Старый 16.06.2009, 15:36   #7  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1409 (52) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Цитата:
Сообщение от Bishop Посмотреть сообщение
В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки
Только поправлю, что в общем случае - не из приложения разработки, а из тестового приложения. А так я тоже считаю, что рабочее приложение должно обновляться слоем целиком. Правда тут тоже возникают проблемы с тем, что для того, чтобы перенести какую-либо не очень большую модификацию по хорошему требуется, чтобы и все (ну или по-крайней мере критически важные) другие модификации к данному моменту уже были протестирована. А если это невозможно по каким-либо причинам (скажем, внедрение еще в самом разгаре, но какая-то часть функционала уже работает), то начинаются танцы с бубнами и дополнительными приложениями.

По-моему, на эту тему уже был опрос, но что-то я его не нашел.
__________________
С уважением,
Олег.
Старый 16.06.2009, 19:22   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от oip Посмотреть сообщение
Только поправлю, что в общем случае - не из приложения разработки, а из тестового приложения. А так я тоже считаю, что рабочее приложение должно обновляться слоем целиком. Правда тут тоже возникают проблемы с тем, что для того, чтобы перенести какую-либо не очень большую модификацию по хорошему требуется, чтобы и все (ну или по-крайней мере критически важные) другие модификации к данному моменту уже были протестирована. А если это невозможно по каким-либо причинам (скажем, внедрение еще в самом разгаре, но какая-то часть функционала уже работает), то начинаются танцы с бубнами и дополнительными приложениями.

По-моему, на эту тему уже был опрос, но что-то я его не нашел.
Согласен.

Мы для этой цели попробовали применить схему похожую на то как в ax3.0 sp5 объединили восточно-европейский функционал - там везде понатыкана проверка что если конфигурационный ключ для такой-то страны включен, то выполнять определенный код иначе пропускать. Применив такую схему и при условии аккуратного кодирования, можно переносить слой с не до конца оттестированными модифами.
За это сообщение автора поблагодарили: Dron AKA andy (2).
Старый 17.06.2009, 10:57   #9  
Dron AKA andy is offline
Dron AKA andy
Moderator
 
944 / 253 (10) ++++++
Регистрация: 27.03.2002
Адрес: Москва
Цитата:
Сообщение от Bishop Посмотреть сообщение
В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки.
Выскажу свое мнение. Использовал оба способа, в каждом есть свои + и -, сейчас остановился на переносе проектами с идентификаторами из тестового в рабочее (с разработческого на тестовое - тоже проектами и обязательно БЕЗ идентификаторов).
По пунктам:

Цитата:
Сообщение от Bishop Посмотреть сообщение
1) Не все клиенты покупают лицензии на разработку, и опция "инкрементная компиляция" у них отсутствует.
2) Не у всех клиентов есть лицензии на разработку в тех слоях, в которых ведет разработку партнер. Если у вас разработка в VAR, а в рабочем приложении
все "лежит" на CUS или USR - это, как минимум, выглядит криво.
Важность этих пунктов оценить не могу, т.к. то немногое кол-во клиентов, с кем мне довелось поработать (внутренние проекты), обязательно имели лицензию на разработку. Велась разработка в USR.

Цитата:
Сообщение от Bishop Посмотреть сообщение
3) Как обновить проектом удаленную (переименованную) в разработке форму/таблицу/класс/...?
Интересно (сам не пробовал - не довелось), как отреагируют данные при переносе слоем таблицы с измененным названием или переименованным полем? Перенос проектами задачу сохранения данных в этом случае не решает, приходится предварительно ручками переименовывать...

Цитата:
Сообщение от Bishop Посмотреть сообщение
4) Если рабочее приложение развернуто на нескольких АОСах (да еще и с балансировщиком), обновление проектом может привести как раз к ОЧЕНЬ большому геморрою (особенно при наличии новых таблиц/полей, как показала практика).
Тут практикую, конечно, копирование слоя или вообще полное копирование приложения из основного рабочего АОС (на который производится подъем проектов).

Цитата:
Сообщение от Bishop Посмотреть сообщение
5) При различиях в идентификаторах таблиц и полей невозможно (в общем случае) корректно подменить данные приложения разработки из рабочей базы при помощи резервного копирования и восстановления (а такая необходимость иногда возникает).
Это довольно редко необходимая (при наличии тестовой базы) операция, и решается очисткой SqlDictionary и запуском Проверки/Синхронизации, подробнее в Изменение идентификаторов(id) полей

Цитата:
Сообщение от Bishop Посмотреть сообщение
6) В "стандарте" нет инструментов, позволяющих проверять, что проект включает все "затронутые" объекты, и это "проверяется" лишь на этапе импорта.
Это да, но тут, помимо элементарной аккуратности, помогает обязательный этап тестирования в отдельном тестовом приложении. Может, то "забытое" и не нужно?

По мне, основной минус в переносе слоем - уже упоминавшаяся вероятность поднять на рабочую неоттестированные модификации. При достаточно большом объеме доработок между отдельными подъемами эта вероятность стремится к 100%, что чревато. Хотя, подъем проектами лишь снижает эту самую вероятность, т.к. остается вариант пересечения модификаций по объекту...
Вариант
Цитата:
Сообщение от Logger Посмотреть сообщение
Мы для этой цели попробовали применить схему похожую на то как в ax3.0 sp5 объединили восточно-европейский функционал - там везде понатыкана проверка что если конфигурационный ключ для такой-то страны включен, то выполнять определенный код иначе пропускать.
не пробовал, но для решения проблемы случайного переноса мелких модификаций это, извините, жесть!
__________________
Андрей.

Последний раз редактировалось Dron AKA andy; 17.06.2009 в 11:00.
За это сообщение автора поблагодарили: Logger (5).
Старый 17.06.2009, 11:05   #10  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Мы переносим проектами...
Потому что, на мой взгляд, в рамках одного проекта, проще отследить все не нужные утечки из других не оттестированных проектов. Элементарно при переносе выполнять внимательное сравнение и всё. А вот если переносить слоями, то это уже лотерея
Переносить с тестового нужно с IDшниками, а между разработкой и тестовой соответствие не важно.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 17.06.2009, 11:20   #11  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Dron AKA andy Посмотреть сообщение
Цитата:
Сообщение от Logger Посмотреть сообщение
Мы для этой цели попробовали применить схему похожую на то как в ax3.0 sp5 объединили восточно-европейский функционал - там везде понатыкана проверка что если конфигурационный ключ для такой-то страны включен, то выполнять определенный код иначе пропускать.
для решения проблемы случайного переноса мелких модификаций это, извините, жесть!
А что такое мелкие модификации? Изменение нескольких свойств контролов на форме? Исправление сообщения, выводимого при ошибке?
Если изначально задаться целью делать модификации отключаемыми (что, конечно, привносит дополнительные "накладные расходы", а в случае изменения дизайна форм/отчетов и вовсе затруднительно, но такое, к счастью, бывает нужно не так часто), то всё, как говорится, реально И в любом случае обновления слоем ведь делаются не каждый день - это ответственный процесс, который включает в себя определенную подготовку, вплоть до сравнения нового слоя и его прежней версии на рабочем приложении, чтобы случайно не перенести что-то ненужное или неотключаемое. Перед этим разработчик, который делал те или иные доработки, проверяет, корректно ли они отключаются, чтобы изменения в функционале не заработали раньше времени. К тому же изредка, но бывает необходимо по тем или иным причинам отключить модификацию на рабочем приложении - в этом случае простая возможность ее отключения вместо необходимости откатывать все изменения оказывается очень полезной.
Кроме того, бывают ситуации, когда одно приложение используется в различных филиалах компании со своей спецификой ведения бизнеса, своими, может, печатными формами для тех или иных документов, etc. В этом случае использование тех же конфигурационных ключей (к примеру, специфичных для того или иного филиала) с целью управления тем, какой функционал должен работать, а какой - нет, как нельзя лучше решает эту проблему.
За это сообщение автора поблагодарили: Dron AKA andy (2).
Старый 17.06.2009, 12:16   #12  
Dron AKA andy is offline
Dron AKA andy
Moderator
 
944 / 253 (10) ++++++
Регистрация: 27.03.2002
Адрес: Москва
Согласен, возможность включать/отключать некую функциональность очень удобна, а иногда просто необходима. Но чтоб КАЖДУЮ модификацию со своим собственным ключом... Не думаю...
Хотя это мысли из той серии: "На вкус не пробовал, но читал - не понравилось"
__________________
Андрей.
Старый 17.06.2009, 12:31   #13  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Dron AKA andy Посмотреть сообщение
Согласен, возможность включать/отключать некую функциональность очень удобна, а иногда просто необходима. Но чтоб КАЖДУЮ модификацию со своим собственным ключом...
Во-первых, можно и не на каждую - это уже зависит от характера модификации: если она существенно меняет бизнес-логику, то лучше сразу предусмотреть "пути отступления". Во-вторых, никто не говорит о своем собственном ключе на каждую модифу - так никаких идентификаторов объектов не хватит (до перехода на AX 6, во всяком случае ). Просто заводится конф.ключ, который включен в разработческой и тестовой базе и заведомо выключен (всегда) в рабочей, делаются где-нить статические методы на каждую отключаемую модифу, которые изначально возвращают признак того, включен ли этот конф.ключ, и уже эти методы дергаются в коде модификаций. Далее, если модифу надо включить, то код метода меняется с
X++:
return isConfigurationKeyEnabled(configurationkeynum(AlwaysOffInLiveDB));
на
X++:
return true;
Аналогичным образом модифа при необходимости отключается. При желании можно какую-нить мордочку для этого сваять, чтобы в код не надо было лазить. Опять же, это нужно в основном лишь для "серьезных" модификаций имеющегося функционала - какой-то новый функционал ("сбоку") можно просто закрыть новыми ключами доступа.
Старый 17.06.2009, 13:32   #14  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Мне так представляется, что перенос слоя - частный случай переноса проектами, просто вместо создания проекта со всеми изменениями на слое переносится готовый файл.

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

Если вести "релизы", т.е. напрограммировали, оттестировали, перенесли - то слой.
Если же разработка и тестирование идут параллельно и / или по нескольким несмежным областям - то проекты.

У каждого регламента есть свои плюсы и минусы, зависит от ресурсов: как исполнителей, так и выделенного на проект времени. Аккуратность же нужна и там, и там.
__________________
Ivanhoe as is..
Старый 17.06.2009, 14:39   #15  
petr is offline
petr
Участник
Соотечественники
 
557 / 201 (8) ++++++
Регистрация: 30.05.2005
Адрес: Швейцария
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Кроме того, бывают ситуации, когда одно приложение используется в различных филиалах компании со своей спецификой ведения бизнеса, своими, может, печатными формами для тех или иных документов, etc. В этом случае использование тех же конфигурационных ключей (к примеру, специфичных для того или иного филиала) с целью управления тем, какой функционал должен работать, а какой - нет, как нельзя лучше решает эту проблему.
В этом случае, по-моему, гораздо удобнее использовать галочки в параметрах модулей, а не конфигурац. ключи, т.к. если в будущем разные филиалы будут использовать одно приложение (единый сервер приложения) - от конф. ключей придется отказаться.
Старый 17.06.2009, 21:04   #16  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Я, конечно, понимаю, что сейчас еще достаточно много пользователей 2.5. Не говоря уже про 3.0.

Но что вы будете делать в 6.0? По слухам там код приложения затолкают в БД, как раньше было в Навижине/Аттейне (да и сейчас, наверное, так и осталось).
__________________
С уважением,
glibs®
Старый 17.06.2009, 23:09   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от glibs Посмотреть сообщение
Но что вы будете делать в 6.0? По слухам там код приложения затолкают в БД, как раньше было в Навижине/Аттейне (да и сейчас, наверное, так и осталось).
Да то же самое. Судя по описанию останется возможность выгружать слои в aod-подобные файлы и из них импортировать.

Кроме того до Ax 6.0 еще дожить надо. На Ax2009 народ почти не работает.

Кстати, сколько сейчас в России проектов на Ax2009 ? Я пока знаю только один.
Старый 18.06.2009, 00:12   #18  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от glibs Посмотреть сообщение
что вы будете делать в 6.0? По слухам там код приложения затолкают в БД
А зачем гадать? Посмотрим, что там по слухам будет с развертыванием приложения (в вольном переводе):
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Источник: http://blogs.msdn.com/mfp/archive/20...w-sql-aod.aspx
==============
...Но подождитве, ведь AOD-файлы были не просто базой данных, они также служили средством развертывания приложения - что же придет им на замену? Dynamics AX поддерживает новый формат файлов - файлы axmodel (с одноименным расширением, например "AxSYS.axmodel"). Они являются бинарными и предоставляют те же возможности для развертывания приложения, которые предоставляли AOD-файлы, но при этом они вдвое меньше размером. Используя специальную новую утилиту, вы сможете импортировать/экспортировать файлы axmodel в/из БД SQL. Вы также сможете импортировать AOD-файлы в БД SQL.
Так что в AX6 развертывание слоем также останется одним из возможных подходов - добавится лишь дополнительная операция по импорту содержимого файла приложения (на этот раз уже axmodel, а не AOD) в БД. Остается лишь надеяться, что утилиту экспорта/импорта сделают достаточно "прямой", чтобы разруливать возможные конфликты.
Теги
upgrade, xpo, как правильно, обновление, слой приложения, ax2012

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Методологией разработки, тестирования и формирования рабочего приложения в Axapta Anais DAX: Программирование 41 17.06.2005 17:30
Обновление ... SerAl DAX: Программирование 0 14.04.2005 19:57
Обновление detail-таблицы DreamCreator DAX: Программирование 1 05.04.2005 15:57
Обновление экрана Аксапты во время выполнения приложения ddadream DAX: Программирование 15 29.05.2003 12:53
Обновление существующего приложения до SP5 SSA DAX: Администрирование 16 19.02.2003 18:14
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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