Тестирование развертывания для Sharepoint несколькими разработчиками на одном сервере

Question

Мы начинаем с разработки Sharepoint с командой из трех человек и в настоящее время создаем среду разработки. Мы хотели бы избежать установки Server 2008 для каждого разработчика, поэтому был настроен один сервер терминалов, используя Remote Windows для запуска экземпляра VS2008 на каждом компьютере разработчика. Теперь мы хотели бы разделить тестовые среды разработчиков (т. Е. Другой сайт на каждом разработчике), но поняли, что сборки должны быть установлены в GAC для корректного отображения на сайте. Но поскольку AFAIK только один GAC, разработчики не смогут самостоятельно тестировать свои материалы.

Можно ли создать отдельные тестовые среды без установки группы серверов 2008 года?

Answer 1

Я не знаю об установке сервера на все, но это похоже на идеальную задачу для виртуальных машин, а не на физических, - где я работаю, мы используем VMWare для этой работы, и это очень хорошо ,

Также полезно иметь возможность отката назад к моментальному снимку, когда дело доходит до тестирования процессов установки и т. Д.

Answer 2

Итак, вы все собираетесь удаленно запускать Visual Studio и собирать вещи и перезапускать IIS и т. Д.?

Вы собираетесь штамповать друг другу пальцы.

В настоящее время более разумным вариантом является использование Hyper-V (или некоторой другой виртуализации).

Мы используем Windows Server 2008 на наших ноутбуках и используем Hyper-V для запуска наших сред разработки. Затем у нас есть среда разработки (песочница), и у них есть VS2008, SVN, Nunit и т. Д.

Наш код протестирован друг против друга благодаря CruiseControl на единственном совместно используемом Hyper-V.

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

Вернитесь и не оглядывайтесь назад.

PS: Я только что просмотрел ваш комментарий об одном сервере ... просто поставьте на него Hyper-V и запустите 3 экземпляра. Это также то, что мы делаем;)

Answer 3

№ В дополнение к GAC есть все файлы SharePoint в 12 кустах, такие как функции и шаблоны сайтов. Это не стоит того, что вы экономите на стоимости сервера.

(Разумеется, если вы не используете GAC, но разворачиваете его в папку bin, и вы ничего не трогаете в 12 улей, вы можете предоставить каждому разработчику собственное веб-приложение на том же сервере. этот подход ставит множество ограничений на то, что они могут сделать. Это все еще не стоит.)

Виртуальные машины будут работать, но они могут медленно развиваться. Например, вам необходимо перезапустить пул приложений для каждого развертывания GAC, что означает паузу в 15-60 секунд для перезагрузки приложения (в зависимости от аппаратного обеспечения). Это станет раздражать.

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

Я рекомендую физический сервер для каждого разработчика.Это позволит свести к минимуму время цикла тестирования кода и убедиться, что им не нужно беспокоиться о том, чтобы наступать друг на друга.

Answer 4

Вы находитесь на неправильном пути с Terminal Services - его просто не дадут вам разделить.

Многие люди рекомендуют разрабатывать на сервере W003/2008 напрямую, и это упрощает некоторые вещи, такие как удаленная отладка.

Я предпочитаю более традиционный метод использования VMWare для запуска виртуальных машин. Они могут работать на локальном или удаленном хосте. Удаленная отладка немного сложнее для настройки, но все же возможна.

Окончательно - если возможно, затем разворачивайте в мусорный диск, а не в GAC. Это упростит развертывание автоматически после компиляции.

Answer 5

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

Некоторые разработчики будут пытаться подключиться к тому же процессу веб-приложений w2ps.exe, поэтому создание отдельных веб-приложений на разных портах является обязательным, если вы не готовы к совместному использованию временной отладки. How to setup a development environment for sharepoint 2013

Вторая проблема заключается в попытке сотрудничества и использования общих компонентов/функций. Желание работать отдельно дискуссионно, я считаю, что разработчики команды должны сотрудничать и делиться друг с другом, поэтому расчесывать работу желательно, чтобы обеспечить бесшовную интеграцию в единое окончательное решение и дублировать работу не нужно. Многопользовательская односерверная среда работает отлично, пока вы не попытаетесь сотрудничать «Одна распространенная ошибка - иметь один« сервер разработки », используемый всеми разработчиками команд. Если члены команды не работают над абсолютно несвязанными компонентами и никогда не должны делать такие общие вещи, как перезапуск IIS или присоединение отладчика к процессу IIS, этот тип среды обычно не работает ». http://technet.microsoft.com/en-us/magazine/dn145990.aspx Мы допустили эту ошибку из-за отсутствия опыта и знаний, но как только вы это сделаете, можно обойти ее.

Моя первая попытка поделиться функциями заключалась в том, чтобы скопировать проект разработчика 1 в решение разработчика 2 и добавить ссылку на него в проект разработчика 2 и добавить все возможности в пакет разработчика 2. Развертывание этого отлично подходит для разработчика 2, пока я не обнаружил, что если разработчик 1 отсоединяет свое решение от отладчика, он ретранслирует решение на основе дублированного идентификатора решения из фермы и, следовательно, из веб-приложения каждого разработчика. Поэтому у разработчика 2 есть коврик, вытащенный из-под них. Хотя это часть решения и, похоже, какое-то время работало, мне потребовалось некоторое время, чтобы разобраться, что происходит, и какие комбинации развертываний dev 1 и 2 делают работу друг друга и не работают.

Таким образом, я нашел лучшее решение. В свойствах проекта в Visual Studio под вкладкой SharePoint есть поле со списком «Автооткат после отладки». Это по умолчанию отменяет решение, когда разработчик останавливает прикрепленный отладчик и вытаскивает функции из-под других разработчиков. Отключение этого блока предотвращает возврат и оставляет каждого отдельного решения разработчиков, развернутого на уровне фермы, и при повторном подключении к отладчику просто заменяет решение с минимальной проблемой.

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