Цитата:
Сообщение от
Bishop
В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки.
Выскажу свое мнение. Использовал оба способа, в каждом есть свои + и -, сейчас остановился на переносе проектами с идентификаторами из тестового в рабочее (с разработческого на тестовое - тоже проектами и обязательно БЕЗ идентификаторов).
По пунктам:
Цитата:
Сообщение от
Bishop
1) Не все клиенты покупают лицензии на разработку, и опция "инкрементная компиляция" у них отсутствует.
2) Не у всех клиентов есть лицензии на разработку в тех слоях, в которых ведет разработку партнер. Если у вас разработка в VAR, а в рабочем приложении
все "лежит" на CUS или USR - это, как минимум, выглядит криво.
Важность этих пунктов оценить не могу, т.к. то немногое кол-во клиентов, с кем мне довелось поработать (внутренние проекты), обязательно имели лицензию на разработку. Велась разработка в USR.
Цитата:
Сообщение от
Bishop
3) Как обновить проектом удаленную (переименованную) в разработке форму/таблицу/класс/...?
Интересно (сам не пробовал - не довелось), как отреагируют данные при переносе слоем таблицы с измененным названием или переименованным полем? Перенос проектами задачу сохранения данных в этом случае не решает, приходится предварительно ручками переименовывать...
Цитата:
Сообщение от
Bishop
4) Если рабочее приложение развернуто на нескольких АОСах (да еще и с балансировщиком), обновление проектом может привести как раз к ОЧЕНЬ большому геморрою (особенно при наличии новых таблиц/полей, как показала практика).
Тут практикую, конечно, копирование слоя или вообще полное копирование приложения из основного рабочего АОС (на который производится подъем проектов).
Цитата:
Сообщение от
Bishop
5) При различиях в идентификаторах таблиц и полей невозможно (в общем случае) корректно подменить данные приложения разработки из рабочей базы при помощи резервного копирования и восстановления (а такая необходимость иногда возникает).
Это довольно редко необходимая (при наличии тестовой базы) операция, и решается очисткой SqlDictionary и запуском Проверки/Синхронизации, подробнее в
Изменение идентификаторов(id) полей
Цитата:
Сообщение от
Bishop
6) В "стандарте" нет инструментов, позволяющих проверять, что проект включает все "затронутые" объекты, и это "проверяется" лишь на этапе импорта.
Это да, но тут, помимо элементарной аккуратности, помогает обязательный этап тестирования в отдельном тестовом приложении. Может, то "забытое" и не нужно?
По мне, основной минус в переносе слоем - уже упоминавшаяся вероятность поднять на рабочую неоттестированные модификации. При достаточно большом объеме доработок между отдельными подъемами эта вероятность стремится к 100%, что чревато. Хотя, подъем проектами лишь снижает эту самую вероятность, т.к. остается вариант пересечения модификаций по объекту...
Вариант
Цитата:
Сообщение от
Logger
Мы для этой цели попробовали применить схему похожую на то как в ax3.0 sp5 объединили восточно-европейский функционал - там везде понатыкана проверка что если конфигурационный ключ для такой-то страны включен, то выполнять определенный код иначе пропускать.
не пробовал, но для решения проблемы случайного переноса мелких модификаций это, извините, жесть!