Aislamiento del sitio en instancia de SitePoint de Multisite Específicamente, ya que se aplica a Sitecore

Entiendo que se han formulado preguntas similares con respecto al aislamiento del sitio en una instancia de Sitecore de varios sitios, especialmente donde se menciona la solución multisitio de Tim , pero estoy buscando más claridad antes de intentar implementar completamente el código de Tim.

Actualmente estamos trabajando con una instancia de Sitecore que alberga casi diez sitios en este momento. Tenemos una solución de Visual Studio singular que, de una manera u otra, alimenta todos los sitios en una única base de código, de modo que todos los files DLL son comunes, y cualquier otro file puede serlo también. Hemos comenzado más o less a manejar esto al dividir todos los sitios en sus propios proyectos, con cada una de las estructuras de sus proyectos reflejando la estructura singular y final. Esto simplemente permite less "abandono" cuando se modifican elementos como los files .csproj, networkinguciendo los conflictos con otros desarrolladores que trabajan en paralelo. Aunque este es definitivamente un buen elemento para tener, es más una conveniencia de lo que verdaderamente buscamos.

Para tener un poco más de experiencia, tenemos cinco instancias totales de Sitecore en una "secuencia", que son la instancia del desarrollador local, la instancia de desarrollo, la instancia de ensayo intermedio y luego dos instancias de producción. Estamos gestionando los cambios con Git.

En este momento no podemos realizar un cambio comstackdo, digamos un cambio en cualquier código subyacente, ya que se aplica a un elemento en un sitio (que no afecta a los otros sitios funcionalmente), y desplegar ese cambio comstackdo sin que otros sitios tengan confiar en esa DLL. La principal forma de que esto se convierta en un problema es que no podemos garantizar que todos los sitios sigan ejecutándose cuando se extraiga algún código; cualquier cambio en un solo sitio podría romper todos los sitios a la vez. Ha habido casos en los que he realizado cambios de código que se implementaron erróneamente en el desarrollo que rompió todos los sitios, por lo que este es un problema totalmente realizado. Tampoco queremos tener que probar cada sitio cada vez que hay un cambio de código, cuando podríamos tener más de treinta sitios en Sitecore en el futuro cercano.

Quizás la solución de sitios múltiples de Tim hace esto, pero ¿hay alguna manera de aislar realmente los sitios para que no todos dependan de los mismos files DLL? ¿Podríamos entonces tener soluciones de Visual Studio separadas para cada website (que creo que sería ideal)? He visto otras respuestas que han mencionado la solución de Tim como "aislante", pero eso ha sido demasiado ambiguo para mí. ¿En qué medida la solución de Tim "aísla" los sitios? ¿Hay una mejor solución?

Una única instancia de la aplicación Sitecore es esencialmente un entorno de alojamiento virtual para uno o más sitios web. Cada sitio se compone de layouts y componentes de la interfaz de usuario que pueden compartirse, pero no es necesario. Dicho esto, puede duplicar sus componentes en proyectos o soluciones por separado para cada sitio y esto resolverá ese problema. Sin embargo, abre otro problema de código duplicado en todos los sitios. Solucione un problema y lo necesite muchas veces. Además, cuando implementa una DLL, reciclará el grupo de aplicaciones para que todos los sitios se reinicien, ya que es la misma instancia de la aplicación. La mejor orientación que puedo dar es que esté organizada y tenga algún tipo de gobernanza de encoding. Tal vez un set de utilidades comunes utilizadas por todos los sitios que puedan ser propensas a romper múltiples sitios se modifiquen con mucho cuidado. Mientras que los componentes específicos del sitio son más al margen y tienen less impacto. Además, no acople sus componentes UI a demasiadas capas de inheritance y código en utilidades comunes. Aunque puede tener sentido lógicamente, crea un montón de acoplamiento que puede contribuir a su problema. Solo mis 2 centavos basados ​​en la experiencia con los mismos desafíos.

En nuestro caso, tenemos una biblioteca central de utilidades compartida por todos los sitios, un proyecto web central para componentes de interfaz de usuario compartidos, y luego proyectos web específicos del sitio para los componentes que se encuentran en esos sitios. También evitamos cambios de configuration globales donde sea posible y "sobre parches" de características como events y canalizaciones. En su lugar, intente mantener su código en el scope de un sitio específico.

Si necesita aislar realmente los sitios y la implementación de Sitecore, puede optar por un model donde cada sitio tenga su propia solución, el website de IIS (y el grupo de aplicaciones), el pipeline de implementación y toda la funcionalidad / configuration compartida se realice a través de packages NuGet. En este model, usted tiene un solo server CM donde la web es compartida por todos los sitios.

Además, puede aislar la publicación con un proveedor de events personalizado en cada sitio que solo genere events relevantes para los elementos de un sitio determinado, de modo que el caching no se borre en todos los sitios en cada publicación.

Esta forma de aislamiento actualmente se está ejecutando en producción con más de 70 sitios por server y ~ 80 desarrolladores distribuidos en ~ 10 equipos.