Лучшие практики для обновления рабочего сайта SharePoint 2010

Question

У меня есть виртуальная машина (# 1) с установленным SP 2010 и SQL Server 2008. Она отвечает нашим потребностям с точки зрения нагрузки и емкости. В случае поломки мы можем вернуть его к снимку.

Процесс разработки все еще продолжается. Вопрос в том, что является хорошим подходом для обновления рабочей ВМ?

Вариант 1:

1. Иметь копию производственной ВМ (# 2)
2. Когда итерация завершена (разработка-> тестирование-> исправление) и мы готовы сделать обновление, мы меняем виртуальные машины (# 1 <-> # 2)
3. Тестирование ВМ № 2 становится производственным процессом, а № 1 - его тестированием.

"+" : Мы запускаем полностью протестированное решение.

"-" : необходим механизм синхронизации между виртуальными машинами.

Вариант 2:

1. Разработка, тестирование и исправление на рабочей ВМ

2. Публикация изменений, когда мы будем готовы.

"+" : нам не нужен механизм синхронизации между виртуальными машинами

"-" : аварии могут происходить чаще.

Любое предложение будет оценено.

ТИА

Answer 1

НЕ занимайтесь разработкой на производственной виртуальной машине.SharePoint очень легко сломать во время разработки, и вы, скорее всего, в какой-то момент повредите свою производственную среду.Риск в основном слишком высок.

Делайте ваши разработки в отдельной системе.Правильно упакуйте свое решение / изменения как WSP - протестируйте его в другой системе (между вашей средой разработки и, в основном, копией производства).После того, как все тестирование будет проведено на промежуточном сервере, разверните WSP в рабочей среде.

Замена систем - трудная задача, когда дело доходит до SharePoint - у вас есть альтернативные сопоставления доступа, привязки IIS и т. Д.и требует больше времени и усилий, чем просто загрузка нового WSP и нажатие кнопки «развернуть» (очевидно, после тестирования на указанном сервере).

Answer 2

Это действительно зависит от того, «что» вы разрабатываете:

1. Только контент

   • Это часто проще сделать на производственном оборудовании. Стандартной среды публикации должно быть достаточно, чтобы скрыть изменения от обычных пользователей.

   • Или вы можете использовать функции развертывания контента на sharepoint, чтобы переместить его из фермы разработчиков в рабочую ферму

   • Или вы можете использовать инструмент развертывания контента

2. Веб-части, простые компоненты

   • В 2010 году это должно быть сделано как «песочница» (если вы можете с этим справиться), тогда их будет очень просто загрузить / изменить в вашей среде разработки. Создайте свою среду разработки, затем загрузите ее через веб-страницы sharepoint.

3. Сложные компоненты

   • Вещи, которые требуют администратора фермы для установки на сервере (задания, сложные веб-части и т. Д.), Должны быть разработаны с Visual Studio на вашем устройстве разработчика, а затем перенесены в prod полностью протестированным способом. Попробуйте использовать среду тестирования / стадии.

4. Сочетание всего вышеперечисленного

   • Обычно это зависит от степени риска, которому ваш клиент готов подвергаться, скажем, например, если это новый сервер, то нет большого риска уничтожить пользователей системы.

Я бы не рекомендовал установить Visual Studio на PRODUCTION Сервер SharePoint