La primera decisión que hay que tomar a la hora de diseñar la arquitectura de una solución basada en Sharepoint tiene que ver con la
estrategia de despliegue. Yo haría distinción entre tres métodos principales:
- Desarrollo Ad-hoc
- Site Templates
- Site Definitions
En mi opinión el desarrollo
Ad-hoc sólo está recomendado en casos muy concretos. O bien para prototipaje, de cara a conseguir mostrar funcionalidades de una manera muy rápida. O bien para aquellos casos en los cuales no se tenga una idea clara de a dónde se quiere llegar de manera que, se empieza con una base aceptable y, a partir de allí se crece de una manera un tanto anárquica pero ágil. En estos casos, la metodología de desarrollo es simple:
- Instalación del servidor de producción
- Implantación de Sharepoint
- Desarrollo directo sobre ese servidor
Las mayores desventajas de este método son, el nulo reaprovechamiento del trabajo realizado y el enorme riesgo que se corre al trabajar directamente sobre un servidor en producción.
Una extensión de esta aproximación consiste en el uso de los comandos
import y
export o incluso
backup y
restore. Si bien la primera de las dos parejas de comandos se podría aceptar como método de despliegue (
backup y
restore bajo ningún concepto), este tipo de operaciones nos puede provocar problemas si utilizamos entornos de desarrollo y de producción ligeramente diferentes.
Aquí entran en juego los elementos más propios de una estrategia de despliegue: S
ite Templates y
Site Definitions. Ambos conceptos están relacionados con el despliegue de soluciones basadas en Sharepoint, y cada uno de ellos está indicado para un tipo de proyecto diferente. En mi humilde opinión, un
Site Template sólo está indicado cuando no tenemos tiempo de crear un
Site Definition (y aún esto es relativo, puesto que el tiempo se recupera a la larga). Los
Site Templates tienen mucho éxito porque son muy fáciles de crear y de desplegar, ya que se pueden realizar todas las personalizaciones que se deseen sobre un sitio de Sharepoint y después grabarlo como fichero utilizando únicamente la interfaz de usuario de Sharepoint. Por otro lado, las deficiencias que presenta esta solución son varias, por ejemplo:
- Aplicable únicamente a sitios, y no a colecciones de sitios
- No extensibles
- Tamaño máximo
- Uso de referencias hardcoded a urls
- Etc.
A diferencia de un Site Template, un Site Definition requiere algo más de trabajo, y la utilización de Visual Studio. Actualmente existen muchas herramientas que nos ayudan en la creación de estos, pero aún así, los conocimientos que se requieren son elevados. ¿Merece la pena realizar el esfuerzo? Dependerá del tipo de proyecto y de vuestra experiencia en el diseño de soluciones basadas en Sharepoint pero, la respuesta por defecto es: sí.
Como todo, también tiene sus puntos negativos:
- Tiempo requerido para su creación
- Control de errores complejo
- Alta curva de aprendizaje
De todo lo que he dicho se podría deducir que mi consejo es el uso de Site Definitions, y así es. Continuaré escribiendo sobre este tema en los próximos posts para dar algunas pistas sobre la manera en la que yo trabajo con ellos y la evolución que han tenido mis diseños de soluciones desde que empezara hace unos 4 años con Sharepoint 2003 hasta el día de hoy.
0 comentarios:
Publicar un comentario