Cuando le preguntas a unos cuantos desarrolladores de SharePoint cuál es el entorno ideal te das cuenta de la cantidad de opciones que existen. Cada uno tiene sus preferencias y defenderá a muerte las virtudes de su elección, o la justificará en función de las limitaciones impuestas por su hardware o por la política de su empresa. Yo, como todos, tengo mis preferencias, y quería compartir con vosotros mis pensamientos al respecto.
Hasta hace relativamente poco trabajábamos en entornos de desarrollo de 32 bits, y no era posible instalar SharePoint en un sistema operativo cliente. Esto nos llevaba a dos opciones:
- Instalar Windows Server, SharePoint y Visual Studio en nuestra máquina física.
- Virtualizar utilizando Virtual PC o algún otro producto de terceros.
Con la aparición de Windows 7 y de Windows Server 2008 R2 surgió una nueva posibilidad, consistente en instalar directamente uno de estos sistemas operativos sobre un disco virtual (.VHD). Hace ya algún tiempo publiqué esta entrada acerca de cómo realizar este proceso. Desde que publiqué el artículo ésta ha sido mi elección, porque te da la mayoría de las ventajas de trabajar con un entorno virtualizado, a la hora que se salta la mayor de las limitaciones, a mi juicio. Esta limitación es, evidentemente, el hardware. Si tienes un sistema operativo instalado desde el cual haces funcionar máquinas virtuales una parte de tu memoria RAM total queda ocupada por el primer sistema operativo. Además, si necesitas acceder a dispositivos externos, en función del sistema de virtualización que estuvieras utilizando tenías unos problemas u otros. Con las características gráficas pasa algo similar. ¿Habéis probado a desarrollar algo para WPF, Silverlight o Surface desde una máquina alojada en un servidor de Hyper-V?
Hace unos meses me cotaba mucho convencer a alguien de que esta forma de trabajar era adecuada. Normalmente, la gente que trabajaba con productos de servidor, como SharePoint no solía necesitar altas capacidades gráficas, y en un portátil con 4GB, dedicando 2GB a SharePoint tenían de sobra, mientras que la gente que trabajaba con WPF, Silverlight o Surface no estaba acostumbrada a trabajar de manera virtualizada. Al final, los pocos privilegiados que, como yo, tenían la oportunidad de trabajar en los dos terrenos éramos los que más valorábamos esta nueva opción de virtualización.
Últimamente todo esto ha cambiado. Ya no hay evento al que asista en el que no se haga referencia a instalación de sistema operativo en disco duro virtual. ¿Qué es lo que ha cambiado? Para mí han habido dos elementos fundamentales: SharePoint 2010 y Visual Studio 2010. El primero de ellos es un producto con el que necesitaremos arquitecturas de 64 bits para trabajar, mientras que el segundo está desarrollado sobre WPF, con las necesidades gráficas que esto implica. Si bien es cierto que SharePoint 2010 se puede instalar (sólo algunas versiones) sobre un sistema operativo cliente (Vista o 7 –64 bits-), es importante disponer de un entorno lo más similar a lo que nos encontraremos en producción. Dicho todo esto, parece claro que las opciones más recomendables deberían ser:
Virtualizar utilizando Hyper-V o algún otro producto de terceros que soporte 64 bits. Instalar Windows 7 (o Vista), SharePoint y Visual Studio en nuestra máquina física. Instalar Windows Server, SharePoint y Visual Studio en nuestra máquina física. Instalar Windows Server, SharePoint y Visual Studio en un disco virtual. Yo, por lo que ya he explicado, me quedo con la última opción, pero estoy abierto a otras opiniones si me convencéis de sus ventajas respecto a mi elección.
Por cierto, ¿qué pasa cuando tenemos muchos VHDs creados para diferentes proyectos y queremos seleccionar uno de ellos a la hora de arrancar? Si habéis seguidos los pasos de la entrada que indico al principio de este post la pantalla de inicio de sistema únicamente indicará el nombre del sistema operativo. Para cambiar esto, la manera más fácil es utilizar el comando bcdedit. Si abrimos un comando de sistema privilegiado y ejecutamos el comando indicado nos aparecerá una lista de grupos como el siguiente:
Windows Boot Loader
-------------------
identifier {1bff685e-0067-11df-8690-e6a56e5f9542}
device vhd=[D:]\vhd\WS2008R2.40GB.FIXED.vhd
path \Windows\system32\winload.exe
description Windows Server 2008 R2
locale en-US
inherit {bootloadersettings}
recoverysequence {1bff685f-0067-11df-8690-e6a56e5f9542}
recoveryenabled Yes
osdevice vhd=[D:]\vhd\WS2008R2.40GB.FIXED.vhd
systemroot \Windows
resumeobject {1bff685d-0067-11df-8690-e6a56e5f9542}
nx OptOut
hypervisorlaunchtype Auto
ems Yes
Si queremos cambiar el nombre Windows Server 2008 R2 en la lista por WS2008R2 + SharePoint 2010, por ejemplo, ejecutaríamos:
bcdedit /set {1bff685d-0067-11df-8690-e6a56e5f9542} description "WS2008R2 + SharePoint 2010"
Pero, más fácil todavía, si arrancáis el sistema operativo el nombre del cual queréis cambiar, podéis utilizar este comando:
bcdedit /set {current} description "WS2008R2 + SharePoint 2010"
Así no tenéis que preocuparos por el GUID que necesitáis utilizar.
