Site icon Blog ARC Optimizer

Mise à niveau des plateformes Sitecore – Migration de contenu

Mise à niveau des plateformes Sitecore – Migration de contenu


Vous avez donc besoin d’une mise à niveau Sitecore et vous ne savez pas par quoi commencer ni comment l’aborder ? Cette série d’articles de blog couvrira l’ensemble du processus, de zéro à héros, ou en termes de mise à niveau – de la planification à la mise en ligne. Il se présente sous la forme d’un guide qui vous fera économiser au moins 2 fois des efforts cumulés, en évitant les pièges cachés et les problèmes non évidents sur votre chemin vers une solution améliorée brillante. Au fil du temps, j’ai lutté et documenté la plupart de ces problèmes et je veux maintenant les partager tous en un seul endroit.

Contenu

Migration de contenu

Lorsque j’ai demandé à mes collègues quel était le plus grand défi de leur expérience de mise à niveau, presque tout le monde a répondu : la migration du contenu.

La migration de contenu est souvent la partie la plus longue et la plus difficile de la mise à niveau d’un site Web Sitecore, car elle implique le déplacement de grandes quantités de données de l’ancien site vers le nouveau. Cela peut être un processus complexe et délicat, car le contenu doit être transféré avec précision et correctement formaté pour fonctionner avec la nouvelle version de Sitecore. De plus, le processus de migration nécessite souvent une planification et une coordination minutieuses avec diverses équipes, y compris les créateurs de contenu, les développeurs et les parties prenantes, pour garantir que le contenu est migré en douceur et sans interruption de l’expérience utilisateur.

1. Maintenance du contenu

Selon votre niveau de propriété, il peut être judicieux d’entreprendre la maintenance du contenu. Ceci est facultatif mais hautement souhaitable.

Suppression d’anciennes versions d’éléments est une bonne pratique connue pour conserver moins de 10 versions par élément, ce qui améliore les performances d’édition du contenu. Une fois, j’ai vu 529 versions de l’élément Accueil du site et j’ai douté que les auteurs en aient tous besoin.

Vous pouvez supprimer manuellement les éléments hérités en exécutant le script SPE (Script PowerShell Extensions pour supprimer les éléments multimédias inutilisés de plus de 30 jours ) ou faites-le régulièrement en créant une règle dans le moteur de règles pour conserver automatiquement un nombre de versions inférieur au nombre souhaité (Actions du moteur de règles pour supprimer les anciennes versions dans Sitecore).

Envisager nettoyage de la médiathèque car c’est le domaine de contenu le plus abusé, généralement. Les éditeurs non formés ou simplement pressés placent souvent du contenu sans aucun soin. Presque toutes les solutions que j’ai vues avaient des problèmes avec la médiathèque : soit une structure foirée, beaucoup de médias inutilisés et incertains, soit les deux. Ces éléments sont lourds et gonflent la base de données et l’arborescence de contenu sans apporter aucun avantage. Il existe une extension PowerShell scénario pour répertorier tous les éléments multimédias qui ne sont pas liés à d’autres éléments, afin que vous puissiez réviser la liste et vous débarrasser de ceux qui ne sont pas désirés.

Vous voudrez peut-être aussi nettoyer les liens brisés avant de faire une mise à niveau. Sitecore a une page d’administration qui permet de supprimer les liens brisés. Vous pouvez le trouver dans le dossier Admin : RemoveBrokenLinks.aspx – sélectionnez simplement la base de données et exécutez l’action.

À partir de la version 9.1 par défaut Dossiers Helix vient OOB avec des bases de données devenues universelles. Dans le même temps, de nombreuses solutions Helix ont été implémentées auparavant et leurs ID de dossiers correspondants ne correspondent pas à ceux des versions ultérieures OOB.

Par exemple, la solution existante comporte également des dossiers tels que /sitecore/Layout/Renderings/Feature mais ils ne sortent pas de la boîte et ne sont donc pas sérialisés, mais ce qui est encore pire – avoir des identifiants différents de ceux qui viennent OOB qui sont maintenant universels.

Vous devrez retravailler la sérialisation pour qu’elle corresponde aux dossiers parents corrects provenant d’OOB.

2. Options de migration de contenu

En fait, vous disposez de nombreuses options pour migrer le contenu. Voyons ce qu’ils sont.

Emballage Sitecore

C’est le moyen par défaut d’échanger occasionnellement des éléments entre des instances connues de chaque développeur. Cependant, il est extrêmement lent et ne fonctionne pas bien avec les gros paquets de quelques centaines de mégaoctets.

Migrateur de contenu Sidekick

Sitecore Sidekick est un outil gratuit et dispose d’un module Content Migrator utilisant le format de sérialisation Rainbow pour copier des éléments entre les instances de manière multithread. Contrairement aux packages, il est ultra-rapide. Gardez à l’esprit que les deux serveurs doivent avoir le programme de migration de contenu installé sur eux.

Caractéristiques et avantages :

  • Un outil open source gratuit
  • Utilise la sérialisation Unicorn et Rainbow
  • Le fonctionnement multithread est très rapide !
  • Les deux serveurs nécessitent l’installation de Content Migrator
Télécharger Compagnon Sitecore (par Jeff Darchuk)

Razl

Offre une manière assez intelligente de copier des éléments entre les serveurs.

Caractéristiques et avantages :

  • Outil de comparaison visuelle de bases de données
  • Fournit l’ensemble d’outils de copie le plus intelligent
  • C’est un outil officiel du fournisseur
  • Cependant, ce logiciel n’est pas gratuit et nécessite une licence pour fonctionner.

En savoir plus sur Sitecore Razl – un outil de comparaison et de fusion.

Migration Sitecore PowerShell

Nous avons un scénario pour migrer le contenu entre les instances Sitecore à l’aide des extensions Sitecore PowerShell (par Michael West) qui exploite également la sérialisation Unicorn et Rainbow. Ce script est extrêmement rapide, mais il nécessite SPE avec Remoting activé sur les deux instances.

Caractéristiques et avantages :

  • Migre le contenu entre les instances
  • Utilise la sérialisation Unicorn et Rainbow
  • Nécessite SPE Remoting sur les deux instances
  • Fonctionne extrêmement vite !
  • Écrit par SPE auteur/mainteneur
$sourceSession = New-ScriptSession -user "admin" -pass 'b' -conn "https://old.site"
$destinationSession = New-ScriptSession -user "admin" -pass 'b' -conn "https://new.site"

$copyProps = @{
    "WhatIf"=$true
    "CopyBehavior"="CompareRevision"
    "Recurse"=$true
    "RemoveNotInSource"=$false
    "ClearAllCaches"=$true
    "LogLevel"="Detailed"
    "CheckDependencies"=$false
    "BoringMode"=$false
    "FailOnError"=$false
}

$copyProps["SourceSession"] = $sourceSession
$copyProps["DestinationSession"] = $destinationSession

# Default Home Item
Copy-RainbowContent @copyProps -RootId "{110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9}"

Cadre d’échange de données

Une alternative lourde à toute autre approche de migration, Data Exchange Framework (DÉF) fournit aux organisations un moyen standardisé de déplacer des données d’un système à un autre de manière efficace et sécurisée. La configuration prend beaucoup plus de temps, mais une fois cela fait, DEF pourrait effectuer une extraction et une mise à jour récurrentes du contenu de manière régulière.

Certains des principaux avantages de l’utilisation de DEF incluent :
• Il offre une approche cohérente et centralisée de la gestion des données, ce qui facilite la gestion des données provenant de plusieurs sources.
• Il permet aux développeurs de créer des fournisseurs de données et des formats de données personnalisés, ce qui permet d’intégrer DEF à une large gamme de systèmes externes.
• Il dispose d’une interface conviviale qui permet aux non-développeurs de gérer facilement les importations et les exportations de données.
• Il prend en charge une gamme de capacités de transformation et de mappage des données, ce qui permet de manipuler les données lors de leur importation ou de leur exportation.
Dans l’ensemble, DEF peut aider à améliorer l’efficacité et la fiabilité de la gestion des données dans les sites Web et les applications optimisés par Sitecore. Une fois configuré, il migrera et traitera naturellement tout contenu à partir de n’importe quelle API, pas seulement une autre base de données Sitecore.

Déplacer un élément vers une autre base de données à partir du Panneau de configuration

Si aucune des options ci-dessus ne fonctionne pour vous, il existe un outil intégré pour copier des éléments entre les bases de données qui fait partie du Panneau de configuration. L’astuce consiste à connecter la base de données cible en tant que base de données externe à une instance afin qu’elle soit visible dans Sitecore, puis vous pourrez copier des éléments à l’aide de cette option. Il a des fonctionnalités limitées et fonctionne raisonnablement lentement, mais permet de copier des données dans les deux sens.

Remarque : si vous migrez du contenu vers la version 10.1 ou une version plus récente, il existe une bien meilleure façon de gérer une mise à jour du contenu et de la base de données, que j’expliquerai en détail ci-dessous.

3. Sécurité du contenu

Il existe quelques options pour transférer des utilisateurs et des rôles d’une instance à une autre.

Forfaits Sitecore

Vous pouvez utiliser le Concepteur de package standard à partir du menu Outils de développement dans Sitecore Desktop. Vous pouvez ensuite ajouter les rôles et les utilisateurs que vous souhaitez regrouper pour la migration, générer le package, le télécharger, puis l’installer sur l’instance cible de la même manière que vous le feriez pour le contenu.

Sérialisation

Une alternative consiste à utiliser l’option de sérialisation à partir des applications User Manager et Role Manager. Les utilisateurs et les rôles seront sérialisés dans le dossier (données)/sérialisation/sécurité. Vous pouvez le copier de l’instance source vers l’instance cible, puis utiliser l’option de retour.

Pour ces deux options, le mot de passe de l’utilisateur n’est pas transféré mais réinitialisé (à une valeur aléatoire lors de l’utilisation des packages Sitecore ou à « b » lors de l’utilisation de la sérialisation).

Comment gérer les mots de passe ?

Vous pouvez alors soit réinitialiser manuellement le mot de passe des utilisateurs (du gestionnaire d’utilisateurs), ou les utilisateurs eux-mêmes peuvent réinitialiser le mot de passe à l’aide de l’option « Mot de passe oublié » à partir de l’écran de connexion, en supposant que le serveur de messagerie a été configuré et qu’ils reçoivent un e-mail de récupération du mot de passe.

Vous avez également la possibilité d’utiliser le dossier admin TransferUserPasswords.aspx outil pour transférer les mots de passe des bases de données source et cible. Pour ce faire, vous aurez besoin des deux chaînes de connexion et ces connexions doivent avoir un accès activé. En savoir plus sur le transfert des mots de passe utilisateur entre les instances Sitecore avec TransferUserPasswords.aspx outil.

SQL brut ?

Sans avoir l’accès requis, vous pouvez le faire manuellement avec SQL. Les données de rôle et d’utilisateur sont stockées à l’aide du fournisseur d’appartenance ASP.NET dans les tables SQL Server de la base de données Core. Veuillez noter que Sitecore 9.1 et les tables d’adhésion plus récentes peuvent être extraites de Core dans leur propre base de données de sécurité isolée (lire cet article sur l’extraction des données d’adhésion à Sitecore à partir de la base de données principale dans une base de données de sécurité isolée).

Il est donc possible de transférer les rôles et les utilisateurs avec un outil tel que Redgate SQL. Vous devrez vous assurer de migrer les données utilisateur à partir des tables suivantes :

aspnet_Membership
aspnet_Profile
aspnet_Roles
aspnet_Users
aspnet_UsersInRoles
RolesInRoles

Vous pouvez ajuster et utiliser SQL scénario pour migrer la sécurité du contenu lorsque les bases de données source et cible se trouvent sur le même serveur SQL. Aussi, suivez un StackExchange réponse à propos du déplacement des utilisateurs/rôles/mots de passe vers une nouvelle base de données principale (par Kamrouz Jaman).

4. Format des espaces réservés dynamiques

À partir de la version 9.0, les espaces réservés dynamiques sont devenus une partie intégrante de la plate-forme, contrairement aux modules tiers que nous utilisions auparavant. Cependant, Sitecore a mis en place son propre format d’adressage des composants : {placeholder key}-{rendering unique suffix}-{unique suffix within rendering}.

Cela signifie que vos mises en page précédentes ne seront pas affichées sur la page à moins que vous ne mettiez à jour les détails de présentation pour ces différences, sinon les rendus. Par exemple, si vous avez un composant sur une page dans un ancien format d’espace réservé dynamique, vous devez le modifier de :

main_9d32dee9-17fd-4478-840b-06bab02dba6c

au nouveau format, il devient donc :

main-{9d32dee9-17fd-4478-840b-06bab02dba6c}-0

Il y a quelques solutions pour aborder cela

De plus, vous n’avez plus besoin d’un module d’implémentation tiers, alors supprimez-le (à la fois DLL et son fichier de correctif de configuration). Sa fonctionnalité a été « déplacée » dans les bibliothèques Sitecore MVC intégrées que vous devez bien sûr référencer à partir de web.config:

<add namespace="Sitecore.Mvc"/>
<add namespace="Sitecore.Mvc.Presentation"/>

Lire la suite : un fonctionnaire guide sur les espaces réservés dynamiques.

Le prochain article de cette série est consacré à la mise à niveau de la base de code.






Source link
Quitter la version mobile