решения\solutions: how to

[Eugene.Ostroukhov]

добрый день.
подскажите плз вменяемый ресурс для полного понимания как работают решения в плане managed/unmanaged?

я правильно понимаю, что
1) managed: импорт-удаление - самый простейший способ для паблиша в продакшен ?
какие могут быть подводные камни при установке решений, содержащих те же компоненты (вебресурсы, формы в основном) в будущем ? как СРМ понимает какую версию формы\ресурса при этом использовать? не будет ли это трудоемко по производительности ?
версионность?

2) unmanaged: тут попроще для понимания - в виде debug mode, когда можно вручную ченить починить быстренько.
но откаты - это бекап компонент, которые содержатся в решении, и тот же импорт-удаление-импорт бекап-решения - выглядит ужасом, кмк.

какие нибудь best practice? интересуют вобщем-то они, наверное *-)
помимо "если вам не надо менять решение блабла" из стандартных мсднов и блогов с тултипами в самом срм

пысы: изменений очень много, но мелких, и очень часто изменения пересекаются по компонентам (формы, скрипты и пр.)

[a33ik]

Добрый день,

Смотрите SDK:
https://msdn.microsoft.com/en-us/library/gg334576.aspx
https://msdn.microsoft.com/en-us/library/gg309329.aspx

[Eugene.Ostroukhov]

Deleting a managed solution uninstalls all the solution components in it.

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

(просто вопрос возник изза лени с откатом unmanaged)

[Артем Enot Грунин]

Вся суть решений не в том, как они выгружаются, а как работают в системе куда они установлены. Пара значений Издатель + Решение определяет такую вещь, как зависимости между компонентами + их управляемые свойства. Удаление управляемого решения, действительно приводит к удалению зависимостей и самих компонент, если они не используются другим решением (например стандартным решением).
Если нужна простая аналогия, то управляемое решение - это гвозди в коробке, а не управляемое - гвозди на лопате.

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

Я рекомендую следующую практику: нужно иметь отдельные решения для основных компонент решения:

1. Кастомизации и локализация
2. Права доступа (частые плавающие правки)
3. Сборки и бизнес-логика (плагины)
4. Рабочие процессы (имеют специфику активации при установке)
5. Отчеты

Для последних трех решений очень важна та самая возможность удаления решения в ад. Дело в том, что обновление решения - это всегда сумма компонент. Если вы что-то удалили из своего пакета, в принимающей системе это что-то все равно останется. Например, имеем ситуацию, когда вы объединили несколько отчетов, пересмотрели процессы или отказались от какой-то бизнес-логики в пользу другого решения. Через неуправляемое решение вы накатите новые компоненты поверх старых и вам придется вручную вычищать лишнее. Иными словами появятся новые процессы и обработчики, но и старые продолжат работать. Поэтому бывает удобно снести старую версию решения со всем этим хозяйством и развернуть новую. По сути - переустановить решение. При этом, вы сохраняете возможность обновить минорную версию. Красота. Но только очень важно, чтобы ваши решения не имели лишних зависимостей, чтобы вместе с процессами не снести случайно какую-то сущность вместе с таблицей в БД.

[Eugene.Ostroukhov]

о, спасибо большое! очень хороший пост! (пысы : ссылки выше тоже хороши! )

у меня ситуация сейчас следующая:
есть уже вполне себе готовая к продакшену СРМка, сделанная подрядчиком.
глобальные вещи меняться не будут совершенно точно.
т.е. ничего нового кроме отчетов, плагинов, воркфлоу появляться не должно в теории.
вся допиливание существующего: добавить\удалить поля, перенести между сущностями их, какая нибудь клиентская бизнес-логика на джаваскрипте, типа скрыть\показать\сделать обязательным, не дать натворить фигни пользователям и т.п. Т.е. вся работа - не сильно глобальная и даже скорее - точечная.

из доставшегося - ВСЕ решения от подрядчика - неуправляемые.
системного функционала СРМа используется очень мало (буквально 3-4 сущности, вроде подразделений\пользователей\рабочих групп\ролей), никаких activity и прочего (т.е СРМ не срм вовсе - как отношение с кастомерами, а просто как платформа чтоб побыстрее наклепать своих каталогов и форм)

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

но мысль я ухватил. спасибо большое еще раз!