online - sharepoint tutorial
Entornos de desarrollo/producción de SharePoint (3)
Uno de los mayores desafíos que he encontrado con SharePoint es que no se presta muy bien al entorno de proyecto típico, que, como mínimo, contiene entornos de desarrollo y producción. Los problemas con los que me he topado más son que el contenido y las listas están tan estrechamente unidos que dificultan realizar cambios de diseño sin realizar una congelación de contenido en el entorno de producción. Por ejemplo, si tengo una lista con columnas calculadas y deseo agregar alguna funcionalidad nueva, tendría que congelar el contenido en el servidor de producción, crear una plantilla de lista (incluido el contenido) del servidor de producción, restaurar esa lista al entorno de desarrollo, realice mis cambios y luego invierta el proceso de la plantilla de la lista. Lo mismo es cierto para las páginas y casi cualquier otra cosa en SharePoint. Parece que una vez que se despliega el sitio, es mejor trabajar directamente en la caja de producción, pero eso rompe una tonelada de mejores prácticas, por razones obvias.
¿Cómo manejan esta limitación algunos de ustedes otros desarrolladores de SharePoint?
Puede usar el Asistente de implementación de contenido ( http://www.codeplex.com/SPDeploymentWizard ) para migrar rápidamente cosas como listas y bibliotecas. También puede tomar una copia de respaldo / restauración de la producción, luego hacer los cambios en eso, y luego en las primeras horas de la mañana, congelar el contenido (ojalá a nadie le importe), importar todos los datos modificados de la producción a su copia y luego restaurar la copia sobre la producción. Al menos, la congelación podría posponerse y solo sería necesaria durante el procedimiento de exportación-> importación-> restauración.
En la práctica, solo hago mis cambios de producción a mano.
Use el código FeatureActivation para implementar cambios en los campos de las listas. Después de que el código actualice los campos, usted desactiva la función y la elimina. Esto permite que los resultados se prueben antes en un entorno de control de calidad.
En realidad, hay dos (¿más?) Niveles para el "desarrollo" de SharePoint. Tiene el código que se implementa en el servidor, como elementos web, tipos de contenido, acciones de flujo de trabajo, etc. Esto funciona relativamente bien en términos de implementación y mejores prácticas.
Luego tiene su ejemplo, que es más una personalización de las instancias del sitio. Lo que hemos hecho cuando tuvimos que personalizar un campo calculado en la lista del Directorio de sitios del portal, es intentar modificar los cambios en el desarrollo. A continuación, escriba las instrucciones detalladas de la personalización que se realizará, y tenga una persona separada con los permisos apropiados, use esas instrucciones para realizar el cambio en un servidor de integración (almacenamiento intermedio). Luego, haga que la misma persona haga los cambios en vivo en la producción.
No estoy seguro si sus cambios son susceptibles a este enfoque, pero vale la pena considerarlo.
Luego tenemos otro sitio que está muy personalizado con el diseñador de SharePoint, y aquel en el que trabajamos en vivo.