Sitecore environments

Question

El sitio web de nuestra organización se está mudando a Sitecore CMS pero estamos luchando con la configuración de entornos para Desarrolladores (4), Diseñadores (4), Aseguradoras de calidad (3), Autores (10-15) y Aprobadores (4- 10) de manera que puedan trabajar de forma independiente, sé que habrá dependencias, pero la idea es minimizarlas.

Éstos son par de reglas:

1) Quien es el responsable del cambio, entonces deberían hacerlo todo hasta que ya menos que haya ninguna dependencia.

2) Si un equipo está trabajando en una característica, entonces no debería detenerse o efectuar el trabajo de otro equipo. Por ejemplo, si QA está probando la característica, los Derringers y los Desarrolladores deberían continuar su trabajo en la misma función para las nuevas mejoras.

Cuestiones relacionadas con los entornos:

1) donde los diseñadores trabajarán? Me refiero a dónde agregarán sus html, js e imágenes? ¿En que servidor? En Sitecore? En Source Control (TFS)?

2) ¿Cómo deben trabajar juntos los diseñadores y desarrolladores? Sé que los desarrolladores trabajarán en sus máquinas locales en Sitecore. Y promocionará su trabajo al servidor de Integración, pero ¿cómo van a hacer que los diseñadores se encarguen de todo? Supongamos que la función ha entrado en producción con éxito; ahora solo se requieren cambios en el diseño de gráficos, por ejemplo, estilos de fuente y algunas imágenes, ¿dónde deben hacer los diseñadores los cambios? En que servidor? Y después de eso, cómo la instancia de Sitecore se sincronizará con otras instancias de Sitecore. Y para los cambios de diseño, no quiero que los desarrolladores promocionen ningún código o archivo.

3) ¿Cuál es la forma más segura de sincronizar el entorno/bases de datos Sitecore? Significa que todo lo que se haya publicado en el sitio web de producción lo necesitaremos en entornos DEV, QA y UAT.

No queremos hacer ninguna promoción manual de código, html, js y archivos de imagen. ¿Hay alguna manera de hacer este tipo de cosas automáticamente a través de la herramienta o los comandos de Sitecore. Personalmente, no me gustan los paquetes de Sitecore.

4) ¿Conoces alguna buena referencia? Donde puedo encontrar respuestas de preguntas similares? Cualquier sitio web, libro, blog?

Conozco un documento "Comprensión de Sitecore Deployments 6.2", pero no se tratan aquí los diseñadores y cómo se sincronizarán los diferentes entornos.

Gracias.

Answer 1

1. No hay necesidad de que los diseñadores tengan acceso a Sitecore para construir marcas/js/css/imágenes estáticas pero para que eso puede incorporar en Sitecore será necesario que alguien integrarlo añadiendo sublayouts o representaciones que tienen el marcado y la referencia css/js/images. Si ha separado a sus diseñadores y desarrolladores, normalmente es útil explicarles que está utilizando un entorno de formularios web asp.net ya que hay consideraciones especiales a tener en cuenta al respecto (por ejemplo, identificaciones de control y uso de formularios). Hacer que compartan el control de código fuente con sus desarrolladores es una gran ventaja, ya que limita la cantidad de repeticiones que pueden necesitarse si ambos trabajan en tangente y realizan actualizaciones por separado.

2. Vale la pena conceptualizar la diferencia entre el contenido estático y dinámico.Si necesita realizar un "cambio de diseño" que implique actualizar markup/css/js, deberá aplicar ese cambio a través del ciclo de vida de desarrollo de software de la misma manera que lo hacen los desarrolladores. De hecho, sería mejor para los desarrolladores hacer eso. Si necesita realizar un cambio de naturaleza más "dinámica" y se ha desarrollado para, por ejemplo, actualizar texto, enlaces, imágenes, incluso CSS en algunos casos mediante el uso de campos del editor de texto enriquecido, por supuesto, podrías tener diseñadores que lo hagan. Serían "editores" como cualquier persona que use un CMS. La cantidad de participación que tienen en el proceso editorial depende en gran medida de la extensión del paradigma "basado en el contenido". Si lo desea, podría hacer que todas sus páginas solo expongan un campo de editor de texto enriquecido, pero eso sería una práctica extremadamente mala desde la perspectiva de Sitecore.

3. Echa un vistazo a un producto llamado Team Development for Sitecore de Hedgehog Development.

4. Hay muchos canales RSS de destacados desarrolladores de sitios como John West, Alex Shyba e.t.c. También hay muchas listas de lectura por ahí.

Answer 2

Esta ilustración muestra una manera de organizar sus entornos para evitar los solapamientos y bloqueos. Respondiendo a sus preguntas:

1 y 2) Tanto los desarrolladores como los diseñadores trabajan en sus máquinas locales, usando instancias locales de Sitecore. Usan TFS como el sistema de control de fuente para que puedan integrarse mutuamente en su trabajo. Por lo general, los Diseñadores trabajan más en CSS, Javascrips, Imágenes, Sublayouts (markups) y Desarrolladores en el código mismo. Contamos con un servidor de Integración Continua (Ex: TeamCity) que implementa cambios en 3 entornos diferentes: Servidor CI (para comprobación de estado de compilación), Servidor de QA (Para QA) y Servidor Prod (para edición de contenido y acceso público). Cuando, por ejemplo, un diseñador tiene que arreglar un problema de diseño, lo hará en su máquina local y luego enviará los cambios a TFS. El siguiente paso, TeamCity implementará cambios en el servidor de CI, si la compilación está bien, la persona de QA puede activar una compilación y probar las correcciones. Si todo funciona como se espera, alguien puede activar la compilación en el servidor de producción y la solución se activa.

usted tiene este otro diagrama que muestra los detalles de cómo se puede configurar el servidor de producción para separar creación de contenido y entrega de contenido - Aquí es una búsqueda me encontré con varias entradas de blog acerca de esta configuración: sitecore content authoring delivery

3) necesita TDS (Team Development for Sitecore): use esta herramienta para serializar/deserializar elementos de una instancia de Sitecore a otra. Luego puede tener los archivos serializados en TFS y compartirlos a través del equipo y los entornos. Lo bueno es que puede usar TeamCity para enviar elementos automáticamente a entornos de CI/QA/Prod;

4) La fuente principal de información en Sitecore es su SDN: puede registrarse gratis (o tener una cuenta extendida si tiene una licencia de sitecore)