2008-10-23 11 views
5

Así que, tal vez soy un poco de la vieja escuela, pero cuando creamos sitios web en el pasado, desarrollamos el sitio en un servidor de desarrollo, luego publicamos o promocionamos las páginas y archivos al servidor de producción. Esto siempre parece ser un buen camino a seguir para que los usuarios no vean páginas arruinadas o (Dios no lo quiera) un servidor caído porque uno de nosotros nos equivocamos.Promoción de sitios de MOSS '07 de Dev a producción

Pero parece que Microsoft no tenía esta idea en mente cuando crearon SharePoint ... al menos, no he podido encontrar la manera de hacerlo en la infraestructura tal como está definida.

¿Alguien sabe si hay una estrategia de administración para el desarrollo de SharePoint? He leído en línea que podemos hacer una copia de seguridad del entorno de desarrollo y restaurar al servidor de producción. Eso podría funcionar la primera vez, pero las actualizaciones del servidor de producción no pueden hacer eso sin arriesgar la pérdida de datos en el servidor de producción. He visto algunas herramientas para migrar contenidos de la lista, páginas y documentos de un servidor a otro, aunque debo admitir que aún no los he investigado.

Pero, otra preocupación mía es el tipo de contenido personalizado. Parece que una vez que una lista utiliza un tipo de contenido, no puede actualizarlo sin eliminar los elementos de la lista, desasociar el tipo de contenido y reasociar el tipo de contenido. ¿No debería haber alguna forma de ACTUALIZAR un tipo de contenido?

De todos modos, si tiene alguna sugerencia para cualquiera de estos dilemas actuales, ME ENCANTARÍA saber de usted.

Gracias de antemano,

Dan


Gracias por su rápida respuesta.

Ya tenemos varias características creadas para nuestro sitio y un paquete de soluciones que agrupa funciones dirigidas a los fundamentos (tipos de contenido, columnas, etc.) y otra solución para las características relacionadas con la marca (diseños de página, páginas maestras, etc. .)

Pero parece que se trata de una sola vez ... básicamente, configura nuestro servidor, ¿verdad? Una vez que las personas hayan comenzado a usar el entorno de producción, tendremos documentos, páginas, elementos de lista que estarán en nuestra base de datos de contenido y será imposible actualizar cosas como tipos de contenido, columnas.

Funciones que debe desactivar y desinstalar antes de poder instalar y activar la nueva característica, ¿no? He visto una propiedad de versión en la definición de la característica, pero por lo que puedo decir, esto no hace nada. Parece que las soluciones se pueden actualizar incrementando el número de versión, pero no parece modificar cosas como los tipos de contenido y las columnas, especialmente si están en uso. Además, no estoy seguro de cuán extensa es la actualización con soluciones.

Hay muy poca documentación para este tipo de cosas. Parece que todo lo que estoy leyendo es cómo configurar inicialmente tu servidor de SharePoint ... no a largo plazo.

¿Tiene algún consejo o sugerencia?


Gracias a todos por sus sugerencias.

Pero llevamos más de un año trabajando en este sitio. Estoy bastante seguro de que ya estamos configurados de acuerdo con lo que la mayoría de ustedes recomiendan.Ya tenemos varias características que instalan cosas como tipos de contenido, columnas, páginas maestras, diseños de página y flujos de trabajo. La mayoría de estas características están contenidas en paquetes de soluciones. Tenemos todos nuestros entornos de desarrollo configurados como servidores VPC.

Por lo tanto, tengo la implementación inicial prácticamente establecida. Lo que REALMENTE estoy esperando saber es cómo puedo actualizar cosas como tipos de contenido y columnas y cosas en el futuro. ¿Es posible cambiar los tipos de contenido una vez que están en uso? Porque no parece, basado en mi prueba inicial, que esto sea posible. No me preocupan las asambleas porque parece que cambian muy bien, pero la única forma en que he actualizado un tipo de contenido es eliminando los elementos que hacen referencia a ellos (es decir, todas las páginas de la biblioteca de mi página), eliminando el tipo de contenido, luego volver a agregarlo.

¿Alguno de ustedes sabe si hay una manera de actualizar un tipo de contenido después del despliegue inicial? ... cuando los usuarios ya han creado elementos basados ​​en los tipos de contenido que ya hemos implementado?

(La otra parte de mi pregunta estuviese desplazándose hacia las páginas existentes desde el servidor de desarrollo de la producción, pero puedo vivir sin eso. Mi mayor preocupación es los tipos de contenido.)

Respuesta

5

El mejor camino a seguir está desarrollando con características. Una vez que las funciones están listas, puede desplegarlas con el paquete de Solución (llamado WSP).

Lo único que queda por hacer es reactivar esas funciones. De esta forma, puede implementar progresivamente nuevas funciones sin tener que hacer todo en producción.

WSPBuilder es una aplicación que le ayuda a construir el PAS.

Para automatizar todo esto ... buena suerte. Hay mucho trabajo involucrado.

ACTUALIZACIÓN: Desplegar tipos de contenido y columnas son complicados. Una vez que el sitio web ha sido creado, ya no puede actualizarlos mediante funciones. Debe revisar el código y recorrer de manera recursiva todos los sitios y modificar el tipo de contenido específico que coincida con el nombre.

Hemos intentado y no es posible hacerlo normalmente con características. Esta necesidad de pasar por algo que yo llamo "implementar con código".

1

Yo recomiendo echar un vistazo a Chris O'Brien cargo más reciente, y su gran Asistente para la distribución de contenido: it's not all about Features!

+0

Gracias ... Lo verificaré. ¿Lo has usado anteriormente? ¿Sabes si funciona bien? – Dan

+0

¡Sí, funciona genial! –

1

Maxim tiene razón en que la mayoría de los artículos deben ser desplegadas a través de características que se envuelven en soluciones (archivos WSP) Su estrategia debe ser asegurarse de que sus soluciones y ensamblajes estén divididos en partes relacionadas de funcionalidad. Esto también es beneficioso porque las características se pueden aislar en ciertos niveles, como sitios y redes. El código de activación de funciones, el código de desactivación y el engrapado de funciones se deben usar al actualizar las actualizaciones de contenido. La implementación de contenido también puede tener sentido.

Una vez que hay que recordar es que si los cambios son sólo en código a continuación, los conjuntos se pueden actualizar sin necesidad de la característica de ser reactivado o la solución retraída y redistribuido. Todo lo que se requiere es que se restablezca el grupo de aplicaciones.

Microsoft tiene un par de artículos sobre entornos de desarrollo y puede buscar en Google a muchos otros que recomiendan entornos. Desarrollamos en máquinas virtuales e implementamos la mayoría de los artículos en un servidor de integración virtual. Una vez que probemos humo, implementamos nuestras soluciones para control de calidad, etcétera. El beneficio es que las características y soluciones son fáciles de retraer. Una vez que sale a producción, debe ser ampliamente probado.

Desarrollar en SharePoint tiene sus problemas, por supuesto, pero Hasta ahora He encontrado que los beneficios superan los problemas.

Team-Based Development in Microsoft Office SharePoint Server 2007

2

Usted realmente necesita para definir los tipos de contenido usando una característica porque de esa manera cada tipo de contenido tendrá un GUID set y se almacena en la base de datos con el mismo nombre. Esto se vuelve importante cuando se ejecutan consultas de CAML en el sitio y hay algunos otros pequeños problemas cuando los tipos de contenido se crean "de todos modos" si se quiere.

Prefiero STSDev para implementar soluciones con tipos de contenido personalizados.

Hay dos formas de editar páginas en el servidor. Puede definir que la biblioteca de páginas tenga versiones principales y secundarias. Esto permite a los editores editar la página y un editor definido para publicarlos. Esto es bueno en un sitio interno, pero no se recomienda para un sitio público.

Para un sitio del lado público tendrá que utilizar Content Deployment

No puedo hacer suficiente hincapié en que antes de seguir adelante con una versión de producción a asegurarse de que tiene características para los tipos de contenido.

Como se menciona aquí, Chris O'Brian tiene una publicación que dice que no debe usar funciones a menos que sea necesario. Una de sus razones es que ralentiza el desarrollo.

No estoy de acuerdo con esto. El desarrollo es más lento si no está familiarizado con las características, pero una vez que se alcanza un nivel de conocimiento, no es un factor importante.

Hazle caso acerca del método de copia de seguridad y restauración para mover el contenido. Si haces eso, todo el desorden en los tipos de contenido y campos y webs que hayas creado durante el desarrollo (para mí, que siempre es bastante) se moverán a tu sitio de producción.

En lugar de tener un sitio agradable y limpio donde todo es coherente, terminará con pequeños errores y algunas áreas del sitio se comportan de manera diferente a los demás simplemente debido a un desarrollo antiguo.

0

Desarrollamos una solución personalizada que actualizaría los tipos de contenido y los campos de una Colección de sitios. Debajo de las portadas, a través del código, SharePoint nos permite modificar los Campos, así como los valores en los Campos y los tipos de Contenido de Sitio/Lista.

Para mover el contenido real de QA a Prod utilizamos Echo

+0

La pregunta era sobre mover los sitios de MOSS 2007 de Dev a Production y no sobre las personalizaciones que se mueven de Dev a Production. Curiosamente, el que obtuvo los puntos maximium es el que ha dado una respuesta diferente y obtuve -1 por participar aquí. Gracias ... – Ganesha

Cuestiones relacionadas