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

[raz]

Цитата:

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

Это до тех пор пока вы проектами все обновляете. А когда объем доработок большой, а время простоя базы не более часа в неделю - то приходится слоем обновлять - для таких случаев актуально чтобы id-ники выделялись в одном месте и не менялись.

Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

ЗЫ. Даже очень большой проект можно накатить через *.xpo
Есть ли у кого-нибудь такая штучечка?

[Logger]

Цитата:

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

Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

Понятно. А расскажите поподробнее что может быть плохого ?

Цитата:

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

ЗЫ. Даже очень большой проект можно накатить через *.xpo
Есть ли у кого-нибудь такая штучечка?

Спасибо.
Это все правильно. Но если проектов 15, даже не очень больших, то по-моему проще слоем. Не забывайте про ограничение по времени простоя базы. Лучше в таком случае сделать как ice предложил. Правда все равно может потребоваться иногда лечить идентификаторы.

[raz]

Цитата:

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

Понятно. А расскажите поподробнее что может быть плохого ?.

После накатки приложения нужно синхронизировать, вот тут и вылазят проблемы с разными идентификаторами. Можно ненароком потерять данные в несовпадающих полях.

Цитата:

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

Это все правильно. Но если проектов 15, даже не очень больших, то по-моему проще слоем. Не забывайте про ограничение по времени простоя базы. Лучше в таком случае сделать как ice предложил. Правда все равно может потребоваться иногда лечить идентификаторы.

Тут согласен. Делаем текущую копию реального приложения, переносим на нее попроектно при помощи *.xpo новые наработки (с инкрементной компиляцией). Полученное приложение накатываем вместо рабочего. Синхронизируем.

[Bishop]

Цитата:

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

Это до тех пор пока вы проектами все обновляете. А когда объем доработок большой, а время простоя базы не более часа в неделю -
то приходится слоем обновлять - для таких случаев актуально чтобы id-ники выделялись в одном месте и не менялись.

Цитата:

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

Очень плохая практика, может привести к ОЧЕНЬ БОЛЬШОМУ геморою.

Очень смелое утверждение!

У меня абсолютно противоположное мнение. В общем случае, обновление рабочего приложения желательно проводить только слоем (слоями) из приложения разработки. А если все же дело доходит до проектов (в крайних случаях), то экспорт/импорт только с идентификаторами.
И вот почему:
1) Не все клиенты покупают лицензии на разработку, и опция "инкрементная компиляция" у них отсутствует.
2) Не у всех клиентов есть лицензии на разработку в тех слоях, в которых ведет разработку партнер. Если у вас разработка в VAR, а в рабочем приложении
все "лежит" на CUS или USR - это, как минимум, выглядит криво.
3) Как обновить проектом удаленную (переименованную) в разработке форму/таблицу/класс/...?
4) Если рабочее приложение развернуто на нескольких АОСах (да еще и с балансировщиком), обновление проектом может привести как раз к ОЧЕНЬ большому геморрою (особенно при наличии новых таблиц/полей, как показала практика).
5) При различиях в идентификаторах таблиц и полей невозможно (в общем случае) корректно подменить данные приложения разработки из рабочей базы при помощи резервного копирования и восстановления (а такая необходимость иногда возникает).
6) В "стандарте" нет инструментов, позволяющих проверять, что проект включает все "затронутые" объекты, и это "проверяется" лишь на этапе импорта.

В добавок к этому, обновление проектами ухудшает качество разработки, т.к. всегда можно "быстренько все подправить", если что...

[oip]

Цитата:

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

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

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

По-моему, на эту тему уже был опрос, но что-то я его не нашел.

[Logger]

Цитата:

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

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

По-моему, на эту тему уже был опрос, но что-то я его не нашел.

Согласен.

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

[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. В этом случае использование тех же конфигурационных ключей (к примеру, специфичных для того или иного филиала) с целью управления тем, какой функционал должен работать, а какой - нет, как нельзя лучше решает эту проблему.

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