SharePoint 2010: Establezca el entorno adecuado
La forma en que configuramos los entornos de desarrollo, pruebas y procesos puede tener un impacto enorme en las aplicaciones.
Steve Wright y Corey Erkes
Adaptado de "Pro SharePoint 2010 gobernanza" (Apress, 2012)
En el transcurso de cualquier proyecto de desarrollo grande, usted necesitará gestionar diferentes tipos de información. Es preferible tener un repositorio central de información que se integra con las otras herramientas utilizadas por el equipo de desarrollo.
Existen varios productos para ayudar a sus equipos de desarrollo, colaborar y comunicarse, y Microsoft Visual Studio Team Foundation Server (TFS) tiene ventajas cuando se utiliza para el desarrollo de SharePoint. Está estrechamente integrado con Visual Studio y SharePoint. Si su organización ya no tiene una herramienta y va a desarrollar aplicaciones para el entorno Microsoft Windows, usted debe considerar TFS.
Independientemente del producto y el método que elija, hay algunas características que debe tener tal plataforma, incluyendo:
- **Control de código fuente:**Esto mantiene un registro de cada cambio para cada archivo de código fuente en la solución. Versiones de la biblioteca de SharePoint no es apropiado para ello. Un sistema de control de la verdadera fuente soporta muchas características más allá de una sola secuencia de cambios en el archivo de seguimiento.
- **Gerencia del requisito:**Esto remonta cada error, trabajo y el archivo de código fuente artículo hacia los requisitos a los que se relaciona.
- **Seguimiento de elementos de trabajo:**Esto registra los informes de fallos, entradas de escritorio de ayuda, peticiones, comunicados y tareas asociadas con el proyecto.
- **Construcción de automatización:**Esto compila los archivos de origen en los archivos de solución desplegables.
- **Gestión de prueba:**Esto registra casos de prueba automatizados y manuales, automatiza la regresión y pruebas unitarias, gestiona la implementación para probar servidores y realiza pruebas de carga.
No todas las plataformas de desarrollo de equipo apoyará todas estas características. Sin embargo, el control de código fuente es una función que es absolutamente necesaria mantener una aplicación estable base. Las otras funciones pueden ser más o menos importantes a una determinada organización. También puede ser aceptable utilizar herramientas separadas, no integradas para esas funciones.
Entornos de desarrollo
Uno de los aspectos más difíciles del desarrollo de SharePoint es establecer un entorno de desarrollo productivo. Esto se refiere a la zona donde un desarrollador individual puede trabajar para crear y depurar sus componentes asignados o actualizaciones. SharePoint es una tecnología de servidor, por lo cual componentes diseñados para ejecutarse en un servidor de SharePoint generalmente deben ser desarrollada en uno.
Un error común es tener un "servidor de desarrollo" utilizado por todos los desarrolladores del equipo. A menos que los miembros del equipo están trabajando en componentes totalmente sin relación y nunca necesitan hacer común cosas tales como reiniciar IIS o asociar a un depurador a un proceso IIS, este tipo de ambiente generalmente no funciona bien. Los desarrolladores tienen control total sobre el servidor para depurar eficazmente problemas. Aislar a los desarrolladores de uno con el otro es la mejor forma de mantener a todo el mundo productivo.
Otra idea falsa es que puede convertirse en un sistema cliente Visual Studio y depurar en un servidor remoto que ejecute SharePoint. Mientras que puede depurar una solución SharePoint en otro servidor, todavía debe tener SharePoint instalado en el sistema de compilación de código de servidor de SharePoint. Las bibliotecas que utiliza el código del lado del servidor están disponibles sólo en un servidor de SharePoint. No tienes instalado por separado en un equipo cliente para permitir que el código compilado. Si está desarrollando aplicaciones de cliente utilizando sólo el nuevo cliente modelos de objetos (cliente OMs) presentó con SharePoint 2010, se puede compilar en un sistema que no tiene SharePoint instalado.
Un entorno de desarrollo de SharePoint mínimo debe incluir lo siguiente:
- Un OS de Windows de 64 bits compatible con SharePoint 2010 (Windows 2008, Windows Vista SP1 o Windows 7)
- Visual Studio 2010
- SQL Server Express
- SharePoint Foundation o servidor componentes según sea necesario
Las siguientes herramientas son a menudo útiles y debe incluir estos siempre que sea posible:
- Aplicaciones de Microsoft Office
- SQL Server Edición para desarrolladores
- Microsoft Visio
- Diseñador de InfoPath
- SharePoint Designer (descarga gratuita)
También tienes varias opciones a tener en cuenta con respecto a donde instalar estas herramientas. La primera y más sencilla opción es cargar todas las herramientas y SharePoint directamente en la computadora del desarrollador. Esto requiere un sistema operativo de 64 bits compatible con SharePoint. Esta configuración es fácil de usar porque todas las herramientas necesarias están disponibles.
Desafortunadamente, esta configuración está limitada por el poder de la computadora de escritorio, el almacenamiento de la unidad de disco duro y el hecho de que sólo se puede utilizar una configuración de SharePoint. Un desarrollador que con frecuencia se mueve entre proyectos podría encontrar este tipo de configuración difíciles de manejar.
Opciones del entorno de desarrollo
La siguiente opción es utilizar un producto de virtualización de escritorio como Oracle VirtualBox o VMware Workstation. Una vez más, debe ser cierto que cualquier herramienta de virtualización que utilizas soporta a un invitado de 64-bit OS. Esta configuración tiene muchas de las mismas limitaciones que instalar directamente el medio ambiente en el escritorio. Por lo general, rendimiento no es muy bueno y que necesitará archivos de disco grande para soportar la virtualización de escritorio.
La ventaja de este tipo de entorno es que le permite albergar múltiples configuraciones de SharePoint en distintas máquinas virtuales (VMs) en el mismo escritorio. Por lo general, requisitos de memoria y rendimiento no permiten ejecutar más de una VM al mismo tiempo, sin embargo.
También puede crear un archivo de disco duro virtual (VHD) y ejecutarlo directamente en el sistema sin pasar por un producto de virtualización de escritorio. Esto es similar a la antigua configuración "dual-boot" para un sistema. En lugar de utilizar una partición separada para el segundo sistema operativo, se usaría un archivo VHD dentro del sistema de archivo de sistema operativo existente. Esta configuración tiene la ventaja de usar todo el hardware de sistema sin necesidad de un segundo so en ejecución para el servidor de desarrollo.
La única desventaja es que cualquier aplicación cargada en el sistema operativo del cliente de este ordenador de sobremesa no disponible mientras se ejecuta el entorno de desarrollo. Se está convirtiendo la configuración más popular para los desarrolladores de SharePoint ya que proporciona la flexibilidad de la virtualización de escritorio sin incurrir en los costos de funcionamiento. Para obtener más información sobre la ejecución de múltiples sistemas operativos con la nueva configuración de arranque de Windows 7, consulte el blog de Keith Combs post, "doble arrancar desde el disco duro virtual con Windows 7 y Windows Server 2008 R2."
La configuración final utiliza la virtualización de servidores. Esto podría ser Microsoft Hyper-V, VMWare o cualquier otro producto de virtualización de servidores. Esta es una excelente opción para una empresa con una infraestructura de virtualización buena. Aprovisionado de una máquina virtual en un servidor VM y utilizar ese servidor para albergar el entorno de desarrollo completo.
Utilizando a un cliente de Remote Desktop Protocol (RDP), el desarrollador tiene acceso a un completo entorno sin realizar cambios o instalaciones en su entorno local. La única desventaja con esta configuración es que usted debe ser capaz de conectarse al servidor VM para realizar tareas de desarrollo. Usted no puede "llevar con usted."
Entornos de prueba
Una vez completada la desarrollo, tendrás que poner la aplicación a través de un régimen de prueba rigurosa, bien definido. Esto requiere que usted carga en uno o varios entornos ajenos a la producción antes del despliegue de producción. Estos ambientes se van por muchos nombres incluyendo integración, prueba, etapa, pruebas de aceptación y usuario (UAT), preproducción y así sucesivamente.
Puede usar una granja de integración para probar todos los componentes compilados en un entorno que no contiene ninguna herramienta de desarrollo. La presencia de Visual Studio u otras herramientas de desarrollo de un sistema a veces puede enmascarar los errores que ocurren sólo cuando estas herramientas no están disponibles.
Una vez que se prueba la liberación, entregarlo al grupo de aseguramiento de calidad, o cualquier departamento es responsable de la UAT. Luego ese grupo prueba cargará la liberación a la granja de preproducción. Esta finca debe ser lo más similar a la granja de producción como sea posible para ayudar al grupo prueba evaluar la disponibilidad de la producción de la liberación.
Por ejemplo, si la finca de producción tiene varios servidores front-end de la Web, por lo tanto, también debe la granja de preproducción. Servidores virtuales se sustituyen a menudo por servidores físicos hacer más rentable los entornos de prueba. Una vez completada la UAT, puede implementar la aplicación a la granja de servidores de producción final.
Al probar una nueva versión, es importante utilizar contenido como algo similar al contenido en la producción como sea posible. Por ejemplo, si un usuario ha modificado para requisitos particulares cierto artículo en un sitio en la granja de producción que interfiere con un cambio realizado en la aplicación, usted podría no notar si el cambio es solo probado contra datos de prueba "falso". Una excelente fuente de datos de contenido realistas para la prueba es el conjunto de servidores de producción. Puede fácilmente copias de seguridad y restaurar las bases de datos de contenido de producción en los entornos de prueba en la mayoría de los casos.
Otra configuración común para probar e implementar aplicaciones de SharePoint es utilizar un conjunto de servidores puesta en escena. Con esta técnica, hay dos granjas de servidor completo funcionando en todo momento. Sus usuarios utilizan uno y el otro está parado recibir la nueva versión. Una vez que la liberación se implementa en la puesta en escena de la granja, la red se reconfigura para enrutar el tráfico entrante a la puesta en escena de la granja. Así, los servidores de la puesta en escena se convierten en la producción y los servidores de producción cambie a la puesta en escena.
Se trata de una técnica útil para sitios dirigido al público en el que usted no puede permitir tiempo de inactividad. El tiempo necesario para intercambiar las granjas del servidor sólo es siempre que sea necesario para desviar el tráfico de red. Obviamente, es vital que todas las actualizaciones de contenido de producción son trasladadas a la granja provisional antes de desplegar la nueva versión. Para evitar las actualizaciones después de que el contenido comienza a copiarse, SharePoint le permite temporalmente bloquear contenido bases de datos.
Cuando se utiliza esta técnica, el puesta en escena de medio ambiente también puede servir como un caliente en espera para la granja de producción. Si la producción sufre una falla catastrófica, rápidamente puede traer para arriba el servidor en restaurar el servicio. Si se trata de parte de su plan de recuperación de desastres, usted regularmente debe copiar contenido de producción a la granja de la puesta en escena, incluso cuando usted no implementar nuevas versiones. También sería útil que las granjas de puesta en escena y producción alojadas en distintas ubicaciones físicas para proporcionar redundancia de ubicación. Cualquiera de estas técnicas y configuraciones puede ayudarle a desarrollar un entorno de desarrollo de SharePoint que mejor se adapte a sus necesidades y recursos.
.jpg)
Steve Wright es Gerente en la gestión de inteligencia empresarial (BIM) para Sogeti USA LLC en Omaha, Nebraska. En los últimos más de 20 años, Wright ha trabajado sobre control del tráfico aéreo, financiero, seguros y una multitud de otros tipos de sistemas. Él es autor y realizar revisiones técnicas para muchos títulos anteriores que abarca productos de Microsoft, incluyendo Windows, SQL Server , SharePoint y BizTalk.
.jpg)
Corey Erkes es Consultor Gerente de Sogeti USA LLC en Omaha, Nebraska. Erkes ha trabajado con una amplia gama de empresas en diferentes puntos de los ciclos de vida de sus implementaciones de SharePoint. También es uno de los miembros fundadores del grupo de usuarios de SharePoint de Omaha.
© 2012 Apress Inc. Todos los derechos reservados. Impreso con permiso de Apress. Copyright 2012. "Pro SharePoint 2012 gobernabilidad" por Steve Wright y Corey Erkes. Para obtener más información sobre este título y otros libros similares, por favor visite apress.com.