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

[Dron AKA andy]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[gl00mie]

Цитата:

Сообщение от Dron AKA andy

Цитата:

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

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

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

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

[petr]

Цитата:

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

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

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