Расхождение идентификаторов Prod и Stage окружений для ax2012 (способы исправления/недопущения)

[Logger]

Привет всем.
Хотел провести опрос, кто как решает проблемы с расползанием идентификаторов при Prod и Stage окружения в аксапте 2012.

Если что, проблема описана тут
https://download.microsoft.com/downl...vironments.pdf

Quote:

If you use model store files to move metadata between two environments, it is critical to preserve common element IDs between both environments. To preserve common IDs between staging and production, adhere to the following guidelines:
• Initialize the model store of the staging system by importing the model store file from the production environment.
• Do not import new elements (by using XPOs or model files) or create new elements on the production system; otherwise, they will have a different element ID than they have on the staging system.
• Do not delete and re-import models to avoid generating new element IDs. Instead, import models without deleting the existing ones to update the metadata.
• Do not import a model store to the staging environment from a source other than the production system’s model store.
If you do not follow these guidelines, you will have to recreate the staging environment from the production environment.

т.е. официально, Microsoft предлагает только пересоздавать Stage если разъехались идентификаторы.

А как их еще можно выровнять или недопустить их расползания?

Просьба проголосовать.

[db]

давным давно делал доработку экспорта для заполнения LegacyId. и все новые элементы создавались в одном приложении - ну в общем жили как в 2009

однако с 12-кой работал всего один проект (менее полугода) и возможно просто не успел тогда примириться с "новой реальностью"

[Logger]

Quote:

Originally Posted by db

давным давно делал доработку экспорта для заполнения LegacyId. и все новые элементы создавались в одном приложении - ну в общем жили как в 2009

А! т.е. в момент экспорта проекта из DEV проходили по всем его элементам и заполняли LegacyId ?

Прикольно.
Но ведь в самом дев идентификаторы от этого не меняются. Вы их тоже перебивали ? Или оставляли как есть ?

[db]

Quote:

Originally Posted by Logger

А! т.е. в момент экспорта проекта из DEV проходили по всем его элементам и заполняли LegacyId ?

Прикольно.
Но ведь в самом дев идентификаторы от этого не меняются. Вы их тоже перебивали ? Или оставляли как есть ?

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

Собственно повторил проверенную годами схему как жили в 2009, просто вернув выпиленную MS возможность экспортировать с id элементов

[sukhanchik]

Quote:

Originally Posted by Logger

А как их еще можно выровнять или недопустить их расползания?

А можно такой вопрос... может весьма наивный... ? )

Чем плох простой бекап / восстановление БД model со STAGE на PROD?

Сценарий:
1. Имеем STAGE + PROD с выровненными ID
2. Переносим XPO на PROD с новыми объектами. Собираем CIL (можно инкрементно). ID-шники разъехались
3. Делаем бекап / восстановление БД model со STAGE на PROD с последующей сборкой полного CIL. ID-шники снова выровнялись.

Ключевой минус - очевидно, что релиз через modelStore позволяет сократить время простоя рабочей базы в момент релиза. В указанном мною примере фактически ещё полчаса требуется на сборку CIL.
Однако, если данное решение рассматривать в первую очередь, как решение по выравниванию ID - то это решение вполне жизнеспособно. Также оно жизнеспособно в тот момент, когда XPO-шники в "горящем" режиме могут накатываться весьма часто.

Обновление PROD -> DEV можно вполне делать вместе с БД. В крайнем случае можно воспользоваться скриптом https://github.com/dodiggitydag/AX-2...model%20db.sql (проверял; рабочий. Но его нужно запускать строго при остановленном АОСе - иначе он некорректно отработает)

[sukhanchik]

Quote:

Originally Posted by db

Но создавать новые элементы разрешалось (административно с битьем по рукам) только в DEV и этот DEV-id потом переползал без изменений во все среды

Если говорить про релиз через modelStore - то там всё хуже. ID-шники считаются "разъехавшимися", если я просто индекс создал на существующей таблице на PROD. Например, в рамках оптимизации производительности. Т.е. даже создание индекса в такой ситуации должно создаваться где-то на условном DEV / STAGE - в общем, на приложении, на котором генерятся ID-шники

[Logger]

Quote:

Originally Posted by sukhanchik

Чем плох простой бекап / восстановление БД model со STAGE на PROD?

Ничем не плох. Работает хорошо. Даже быстрее чем через modelStore. (импорт при помощи modelStore посредством axUtil занимает около 6 - 7 минут. Восстановление из бекапа средствами SQL 10-30 секунд. Только требует больше прав на SQL для пользователя которые делает релиз.

Quote:

Originally Posted by sukhanchik

2. Переносим XPO на PROD с новыми объектами. Собираем CIL (можно инкрементно). ID-шники разъехались

CIL собирать не обязательно. ID-ники могут разъехаться в момент переноса.

Quote:

Originally Posted by sukhanchik

3. Делаем бекап / восстановление БД model со STAGE на PROD с последующей сборкой полного CIL. ID-шники снова выровнялись.

ID-ники между Stage и Prod выровнялись конечно, но не это нас волнует, так как при этом разъехались ID-ники между базами Prod (бизнесданные) и Prod_Model (приложение) и тогда при синхронизации можно потерять данные. В этом то и проблема !
Для некоторых сценариев возможно удаление столбца в БД и создание снова с дефолтными значениями. Итп.
В некоторых случаях ядро аксапты достаточно умное и само перебивает идентификаторы в SQLDictionary, проставляя их как в модели (т.е. удаления столбца в табличке не происходит). Но если у нас идентификатор используется в табличках с бизнесданными (такие случаи я описал выше в статье) - то там остаются предыдущие значения. Логическая целостность нарушена.

Quote:

Originally Posted by sukhanchik

XPO-шники в "горящем" режиме могут накатываться весьма часто.

Вот именно. Именно поэтому мы и старались выработать "гибридный" режим подготовки релиза, чтобы можно было между релизами накатывать срочные проекты через Xpo, не делая строгих запретов. Но при этом приходится пересоздавать Stage модель перед подготовкой релиза, как и рекомендовано в документации от Microsoft. Плюс получается что нельзя в любое время между релизами накатывать проект на Stage, но возникает момент времени (за 1-2 дня до релиза) когда Stage пересоздали, а затем в авральном режиме (если проектов к переносу много) занимаемся только переносом их на Stage, при этом запрещая переносить на Prod через xpo. Это не очень удобно. Вот хочется найти способ, чтобы и идентификаторы Prod и Stage выровнять и авралов не создавать.

[sukhanchik]

Quote:

Originally Posted by Logger

Ничем не плох. Работает хорошо. Даже быстрее чем через modelStore. (импорт при помощи modelStore посредством axUtil занимает около 6 - 7 минут. Восстановление из бекапа средствами SQL 10-30 секунд. Только требует больше прав на SQL для пользователя которые делает релиз.

Если дело только в правах, то этот вопрос решается достаточно просто:
1. Права на бекап / восстановление - это относительно небольшие права и их выдать (без права доступа к файлу бекапа со стороны Windows) не очень сложно. Есть определенные заморочки в части доступа к физическим файлам на диске, но они решаются (придется немного покорпеть в части составления прав).
2. Есть универсальный способ выдачи прав ... без их выдачи. Организуется запланированное задание (Task в Windows Sheduler), которое запускается от имени служебного пользователя с правами. Обычному пользователю даются лишь права на запуск этого задания (и само собой без выдачи пароля на этого служебного пользователя). У такого подхода есть минус - перечень команд, который выполняется шедулером сложно вставить в свой скрипт (нужно ожидать изменение статуса шедулерного задания). Поэтому выдача прав на бекап / восстановление без прав доступа к файлу со стороны Windows (т.е. когда пользователь, выполняющий релиз не может достучаться до этого файла) - проще, чем организация бекапа через шедулер.

Quote:

Originally Posted by Logger

CIL собирать не обязательно

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

Quote:

Originally Posted by Logger

так как при этом разъехались ID-ники между базами Prod (бизнесданные) и Prod_Model (приложение) и тогда при синхронизации можно потерять данные

Не... ну тут надо понимать "степень запущенности". Для лечения насморка антибиотики необязательны, а при воспалении лёгких без них уже не обойтись .
Переносить через XPO таблицы и поля - суть есть зло, потому что:
1. Это всё равно потребует рестарт АОСа в общем случае
2. Инкрементный CIL не всегда поможет (например, при удалении поля точно)
При этом остальные объекты (классы, формы, привилегии и т.д.) спокойно можно переносить с пониманием, что релиз со STAGE ничего не потеряет.
При этом те же таблицы / поля в принципе "лечатся" скриптом, на который и Вы и я - давали ссылку на Github. Т.е. если вот ну очень прям "надо-надо" было перенести табличку / поля - можно перенести, но потом запланировать релиз со STAGE с применением скрипта по выравниванию ID-шников без потери данных. Но в целом - просто стараться исключать ситуаций переноса таблиц / полей через XPO.

Quote:

Originally Posted by Logger

Именно поэтому мы и старались выработать "гибридный" режим подготовки релиза, чтобы можно было между релизами накатывать срочные проекты через Xpo, не делая строгих запретов

.

Ну вот ещё со времен 2009-й (а там ещё "многое чего было по-старому") - я привык к таким правилам:
1. Если накат обновления требуется выполнить сегодня из-за того, что встанут какие-то критичные процессы в компании (платежи, продажи) - то обновление делается через XPO. Если туда добавляются таблички / поля - то снимается копия приложения (PREPROD), на него накатывается XPO и оно релизится.
2. Плановые релизы выполняются еженедельно, если выполняется одно из условий:
а) в течении недели хотя бы одна модификация была бы перенесена на STAGE
б) в течении недели хотя бы одна модификация была бы перенесена через XPO на PROD
3. Внеплановый релиз может быть сделан, если был накатан XPO с таблицей, чтобы поскорее привести ID-шники в норму.

Всё это делалось применительно к приложению, которое должно было работать в режиме 24х7. Если есть окна в работе системы - то релиз можно делать и чаще.
Проблемы массового переноса на STAGE были; поэтому от идеи переноса кода на STAGE непосредственно перед релизом отказались, но XPO накатывали на PREPROD и STAGE одновременно (для экстренных XPO).

Из побочных эффектов - т.к. иногда STAGE уходил на релиз внепланово - то некоторые модификации появлялись раньше запланированного времени. Поэтому в TFS (Team Foundation Server - сейчас это Azure DevOps) каждая задача, которая переносилась на STAGE переводилась в статус что-то типа "К обновлению" (точно не помню) с обязательным описанием действий при релизе (джобик запустить или еще чего). Т.о. при внеплановом или плановом релизе было понятно - какие задачи находятся на STAGE и какие действия нужно выполнить сразу после наката обновления.