Какова ваша стратегия обслуживания кода для пользовательских сборок SharePoint? - PullRequest
4 голосов
/ 02 января 2009

Как вы справляетесь с улучшениями и добавлением функциональности в существующий код SharePoint?

Развернули ли вы исходный код как функцию?
Вы создаете новую feature_V2 и деактивируете оригинал?

Какие процессы вы обнаружили, что привело к проблемам в будущем?

Меня особенно интересуют WebParts, EventHandlers и WorkFlows.

Из того, что я могу найти, MS не оставляла "Best Practices" по обновлению существующего кода. (На самом деле, я не уверен, что они оставили «Практику», а тем более «Лучшую практику»)

Вы можете увидеть другие вопросы по этой теме:
как к модернизации-а-затянувшийся-SharePoint-рабочего процесса уже в произведенной продукции
как к обновлению-spitemeventreceiver-сборочно-версия-для-а-список-в-1017 * SharePoint *
должен-я-держать-решения-и-функции-в-1-1-отношение

Какой у вас метод?

Я понимаю, что этот вопрос может быть субъективным, но мне кажется, что в этой области разработки SharePoint существует большой информационный пробел.

Спасибо,
Кит

Ответы [ 2 ]

3 голосов
/ 03 января 2009

Мы всегда внедряем пользовательский код как функции и решения. Когда пришло время обновить существующий код, все, что вам нужно сделать, это stsadm -upgradesolution, и все работает очень хорошо. Мне не нравится идея иметь в своем распоряжении функции типа feature_v2 ... очень трудно отслеживать текущую версию. Я думаю, что у вас должна быть только одна версия каждой функции в вашей производственной среде.

Оставьте контроль версий в вашей системе контроля версий.

0 голосов
/ 15 января 2009

Я работаю в магазине, который занимается разработкой SharePoint. Вы хотите развернуть по функции с пакетом решения. Вы можете легко обновить свои функции по мере продвижения, и вам нужно будет обновить пакет решений. Этот пакет решений может быть создан на сервере сборки TFS с WSPBuilder . Пока вы впереди, остается только обновить решение и «Принудительно» активировать вашу функцию, чтобы получить новую функцию.

Не забудьте выполнить сброс IIS для любого нового развертывания кода, которое выполняется через GAC. Если вы поместите что-то внутри, например, карты сайта и ресурсы, в свои 12, вы захотите сделать stsadm -o copyappbincontent .

Если вы развертываете функции, содержащие файлы приложений, вы хотите выгрузить ваше приложение на ВСЕХ серверах фермы. Это легко сделать, поместив App_Offline.htm в корень каждого приложения на каждой машине.

По завершении удалите App_Offline.htm (или переименуйте его), и все готово. Ваш сайт снова в сети.

...