Práctica recomendada para un proyecto de Sitecore

Question

Soy bastante nuevo en Sitecore y me gustaría saber un poco más sobre el enfoque habitual de un nuevo proyecto. Por lo tanto, estoy dispuesto a escuchar y probar algunas de las soluciones experimentadas de desarrolladores de Sitecore. Tengo muchas preguntas, no las haré todas. Solo tengo curiosidad por el enfoque que otras personas tienen.

¿Cuál sería el mejor enfoque para comenzar un proyecto de Sitecore? ¿Cómo prepararías tu proyecto? ¿Cuál será su enfoque mirando el reciclaje de código en proyectos futuros?

En resumen: ¿Qué experiencias TI tienes (si has trabajado o estás trabajando en proyectos de Sitecore) y cómo recomendarías a otras personas para trabajar con Sitecore.

En este momento estamos ocupados en la construcción de bloques de Sitecore que podemos reciclar en otros proyectos, pero estoy seguro de que hay 1001 consejos útiles y trucos por ahí. Espero que tengamos algún Stackoverflow de Pro de Sitecore que pueda ayudarnos un poco.

Answer 1

Esto es, como usted dijo, una gran pregunta. Éstos son algunos de mis pensamientos:

El desarrollo de Medio Ambiente

En primer lugar cuando empiezo un nuevo proyecto instalo Sitecore en mi entorno de desarrollo y me aseguro de que todo funciona. Ya sea durante la instalación o después de colocar las bases de datos en un servidor SQL por separado y cambiar la conexión de cable en consecuencia.

Abro Visual Studio y creo una solución e incluyo los archivos necesarios. Creo algún tipo de representación HelloWorld y trato de construir la solución para que pueda verificar que todo está funcionando como debería.

Cuando todo está funcionando, creo un archivo zip de toda la solución, incluida la carpeta de datos. Ahora es el momento de agregar esto a algún tipo de sistema de control de versiones, en mi caso Subversion.

Agrego el archivo zip a la subversión y también agrego todos los archivos que creo que serán cambiados durante el proyecto, generalmente le digo a subversion que ignore la carpeta del sitecore, esto acelera el rendimiento drásticamente al registrar archivos.

después de realizar una acción cometer los otros miembros del equipo de mi proyecto pueden revisar el código y empezar a desarrollar (después de descomprimir el archivo zip, fuera de curso)

Todos trabajamos hacia la misma base de datos, aunque esto va en contra de las recomendaciones de Sitecore, no hemos tenido ningún problema con este enfoque, sin embargo, los elementos en GUI creados/modificados por un desarrollador tardan un poco antes de que se creen/cambien para todos los demás.

Podríamos desarrollar varios proyectos diferentes utilizando la misma instalación de Sitecore, pero como casi todos los clientes usan diferentes versiones de Sitecore, encontramos que este enfoque es un poco engorroso.

A menudo configuramos un servidor de compilación automatizado, pero este es otro problema.

código reutilizable y representaciones

me gustaría decir que creamos paquetes ordenados en base a la misma base de código que se reutilizan entre proyectos, pero por desgracia no estamos allí todavía. Hoy en día es mucho cortar y pegar entre soluciones.

código de Carga en cliente

Esto se realiza mediante paquetes de Sitecore, normalmente con algún tipo de selección dinámica para qué archivos incluir, digamos todos ascx-archivos en una carpeta específica cambiaron los últimos 5 días.

Ahí lo tienes.

Answer 2

Aquí hay información de configuración general, basada en cómo hacemos las cosas.

Subversion Esto no es Sitecore específico, pero hemos creado nuestro repositorio de la misma familia

• ramas - Esto se utiliza para trabajar en grandes actualizaciones del sitio que puede tomar un tiempo. Digamos, por ejemplo, que quería actualizar cómo funcionaban todas las barras laterales del sitio, y esto tomaría algunas semanas para completarse. Lo que hacemos es crear una nueva rama y configurar otra instancia de sitecore para esta rama de desarrollo y hacer lo que tenemos que hacer. Cuando se completa, lo fusionamos de nuevo en el tronco para pruebas e implementación.
• etiquetas - Esto se utiliza para mantener una copia del código que nunca se fusionará en el tronco (esa es la diferencia entre esto y las ramas), por ejemplo, cuando implementamos una actualización en un sitio podemos crear una etiqueta de dicho código para que podamos volver a ella si es necesario.
• troncal - El código activo, todo lo que esté registrado aquí siempre debe poder desplegarse.

El tronco Esto es donde estamos desarrollando activamente/corregir errores, dependiendo de la parte del proyecto que estamos. Configuramos algo como esto (como un ejemplo, el proyecto se llama TheProject)

Mantenemos nuestro archivo de solución en la raíz de esta carpeta, esto hará referencia a las diversas bibliotecas en la carpeta src así como al proyecto web en la carpeta del sitio web.

• docs - un lugar para poner la documentación sobre el sitio. Sugiero encarecidamente que a medida que complete las características/secciones redacte una pequeña guía sobre cualquier conocimiento especial necesario para que funcione. Entonces, supongo que estoy trabajando en un cuadro de contenido destacado en una página de destino. Este recuadro extraerá automáticamente cierto contenido, a menos que esté anulado explícitamente. Lo que hago cuando completo algo como esto es escribir una guía para el cliente, usando muchas capturas de pantalla. Envié la guía al cliente y la puse en la carpeta de documentos. Esto ayuda al cliente a capacitar a su personal, y ayuda a los nuevos desarrolladores a acelerar la forma en que se hacen las cosas.
• lib - Aquí es donde guardamos las DLL a las que vamos a tener que hacer referencia en nuestros proyectos.
• prueba - Un lugar para realizar pruebas unitarias.
• src - Aquí es donde guardamos nuestro código de biblioteca específico del proyecto. Entonces aquí tendríamos una carpeta llamada TheProject.Biblioteca, y allí estaría el proyecto de estudio visual para
• web/sitio web - Aquí es donde tenemos Sitecore instalado y es la raíz del sitio. Aquí tenemos un proyecto llamado algo parecido a TheProject.Web. En el proyecto, agregamos todos los elementos generales, como la carpeta web.config/layouts, etc.

general Sitecore Code Library Una de las mejores cosas que puede hacer es de la configuración de inicio de una biblioteca general Sitecore que puede añadirse a lo largo del tiempo. Luego, cuando escribe un código para un proyecto que no solo es aplicable al proyecto, puede agregarlo allí. Puede parecer obvio, pero esto realmente ayudará a largo plazo. Obtendrá un código mucho más sólido, consulte link text.

Así que cuando hayamos terminado con todo esto tenemos algo así como una estructura de la solución/proyecto

theproject (La solución)

• TheProject.Library
• TheProject.Web
• MyCompany.SitecoreLibrary (nuestra biblioteca general del sitio)

Herramientas Esta es otra cosa general, pero me parece que realmente puede ayudar a acelerar el desarrollo de Sitecore. Si te encuentras haciendo algo una y otra vez en Sitecore, usando API escribe una herramienta para que lo haga por ti. Esto no solo ayuda a resolver cualquier problema que estés abordando, sino que también te ayuda a familiarizarte con la API.

ReSharper Esto es más de una sugerencia de desarrollo .NET general, utilice ReSharper (http://www.jetbrains.com/resharper/index.html). Soy una especie de fanático de Resharper, hace que muchas cosas con el desarrollo sean más fáciles y rápidas. En mi opinión, la mayor ventaja es cuán fácil es el código de refactorización, lo cual es muy importante hacer a lo largo del tiempo para mantener las cosas limpias y comprensibles.

Espero que algo de esto ayude.

Gabe

Answer 3

Tome un vistazo a this series.

Especialmente la parte de arquitectura de componentes ha aumentado nuestro nivel de reutilización.

Answer 4

Al crear el proyecto de Visual Studio en la carpeta raíz de la tela de Sitecore y se mantendrá todos los archivos DLL de Sitecore dentro bin, no se olvide de añadir a las referencias del proyecto todos estos archivos:

bin\ComponentArt.Web.UI.dll 
bin\HtmlAgilityPack.dll 
bin\ITHit.WebDAV.Server.dll 
bin\Lucene.Net.dll 
bin\Mvp.Xml.dll 
bin\Newtonsoft.Json.dll 
bin\RadEditor.Net2.dll 
bin\Sitecore.Kernel.dll 
bin\Sitecore.Logging.dll 
bin\Sitecore.NVelocity.dll 
bin\Sitecore.Zip.dll 

Porque cuando LIMPIA su proyecto y solo tendrá referencia de Sitecore.Kernel.dll (en la mayoría de los casos), ¡perderá la mayoría de las dlls del directorio bin !!