SharePoint 2010: Prepare a su equipo
Seleccionar y crear la estructura del equipo de desarrollo adecuado son fundamental para el exitoso desarrollo de soluciones de SharePoint.
Steve Wright y Corey Erkes
Adaptado de «Gobierno Pro SharePoint 2010» (Apress, 2012)
Uno de los aspectos más flexibles de SharePoint como una plataforma de colaboración es la capacidad de preparar e implementar aplicaciones de negocio personalizado. Esto puede ser un proceso complejo. Hay muchas opiniones diferentes sobre el tamaño y estructura de su equipo de desarrollo de la solución de SharePoint más eficiente y eficaz.
Los defensores del desarrollo de soluciones ágiles prefieren equipos más pequeños porque regular comunicación uno-a-uno se considera un aspecto esencial del proceso. Grandes proyectos de desarrollo, un equipo más pequeño puede no proporcionar la suficiente capacidad para satisfacer la necesidad de nuevas funcionalidades. En este caso, asignar múltiples pequeños equipos es generalmente más eficaz que un solo equipo cada vez más grande.
Planificación y asignación de una división del trabajo entre varios equipos se convierte en esencial. Existen tres formas principales de la estructura de varios equipos de desarrollo de soluciones de SharePoint:
- Estructura de equipo paralelo
- Estructura lineal
- Estructura del equipo basado en componentes
Recuerde que en SharePoint, un paquete de solución es la unidad de implementación. Mientras que usted y sus equipos pueden crear un paquete de solución masiva solo para una aplicación de gran tamaño, es preferible para romperlo en varios paquetes relacionados que puede probar y versión individualmente.
Estructura de equipo paralelo
La primera estructura de equipo es uno de los diferentes equipos de trabajo en paralelo para crear un conjunto de paquetes de soluciones que conforman la versión final. Cada equipo es responsable de uno o más paquetes de soluciones. Funciones dentro de estos paquetes pueden depender de uno a otro, pero que no dependen de paquetes producidos por otro equipo.
Una estructura paralela funciona mejor cuando puede interrumpir la funcionalidad de la aplicación en aplicaciones más o menos independientes. Cada equipo crea unidad de pruebas y sus propios componentes y comprueba en el control de código fuente. El automated proceso de construcción combina los paquetes de varios equipos en una sola versión. Este proceso permite a los equipos trabajar independientemente de la otra parte del tiempo con un mínimo de coordinación necesaria entre los equipos durante el desarrollo.
Estructura lineal
La siguiente estructura que podría considerar es una estructura lineal, o capas, del equipo. En este caso, cada equipo es responsable del desarrollo de la funcionalidad en una capa de la aplicación. Por ejemplo, puede que tres equipos de desarrollo de paquetes de soluciones que se capas juntas. Equipo 1 crea la capa del marco inferior y los controles en el control de código fuente. Equipo 2 recupera las soluciones de equipo 1 y utiliza como un marco o conjunto de herramientas para la construcción de la capa siguiente hasta la pila. Equipo 2 pasa la segunda capa de componentes para equipo 3.
Una estructura lineal es ideal para situaciones donde se construye una aplicación en capas de abstracción o marcos. SharePoint sí es un buen ejemplo de este tipo de diseño. Las características que hacen de SharePoint Foundation crean una capa de herramientas que pueden utilizar otras aplicaciones basadas en SharePoint.
Un ejemplo de una aplicación creada con este kit de herramientas es SharePoint Server 2010. El producto de servidor es realmente sólo un conjunto de componentes construida sobre la base proporcionada por SharePoint Foundation. Microsoft Project Server y Microsoft CRM son otros ejemplos de soluciones construidas con este proceso de desarrollo.
Al desarrollar soluciones en capas, cada capa será generalmente depende de las características proporcionadas en niveles inferiores de la pila. Estas dependencias pueden declararse en las soluciones y funciones que se desarrollan para garantizar que se cumplen todos los requisitos previos al activar una función en un sitio de SharePoint.
Estructura del equipo basado en componentes
Considerando que los enfoques paralelos y lineales separan el desarrollo mediante la asignación de paquetes de soluciones a los diferentes equipos, hay casos donde esto simplemente no es posible. En este caso, usted y sus equipos que deba adoptar un enfoque basado en componentes. Este tipo de estructura asigna como elementos Web, formas, flujos de trabajo y similares a varios equipos. Independientemente son probados y comprobados en el control de código fuente. Sólo entonces se empaquetan los componentes para su entrega.
Este tipo de estructura es muy flexible porque puede mover componentes de un equipo a otro según sea necesario sin afectar el empaquetado de la aplicación. Desafortunadamente, esto también hace los equipos interdependientes.
Equipos trabajando en los mismos paquetes de solución necesitan para asegurarse de que cualquier cambio que pueda afectar a componentes desarrollados por otros equipos se comunica claramente. Pruebas de integración basado en ejecutar los paquetes finales es fundamental en este tipo de ambiente. La fuente más probable de fallos en cualquier sistema es en cada límite entre componentes desarrollados por diferentes equipos.
Estrategia de desarrollo de equipo
Hay varias otras consideraciones a tener en cuenta al trazar su estrategia de desarrollo del equipo:
- ¿¡ Que cada equipo tendrá un horario de compilación automatizada independiente?
- ¿Cada equipo tendrá una granja de pruebas de integración independiente, o todos ellos compartirán una sola granja?
- ¿Cómo se piensa comunicados para que cada componente que se completará en el orden necesario por otros equipos que dependen de él?
- ¿Cuánto la comunicación es necesaria dentro de y entre los equipos?
- ¿Estarán todos los equipos en la misma ubicación física?
- ¿Quién es responsable de la versión final antes de la entrega de pruebas de aceptación de pruebas de integración?
Por supuesto, como aplicaciones más grandes y más complejos, es probable que ninguna estructura de equipo solo será suficiente. Un enfoque híbrido utilizando una combinación de paralelo, lineales y basadas en componentes de equipos se convertirá en la norma en grandes organizaciones.
El equipo de Gobierno debe garantizar que todos los equipos entiendan sus responsabilidades asignadas. Deben garantizar que los equipos realizan pruebas rigurosas en las soluciones antes de implementarlas en SharePoint.
.jpg)
Steve Wright es un directivo en la gestión de inteligencia empresarial para Sogeti USA LLC en Omaha, NEB. Durante los años de la última medioambientalista, Wright ha trabajado en control del tráfico aéreo, financiero, seguros y multitud de otros tipos de sistemas. Él es autor y realizar revisiones técnicas para muchos títulos anteriores para los productos de Microsoft, incluyendo Windows, SharePoint, SQL Server y BizTalk.
.jpg)
Corey Erkes es Consultor Gerente Sogeti USA LLC en Omaha, NEB. 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.
© 2011 Apress Inc. Todos los derechos reservados. Impreso con permiso de Apress. Copyright 2012. «Pro SharePoint 2012 Gobierno» por Steve Wright y Corey Erkes. Para obtener más información sobre este título y otros libros similares, visite por favor apress.com.