Обновление рабочего приложения: проектами или слоем?

[Logger]

****** Выделено из темы Изменение идентификаторов(id) полей ******

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

[ice]

Quote:

Originally Posted by Logger

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

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

[raz]

Quote:

Originally Posted by Logger

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

Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

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

[Logger]

Quote:

Originally Posted by raz

Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

Понятно. А расскажите поподробнее что может быть плохого ?

Quote:

Originally Posted by raz

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

Спасибо.
Это все правильно. Но если проектов 15, даже не очень больших, то по-моему проще слоем. Не забывайте про ограничение по времени простоя базы. Лучше в таком случае сделать как ice предложил. Правда все равно может потребоваться иногда лечить идентификаторы.

[raz]

Quote:

Originally Posted by Logger

Понятно. А расскажите поподробнее что может быть плохого ?.

После накатки приложения нужно синхронизировать, вот тут и вылазят проблемы с разными идентификаторами. Можно ненароком потерять данные в несовпадающих полях.

Quote:

Originally Posted by Logger

Это все правильно. Но если проектов 15, даже не очень больших, то по-моему проще слоем. Не забывайте про ограничение по времени простоя базы. Лучше в таком случае сделать как ice предложил. Правда все равно может потребоваться иногда лечить идентификаторы.

Тут согласен. Делаем текущую копию реального приложения, переносим на нее попроектно при помощи *.xpo новые наработки (с инкрементной компиляцией). Полученное приложение накатываем вместо рабочего. Синхронизируем.

[Bishop]

Quote:

Originally Posted by Logger

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

Quote:

Originally Posted by raz

Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

Очень смелое утверждение!

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

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

[oip]

Quote:

Originally Posted by Bishop

В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки

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

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

[Logger]

Quote:

Originally Posted by oip

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

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

Согласен.

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

[Dron AKA andy]

Quote:

Originally Posted by Bishop

В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки.

Выскажу свое мнение. Использовал оба способа, в каждом есть свои + и -, сейчас остановился на переносе проектами с идентификаторами из тестового в рабочее (с разработческого на тестовое - тоже проектами и обязательно БЕЗ идентификаторов).
По пунктам:

Quote:

Originally Posted by Bishop

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

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

Quote:

Originally Posted by Bishop

3) Как обновить проектом удаленную (переименованную) в разработке форму/таблицу/класс/...?

Интересно (сам не пробовал - не довелось), как отреагируют данные при переносе слоем таблицы с измененным названием или переименованным полем? Перенос проектами задачу сохранения данных в этом случае не решает, приходится предварительно ручками переименовывать...

Quote:

Originally Posted by Bishop

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

Тут практикую, конечно, копирование слоя или вообще полное копирование приложения из основного рабочего АОС (на который производится подъем проектов).

Quote:

Originally Posted by Bishop

5) При различиях в идентификаторах таблиц и полей невозможно (в общем случае) корректно подменить данные приложения разработки из рабочей базы при помощи резервного копирования и восстановления (а такая необходимость иногда возникает).

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

Quote:

Originally Posted by Bishop

6) В "стандарте" нет инструментов, позволяющих проверять, что проект включает все "затронутые" объекты, и это "проверяется" лишь на этапе импорта.

Это да, но тут, помимо элементарной аккуратности, помогает обязательный этап тестирования в отдельном тестовом приложении. Может, то "забытое" и не нужно?

По мне, основной минус в переносе слоем - уже упоминавшаяся вероятность поднять на рабочую неоттестированные модификации. При достаточно большом объеме доработок между отдельными подъемами эта вероятность стремится к 100%, что чревато. Хотя, подъем проектами лишь снижает эту самую вероятность, т.к. остается вариант пересечения модификаций по объекту...
Вариант

Quote:

Originally Posted by Logger

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

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

[lev]

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

[gl00mie]

Quote:

Originally Posted by Dron AKA andy

Quote:

Originally Posted by Logger

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

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

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

[Dron AKA andy]

Согласен, возможность включать/отключать некую функциональность очень удобна, а иногда просто необходима. Но чтоб КАЖДУЮ модификацию со своим собственным ключом... Не думаю...
Хотя это мысли из той серии: "На вкус не пробовал, но читал - не понравилось"

[gl00mie]

Quote:

Originally Posted by Dron AKA andy

Согласен, возможность включать/отключать некую функциональность очень удобна, а иногда просто необходима. Но чтоб КАЖДУЮ модификацию со своим собственным ключом...

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

return isConfigurationKeyEnabled(configurationkeynum(AlwaysOffInLiveDB));

на

return true;

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

[Ivanhoe]

Мне так представляется, что перенос слоя - частный случай переноса проектами, просто вместо создания проекта со всеми изменениями на слое переносится готовый файл.

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

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

У каждого регламента есть свои плюсы и минусы, зависит от ресурсов: как исполнителей, так и выделенного на проект времени. Аккуратность же нужна и там, и там.

[petr]

Quote:

Originally Posted by gl00mie

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

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

[glibs]

Я, конечно, понимаю, что сейчас еще достаточно много пользователей 2.5. Не говоря уже про 3.0.

Но что вы будете делать в 6.0? По слухам там код приложения затолкают в БД, как раньше было в Навижине/Аттейне (да и сейчас, наверное, так и осталось).

[Logger]

Quote:

Originally Posted by glibs

Но что вы будете делать в 6.0? По слухам там код приложения затолкают в БД, как раньше было в Навижине/Аттейне (да и сейчас, наверное, так и осталось).

Да то же самое. Судя по описанию останется возможность выгружать слои в aod-подобные файлы и из них импортировать.

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

Кстати, сколько сейчас в России проектов на Ax2009 ? Я пока знаю только один.

[gl00mie]

Quote:

Originally Posted by glibs

что вы будете делать в 6.0? По слухам там код приложения затолкают в БД

А зачем гадать? Посмотрим, что там по слухам будет с развертыванием приложения (в вольном переводе):

Quote:

Originally Posted by 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) в БД. Остается лишь надеяться, что утилиту экспорта/импорта сделают достаточно "прямой", чтобы разруливать возможные конфликты.