Estos últimos meses he estado bastante ocupado y la verdad es que apenas he tenido tiempo de investigar un poco con la nueva versión de SharePoint Server. 
Ya está disponible la versión RTM, así que es tiempo de bajarla, montarla en una máquina virtual y sacar conclusiones :)
Si aún no la habéis obtenido, podéis hacerlo a través del siguiente enlace: http://technet.microsoft.com/en-US/evalcenter/hh973397
El equipo de producto ha liberado el nuevo CU de SharePoint 2010 de Octubre de 2012.
Una vez instalado, hay que:
Si en el post anterior vimos cómo configurar el entorno de TFS y el Servidor de SharePoint para permitir la ejecución remota de scripts de PowerShell, ahora vamos a ver cómo realizar en un siguiente paso dentro de una Build de TFS el despliegue automatizado.
La idea es la siguiente: generar un paquete, o paquetes en la Build, y llamar a un script “maestro” de PowerShell que se encargue de lanzar una llamada al script de despliegue de dichos paquetes. Gráficamente, esto es lo que queremos conseguir:
El Script Maestro, va a ser genérico, por lo tanto habrá unas cuantas reglas que se deberán cumplir, como por ejemplo, que el nombre del script de despliegue sea “Install.ps1”, aunque podremos cambiarlo.
El script de deploy, que se desplegará con el resto del paquete en la máquina de SharePoint, podrá tener lo necesario para ejecutar el despliegue.
La generación de paquete es importante, ya que si se sigue un cierto orden, este mecanismo de despliegue puede ser válido para los proyectos que se desee. Un ejemplo de un paquete generado por la Build es el siguiente:
En este paquete por ejemplo se incluye una documentación, el paquete de solución WSP, un archivo de configuración del que se alimenta el script de “Install.ps1”, y un script común con funciones genéricas.
En Visual Studio, se podría organizar el proyecto de la siguiente forma:
No voy a entrar a detallar cómo organizar un proyecto, porque cada uno tendrá su propia metodología o estará mas acostumbrado a realizarlo de otra forma. De cualquier manera, la idea del despliegue automatizado sigue siendo igual de válida.
Bien, lo que haremos será generar una nueva plantilla para Build de TFS:
Dentro de la secuencia principal, vamos a entrar en la de Run On Agent, para añadir dos secuencias más:
Después de la secuencia de Try, Compile and Test, vamos a añadir la secuencia de generar el paquete, y posteriormente la de lanzar el despliegue automatizado, similar a la siguiente:
No voy a describir entero el proceso de crear el paquete de despliegue, pero el objetivo es generar una carpeta de deploy, que contenga lo necesario para el despliegue, como vimos en el dibujo anterior. Un ejemplo podría ser:
Yo recomiendo generar tantas secuencias como sean necesarias a fin de que podamos hacer seguimiento de cada una de forma cómoda.
Es importante que de las secuencias anteriores, creemos el directorio donde se dejarán los ficheros. La variable que creemos para generar el directorio debería ser similar a la siguiente:
Es importante que indiquemos a la Build que queremos generar los paquetes WSP. Para ello, hay que indicar en su atributo MSBuild Arguments lo siguiente:
El resto de ficheros basta copiarlos usando las secuencias de FindMatchingItems y la de InvokeProcess llamando a “xcopy.exe” para copiar al “PackageFolder” que se definió en la variable anterior.
Ahora, para configurar la secuencia de despliegue automático, hay que indicar en qué ruta vamos a dejar el script maestro de instalación. Por ejemplo de la siguiente manera:
Dentro de la secuencia tendremos un proceso de invocación como el siguiente (InvokeProcess):
Con una configuración similar a la siguiente:
De tal forma que se llame al script maestro, indicando la máquina donde se va a realizar el despliegue, y la ruta del paquete que contiene los ficheros. En este caso yo el paquete lo estoy generando en la máquina de SharePoint en lugar de generarlo en la de TFS.
Es necesario el nombre de la máquina de SharePoint para iniciar una sesión de PowerShell remota sobre ella.
De tal forma que nuestro script maestro de PowerShell puede ser similar al siguiente:
Es importante dar permisos de administrador a la cuenta de usuario que ejecuta el proceso de Build en la máquina de SharePoint, para que deje ejecutar el script.
Este proceso, es bastante complejo y no sale bien siempre a la primera. Lo ideal es ir poco a poco partiendo de lo más básico y si es necesario ir metiendo trazas de mensajes en el WorkFlow de la plantilla de Build.
Los problemas suelen venir por la configuración de permitir la ejecución de scripts de forma remota (que lo vimos en el post anterior), por la configuración de las llamadas a los scripts maestros (si no se escapan bien las dobles comillas, se puede romper la llamada al script), y por los permisos del usuario de TFS sobre la máquina de SharePoint, que pueden no ser suficientes para permitir ciertas acciones, y habrá que asignarlos manualmente.
Con este post se cierra el tema de los despliegues automatizados. Espero que os sirva de ayuda.
