Давно собирался написать о том, как мы разрабатываем решения для SharePoint-a. Мы, как обычно, пошли не тем путем, который рекомендует Microsoft, а выработали свой подход. Почему, я считаю, что наш подход лучше, сейчас расскажу.
Напомню, что для разработки SharePoint решений Microsoft рекомендует каждому разработчику обзавестись своей собственной локальной виртуальной машиной для разработки и делать всю работу непосредственно внутри неё. Это «локальная» разработка, потому что студия у вас запущена на самом сервере непосредственно.
Однако, при желании, можно разрабатываться и в «удаленном» режиме, когда студия запущена непосредственно на машине разработчика, а сама виртуальная машина хостится где-то на централизованном сервере. Здесь, правда, смешано два вопроса. Во-первых, где запускать студию для работы: на сервере или на своей рабочей машине. А во-вторых, где держать саму виртуальную машину: у разработчика на машине или централизованно.
Почему работать со студией, запущенной на своей машине удобнее? Ну, или точнее, при наличии инструментальной поддержки удобнее? А вот почему:
- Более отзывчивая студия.
Всё-таки через терминал со студией работать далеко не так комфортно, в сравнении с вариантом, когда студия запущена сразу на своей машине. Тут думаю и так понятно. К тому же, иногда, сервер может находиться достаточно далеко, где-то за океаном. При этом любая разработка по терминалу превращается в испытание воли и тренировку самообладания. Удаленная разработка же позволяет от этого избавиться. - Отделение исполняемой среды проекта от окружения, в котором этот проект разрабатывается.
В большей степени это возможность держать все проекты вместе у себя на диске, где-то скажем в папке Projects, открывать их по мере необходимости, собирать проект, не заходя на терминал вообще, искать по исходным текстам какой-нибудь класс и многое другое. А во-вторых, это возможность спокойно убивать, заменять и откатывать виртуальные машины в процессе работы. Раз на них исходных файлов проекта нет, шанс, что что-то потеряется, значительно уменьшается. Контент базу беречь, конечно же, при этом все равно надо. Но это уже совсем другая история. - Уменьшение требований к ресурсам виртуальной машины.
Нам практически не нужен терминальный сеанс на самом сервере и нам очень редко нужно на нем запускать студию. Это снижает требования по оперативной памяти для комфортной работы такой виртуальной машины. На одной это не сильно заметно, а вот если у вас их много, уже достаточно чувствительно.
Без дополнений к студии здесь, конечно, не обойтись. Мы, в свое время, прошли долгий путь от скриптов в post-build event’ах, специальных батников, использующих psexec, до написания собственного дополнения к студии. Получилось вот такое решение http://wssdeploy.codeplex.com/ . Плюс, для создания SharePoint проектов на машине без SharePoint-а, нужно добавить себе в реестр копию ветки HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0 с любого сервера (полностью описано, например, тут http://techblog.hk.agenda-asia.com/2010/10/29/create-sharepoint-project-without-install-sharepoint-server/). После этого, необходимость заходить на терминал, чтобы что-то сделать с проектом, практически исчезает. Более подробно о типовых сценариях удаленной разработки расскажу в следующий раз.
А пока, справедливости ради, стоит отметить недостатки удаленной разработки:
- К сожалению, Workflow нельзя отлаживать удаленно. Для отладки придется все-таки логиниться на сервер.
- Немного более замороченный процесс отладки. Нужно запускать remote debugger на удаленной машине, следить чтобы сервер не был наглухо закрыт firewall-ом и тп. Есть нюансы при кросс-доменной отладке. Хотя, если все правильно настроено, процесс будет не сильно отличаться от отладки на локальной машине.
Вот, в принципе, и все минусы. На мой взгляд, плюсы существенно перевешивают минусы.
Теперь немного о втором вопросе. Где держать сами виртуальные машины? У разработчиков на рабочих станциях или централизованно на сервере (ферме)?
Однозначно централизованно на сервере:
- В централизованном варианте можно добиться гораздо большей производительности каждой виртуальной машины за счет лучшего железа, большей памяти, аккуратно настроенного кеширования операций с жестким диском и т.п. На хорошем серверном железке с запасом памяти виртуальные машины будут работать значительно лучше, чем на ПК даже последней сборки.
- Так ими гораздо проще управлять. Мы делаем виртуальные машины под проекты. При этом если нашелся какой-то баг, а проект уже сдан, всегда можно включить машину и протестировать фикс, прежде чем его отсылать заказчику. А не искать её судорожно где-то на давно отформатированном диске у разработчика.
- Меньше ограничений по ресурсам. Можно спокойно выделить 10Gb оперативной памяти для виртуальной машины с FAST-ом или 128Gb на диск для демо машины от Microsoft.
Вот, не все моменты получилось осветить подробно. Но думаю, будет полезно тем, кто задумывается о том, как облегчить процесс разработки SharePoint решений.
Будет очень интересно услышать, если кто-то не согласен с доводами, приведенными в данной статье, и узнать, почему не согласен.
