7
votes

Sitecore Meilleures pratiques

Nous mettons en place notre première migration en sitecore. Nous avons plusieurs sites multi-linguaux avec contenu stocké dans des champs de base de données avec LCID. Les contrôles de l'utilisateur font des appels de base de données pour afficher un contenu de langue différent. Nous migrons de notre contenu sur des articles de Sitecore et que vous souhaitez exploiter l'API SITECORE pour obtenir le contenu de nos contrôles utilisateur afin de créer des structures de données.

J'aimerais savoir comment structurer des projets Visual Studio pour le développement de Sitecore afin d'utiliser les solutions VS existantes. Devons-nous dupliquer Sitecore .dlls et configs sur toutes les solutions ou partagent une installation de Sitecore?

En outre, comment installez-vous les fichiers requis dans la production pour prendre en charge plusieurs sites existant en tant que sites Web distincts dans IIS? Devons-nous avoir des copies en double de toutes les fichiers requis .dlls et des fichiers de configuration requis dans un dossier / SITECORE SEPÉRÉ pour chaque site Web ou partagons un dossier avec un dossier virtuel dans chaque site pointant sur le même physique. / sitecore dossier?


0 commentaires

5 Réponses :


4
votes

En général, nous recommandons de tout exécuter sous 1 site Web IIS. Cela permet d'économiser beaucoup de problèmes de configuration et de déploiement. À côté de cela, ce n'est pas la performance de la Necesarry sage d'utiliser plusieurs sites Web.

Paramètres Les projets peuvent être effectués assez facilement. Assurez-vous simplement que les cibles de construction sont définies sur le dossier / site Web / bin de l'installation de SiteCore. Si oui, vous êtes capable de réutiliser quoi que ce soit. Vous pouvez lier le Sitecore.kernel en tant qu'élément de solution dans Visual Studio.

Globalement, je pense que vous devriez consulter votre bureau de sitecore local pour réfléchir à la mise en place de cette solution. Comme nous sommes connus avec ce type de migrations, nous sommes heureux de vous donner le bon conseil et de discuter de toutes les options.


0 commentaires

7
votes

Dans mon expérience, le "tout sous 1 site Web IIS" pour plusieurs sites avec SITECOore ne fonctionne que lorsque vous n'avez pas les suivants:

  1. Différents certificats SSL par site : IIS ne permettra qu'un certificat SSL par adresse IP / une combinaison portuaire IP et un seul par site Web dans IIS. Nous avons 4 certificats SSL de cartes sauvages différentes (pour 4 domaines de base différents) et nous devons donc avoir au moins 4 sites Web IIS distincts.
  2. Différents répertoires virtuels par site : Si vous souhaitez un répertoire virtuel disponible hors site Web mais pas l'autre, vous devez avoir des sites Web différents dans IIS.

    Si vous avez l'une de ces exigences, ils doivent être différents sites Web dans IIS (ou les exigences doivent être manipulées à l'extérieur de l'IIS).

    Quant à ce que vous avez configuré cela, une chose à garder à l'esprit est que nous nous avons dit que plusieurs installations de SIDECORE sur un serveur nécessitent une licence différente / multiple.

    Alors pour nous, nous avons dû partager la même installation avec plusieurs sites dans IIS, car nous avions toutes deux ces exigences (et une seule licence). Nous avons eu tous les sites Web partagent la même installation SiteCore (tous les fichiers partagés, y compris les DLL et web.config). Le tirage en arrière est:

    • que n'importe quelle configuration ou DLL change de changement de redémarrage pour tous les sites Web
    • que chaque site Web dispose de son propre domaine d'application (il multiplie donc les exigences de la mémoire et le cache en mémoire n'est pas partagé)
    • Ce domaine d'application est fondamentalement un processus distinct, de sorte que tout fonctionnement de maintenance ou planifiée (c'est-à-dire effacer le cache de média) fonctionne sur chaque site Web et accède aux mêmes fichiers. Cela peut causer des problèmes de performance et de concurrence. Nous avons dû lancer une partie de ces processus des tâches planifiées de l'extérieur et uniquement sur notre site Web d'édition pour prévenir les conflits.
    • Depuis que nous n'avons qu'un seul fichier de configuration, nous ne pouvions pas désactiver les fonctionnalités d'édition des sites Web de livraison de contenu. Cela signifie que nous avons dû utiliser les fonctionnalités de l'IIS pour empêcher l'édition sur les sites Web de livraison de contenu.
    • Nous avons dû le traiter comme une installation de Sitecore multi-serveurs, ce qui signifie que nous avons dû configurer un STager pour effacer le cache de publication. Nous avons utilisé l'article disponible dans la bibliothèque Source partagée.

0 commentaires

2
votes

0 commentaires

1
votes

pour la question numéro 2:

Nous utilisons Directives d'hélice / Habitat , il semble être la source de la meilleure pratique de Sitecore. Toute la formation de SIDECORE dit de créer un projet en dehors de SIDECORE et d'importer uniquement des choses que vous en avez besoin. Pour la configuration, je suggérerais de lire rapidement Ce

Il est vrai que SSL et les pools d'applications peuvent devenir un problème. Le déploiement sur un site d'un client fera tomber tous, en fonction de la configuration.

Si vous allez une instance multi-instance, vous devrez examiner votre licence SiteCore.


0 commentaires

1
votes

Pour ma compréhension, je peux voir que vous avez deux préoccupations ici:

1. Comment structurer le projet SITECORE

Je suis un développeur de sitecore depuis plus de 3 ans, sur la base de mon expérience, le meilleur pratice est de créer un seul projet SITECORE qui est la plus haute couche de votre Solution Vous n'avez pas besoin d'installer SITECORE DLLS vers tous les projets, gardez simplement votre ancien code tel qu'il était et le tourner au code de base. Par exemple, je viens de terminer un projet que le client veut passer à l'utilisation de Sitecore, La solution était déjà là, il dispose de 4 projets:

  1. abc.web ==> couche la plus élevée
  2. abc.data ==> Utilisation de la couche de données
  3. ABC.Services => Couche de manipulation d'entreprise
  4. ABC.DOMAIN ==> COUCHE COMMUNE

    Nous avons créé un nouveau projet qui doit être installer des dlls SiteCore, qui remplacent réellement l'ABC.Web (couche la plus élevée) qui contient tout le code SITECore MVC et ne change aucune autre chose à l'ancien code. À partir de ce moment, nous pouvons travailler avec les deux données de l'ancien système (en référençant les DLL ABC.Services) et de SITECORE.

    2. Comment installez-vous les fichiers requis dans la production pour prendre en charge plusieurs sites?

    sitecore prend en charge multisite en structurant l'arborescence de contenu Sitecore et une configuration LITTE. Vous n'avez pas besoin de créer des sites Web séparés dans IIS, Ils sont en fait un site web avec différents domaines.Le fichier de configuration nommé sitefinition.config (ou vous pouvez ajouter votre propre fichier de configuration), vous définissez essentiellement un domaine avec un élément de démarrage. Sitecore reconnaît le domaine qui correspond à celui du fichier de configuration et redirigera vers l'élément de départ en conséquence. Par exemple. Dans l'image, j'ai créé 2 sites (essentiellement, il s'agit de 2 branches d'arbre de contenu Sitecore) avec des éléments de démarrage sont (mySite1 et mysite2)

     Entrez la description de l'image ici

    Ceci est ma configuration xxx

    Vous pouvez faire référence à ce tutoriel pour plus de détails

    https://bridiencaos.wordpress.com/2010/03/01/working-with- Plusieurs sites-in-sitecore /


0 commentaires