перенос откомпилированного приложения

[sukhanchik]

Цитата:

Сообщение от Товарищ ♂uatr

Здравствуйте.
В рамках поставок решений осуществляем перенос aod файлов.
При этом aoi удаляем. Запуск АОСов, создание нового aoi файла, занимает время = простой.
Возникает вопрос: практикует ли кто-либо перенос aoi?

В 3.0 / 4.0 пробовали - высокий риск нарваться на кэш в пересеченных объектах (т.е. в тех объектах, которые находятся в новом .aod и в текущем.aod разных слоев).
Но.. собственно - почему простой? Не на рабочую же сразу надо накатывать. Надо ж подготовить приложение, сделать глобальную компиляцию и только после этого уже выкладывать.
Как бы такой подход и в D365FO практикуется - даже если ты сваял свою dll "сбоку" на C# - она сразу на PROD никогда не выкладывается - только через процедуру сборки

[Товарищ ♂uatr]

Это 5-ка.
Подготовка (ГК и тп) к релизу осуществляется на соответствующей среде. Далее aod-файлы "мигрируют" на рабочее приложение.
Понятное дело, что на время проведения релиза запущен только 1-н АОС и доступ у пользователей к системе ограничен. Отсюда и простой.
Сам релиз занимает в районе получаса, где ~20 минут уходит на создание aoi файла.
Исходя из этого, выглядит логичным помимо aod-файлов с подготовительной среды, так же копировать и aoi. На рабочей среде не очень хочется проводить эксперименты по бразильской схеме, поэтому интересует практический опыт, вряд ли только мне такая мысль пришла в голову.
365 давайте вынесем за скобки, это совершенно иной продукт.

[Logger]

Несколько раз за всю практику копировал aoi - вроде работало. Но перед копированием лучше застопить все аосы.
Но обычно их не копировали. На всякий случай давали возможность вторичным данным (индексам) перестроиться заново.
Если мне не изменяет память то aoi строился не дольше 10 минут и это было в 17-м году. С учетом того что мощности железа только выросли, должно стать еще быстрее, так что надо искать где идет потеря скорости.

Цитата:

Сообщение от sukhanchik

В 3.0 / 4.0 пробовали - высокий риск нарваться на кэш в пересеченных объектах (т.е. в тех объектах, которые находятся в новом .aod и в текущем.aod разных слоев).

Мне кажется не должно быть проблемы если копировать все aod файлы. Так нужно делать, так как в них хранится скомпилированный байт код приложения. Поэтому изменения на USR слое хоть и не влияют на исходные тексты sys слоя, но могут влиять на его байт код. (Пример: добавили переменные в ClassDeclaration класса RunBase или SalesTableType - это приведет также к изменения байткода классов наследников на sys слое, поэтому если не скопировать все aod файлы то могут быть ошибки времени выполнения. Либо надо делать полную компиляцию. Но зачем, когда можно скопировать....)

[Товарищ ♂uatr]

Цитата:

Сообщение от Logger

Несколько раз за всю практику копировал aoi - вроде работало.

Пытаюсь выяснить: почему это не является общепринятой практикой?

[Logger]

Цитата:

Сообщение от Товарищ ♂uatr

Пытаюсь выяснить: почему это не является общепринятой практикой?

Не знаю.
В моем случае, время постройки индекса нас не ограничивало. Поэтому на всякий случай перестраивали (иногда он кривился, поэтому на всякий случай создавали каждый раз с нуля).

[Товарищ ♂uatr]

Здравствуйте.
Обновляю статус: Перешли на модель поставки с копированием как aod, так и aoi файлов - время поднятия АОСа сократилось до 10 секунд. Спасибо!

[Logger]

Цитата:

Сообщение от Товарищ ♂uatr

Здравствуйте.
Обновляю статус: Перешли на модель поставки с копированием как aod, так и aoi файлов - время поднятия АОСа сократилось до 10 секунд. Спасибо!

А синхронизация сколько занимает ?
Весь аот синхронизируете или только измененные узлы ?

[Товарищ ♂uatr]

Весь, последний раз ~3 минуты.
Мы ещё не занимались оптимизациями по данному вопросу.