SharePoint 2010: Создайте эффективную среду

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

Имеется несколько продуктов, помогающих сотрудникам групп разработки взаимодействовать и обмениваться информацией, в частности, Microsoft Visual Studio Team Foundation Server (TFS), обеспечивающий ряд преимуществ при разработке для SharePoint. Он тесно интегрирован и Visual Studio, и с SharePoint. Если в вашей организации еще нет такого средства и она занимается разработкой приложений в основном для среды Microsoft Windows, следует подумать о приобретении TFS.

Независимо от того, какие продукт и метод вы выберете, ваша платформа должна выполнять следующие функции:

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

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

Среды разработки

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

Одна из типичных ошибок — иметь один «сервер разработки», используемый всеми разработчиками группы. За исключением случая, когда члены группы разрабатывают совершенно независимые компоненты и им не нужно выполнять общие операции, такие как перезапуск IIS или подключение отладчика к процессу IIS, такие среды работают не очень хорошо. Изоляция разработчиков друг от друга — лучший способ добиться продуктивной работы каждого из них.

Еще одно заблуждение — то, что можно вести разработку на клиентской системе в Visual Studio, а отладку — на удаленном сервере, на котором выполняется SharePoint. Вы можете отлаживать решение SharePoint, выполняемое на другом сервере, но в системе, на которой компилируется серверный код SharePoint, должна быть установлена SharePoint. Библиотеки, используемые серверным кодом, доступны только на сервере SharePoint. Вы не можете установить их отдельно на клиентский компьютер, чтобы ваш код компилировался. Но если вы разрабатываете клиентские приложения, используя новые Client Object Model (Client OM), введенные в SharePoint 2010, вы сможете их скомпилировать и в системе, на которой не установлена SharePoint.

Вот минимальные требования к среде разработки для SharePoint:

• 64-битная ОС Windows, совместимая с SharePoint 2010 (Windows 2008, Windows Vista SP1 или Windows 7);
• Visual Studio 2010;
• SQL Server Express Edition;
• компоненты SharePoint Foundation или Server (в зависимости от ваших требований).

Следующие инструменты часто бывают полезными, и их следует включать в среду всегда, когда есть возможность:

• приложения Microsoft Office;
• SQL Server Developer Edition;
• Microsoft Visio;
• InfoPath Designer;
• SharePoint Designer (можно скачать бесплатно).

Имеется несколько вариантов выбора, куда устанавливать все эти инструменты. Первый и самый простой из них — установить все эти средства и SharePoint прямо на компьютер разработчика. Для этого требуется 64-битная ОС, совместимая с SharePoint. Такая конфигурация проста в использовании, поскольку все необходимые средства находятся под рукой.

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

Варианты построения среды разработки

Еще один вариант — использовать продукт виртуализации рабочих столов, такой как Oracle VirtualBox или VMware Workstation. И снова вы должны убедиться, поддерживает ли средство виртуализации 64-битные гостевые ОС. Такой конфигурации свойственны многие те же самые ограничения, что и при прямой установке среды на настольный компьютер. Как правило, производительность оказывается не особо высокой, и вам приходится создавать больше дисковые файлы для поддержки виртуализации рабочих столов.

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

Кроме того, можно создать файл виртуального жесткого диска (virtual hard drive,VHD) и запускать его прямо из системы, не используя продукт виртуализации рабочих столов. Это аналогично старой технологии установки системы с двумя вариантами загрузки. Вместо использования своего раздела для второй ОС, вы используете VHD-файл в файловой системе существующей ОС. Эта конфигурация удобна тем, что вы используете только аппаратуру системы и не требуется запускать вторую ОС, которая будет хостом для сервера разработки.

Единственный недостаток — то, что все приложения, загруженные в клиентскую ОС компьютера, не доступны во время выполнения среды разработки. Такая конфигурация быстро становится самой популярной у разработчиков для SharePoint, поскольку обеспечивает гибкость, присущую виртуализации рабочих столов, без ущерба для производительности. Дополнительную информацию о том, как запускать несколько ОС, используя новые возможности настройки загрузки в Windows 7, см. в сообщении блога Кита Комбса (Keith Combs) «Dual Boot from VHD Using Windows 7 and Windows Server 2008 R2».

Последняя конфигурация основана на виртуализации серверов. Можно задействовать Microsoft Hyper-V, VMWare или любой другой продукт, реализующий виртуализацию серверов. Это отличный вариант для предприятий с развитой инфраструктурой виртуализации. Нужно завести VM на хост-сервере VM и использовать этот сервер для хранения всей среды разработки.

При использовании клиента Remote Desktop Protocol (RDP) разработчик имеет доступ ко всей среде и не должен вносить никакие изменения или выполнять установки в своей локальной среде. Единственный недостаток такой конфигурации — что для того, чтобы вести разработку, необходимо подсоединиться к серверу VM. Вы не можете «взять среду с собой».

Тестовые среды

После того как разработка завершена, вы должны провести скрупулезное и четко определенное тестирование приложения. Для этого требуется перед развертыванием в производственной среде загрузить его в одну или несколько непроизводственных сред. Такие среды называют по-разному: интеграционными, тестовыми, обкаточными (stage), средами приемно-сдаточного тестирования (user acceptance testing, UAT), опытными и т.д.

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

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

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

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

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

Эта методика полезна при работе с общедоступными сайтами, для которых недопустимы простои. Время переключения между серверными фермами — это всего лишь время, необходимое для перенаправления сетевого трафика. Очевидно, что жизненно важно, чтобы все изменения производственного контента попадали на обкаточную ферму перед развертыванием новой версии. Чтобы предотвратить изменения после начала копирования контента, SharePoint позволяет временно заблокировать базы данных контента.

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