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

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

Сообщение от 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 и какие действия нужно выполнить сразу после наката обновления.