Лучшие практики для применения изменений в приложении SharePoint

Question

Мне кажется, что мне нужна более четко определенная среда для обновления приложения SharePoint (MOSS 2007) с изменениями пользовательского кода. Я создаю файлы решений wsp с функциями и новыми типами и тому подобным, но как только они будут протестированы и развернуты, я чувствую, что это немного прыжок, и это заставляет меня нервничать и иногда неохотно вносить изменения. После развертывания трудно сопоставить текущее состояние приложения SharePoint с конкретным кодом, развернутым на этом сервере SharePoint. Какие функции фактически установлены и на каких сайтах? Какие функции активированы или деактивированы? Какая версия этого настраиваемого поля или типа контента действительно существует? Вещи как это. Если возникает ошибка, я должен полагаться на свои предположения о том, какой код существует и на самом деле выполняется, или мне приходится тратить время на копание в развернутых сборках и 12 кустах - не невозможно, но довольно неприятно.

Какие шаги я должен предпринять, чтобы улучшить мою способность однозначно определять состояние приложения и находить код, который действительно представляет это состояние? Существуют ли сторонние инструменты, которые могут помочь с этим?

Answer 1

Я чувствую вашу боль ... Жизненный цикл разработки приложений с SharePoint 2007 оставляет у меня горький привкус во рту.

Чтобы ответить на ваш вопрос. Мы создали нашу собственную утилиту развертывания, которая делает для нас несколько вещей.

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

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

3. Показывает версию файла и дату выбранных сборок из GAC (делает это во всех веб-интерфейсах). Ранее мы сталкивались с проблемами, когда сборки неправильно устанавливались на фермах.

4. Обновляет настройки web.config на основе предоставленной нами XML-схемы. У нас возникли некоторые проблемы с обновлениями web.config, поэтому мы подумали о создании утилиты для проверки web.config (в частности, убедитесь, что для определенных ключей нет повторяющихся записей).

5. Push-обновления типа контента (впервые типы контента развертываются с помощью функции, она прекрасно работает, но как только вам нужно обновить этот тип контента, это становится жестким).

6. Проверяет состояние пакета WSP после развертывания или обновления.

Эта утилита использует API SharePoint для выполнения большей части этой работы. Частично это делается проверкой событий WMI.

Answer 2

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

Функции доступны на всех уровнях от фермы до отдельной сети; поэтому обслуживание с этого уровня немного сложно. Я просто пытаюсь организовать весь развернутый код с (сверху вниз) уровня решения.

Это становится еще сложнее при развертывании пользовательских заданий таймера, обработчиков событий и т. Д .; Я действительно надеюсь, что следующая версия решит многие из этих общих проблем разработчиков.

Answer 3

Это не единственный способ, которым у вас есть запланированный / контролируемый процесс развертывания и система управления версиями, такая как TFS

В текущем проекте, в котором я участвую, у нас есть:

1. Непрерывные сборки
2. Daily Builds на сервере разработки
3. Когда мы выпускаем что-то для тестирования, мы объединяем код с Главной ветвью в системе управления версиями (TFS)
4. После тестирования и готовности к производству мы объединяем главную ветвь с разделительной ветвью

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