Vous avez donc besoin d’une mise à niveau de 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
Changements dans Sitecore 10.x
Dans cet article, je vais vous expliquer les changements importants apportés par Sitecore 10.x et comment rendre la transition vers les dernières versions de Sitecore plus fluide que jamais.
1. Conteneurs
Les conteneurs sont immuables, ce qui signifie que toute modification apportée au système de fichiers dans le conteneur sera perdue dès que le conteneur redémarrera
Lorsque vous passez aux conteneurs, votre base de code restera la même, cependant, il y a des changements mineurs – le débogage fonctionne maintenant un peu différemment : nous devons maintenant choisir un conteneur pertinent, puis sélectionner un processus à l’intérieur. au lieu de publier des artefacts dans un dossier Web, nous créons maintenant des images et exécutons un conteneur à partir de celui-ci.
Avec Docker, vous ne déployez plus uniquement votre code d’application. Un conteneur est désormais l’unité de déploiement, qui comprend l’ensemble de l’environnement : les dépendances du système d’exploitation et des applications. Par conséquent, votre processus de génération devra être étendu pour créer des conteneurs Docker et les pousser vers un registre de conteneurs.
Azure et AWS conviennent tous deux à l’exécution de Sitecore dans des conteneurs. Ils fournissent tous deux des services Kubernetes gérés et d’autres options d’hébergement de conteneurs.
Outre les conteneurs, vous devez prendre en compte d’autres composants système : SQL, Solr et éventuellement Redis
Tout déplacer dans des conteneurs nécessitera également de réfléchir à la manière dont vous surveillerez la santé de chaque service. Heureusement, Sitecore est livré avec des points de terminaison de vérification de l’état (/healthz/live et /healthz/ready) prêt à l’emploi, que vous pouvez utiliser à cette fin.
Kubernetes à lui seul imposera une courbe d’apprentissage assez abrupte.
Vous pouvez en savoir plus des astuces sur la migration de votre solution Sitecore vers Docker.
2. Mettre à niveau la base de données
Les bases de données n’étaient pas compatibles à 100 % entre les versions. Précédemment (avant 10.1) il fallait exécuter un script de mise à jour contre Core et Master afin d’attacher les deux à une instance cible vanille et de progresser avec le reste de la mise à niveau.
Le script de mise à jour garantissait que le schéma et le contenu OOB par défaut étaient mis à jour en appliquant toutes les modifications intermédiaires entre les deux versions. Cette article explique plus en détail comment avons-nous mis à niveau les bases de données avant 10.1.
L’idée qui a été prise en considération était que la fourniture de bases de données vides avec une plate-forme vanille éliminerait le besoin ci-dessus pour tous ceux qui mettent à jour la base de données d’opérer à un niveau d’administration SQL. Mais chaque version a son propre ensemble unique d’éléments OOB par défaut, où les conservons-nous ?
En raison de la façon de penser du conteneur d’abord, il était clairement nécessaire de les stocker quelque part au niveau du système de fichiers, il s’agissait donc de choisir et d’adopter un fournisseur de données approprié. Protobuf de Google était un choix parfait en cochant toutes les cases, de plus, c’est une technologie très mature.
Le diagramme montre la différence dans la façon dont nous avons effectué les mises à niveau de la base de données avant la version 10.1 de Sitecore et à partir de la version 10.1
3. Éléments en tant que ressources
Sitecore a appelé cette approche Éléments en tant que ressources.
Je vous recommande fortement de regarder les éléments en tant que plugin de ressources pour la CLI de Sitecore – au lieu de passer par tous les problèmes de création d’images d’actifs, vous pouvez créer des fichiers Protobuf qui contiennent tous vos éléments et les intégrer directement dans votre image de conteneur.
Vous pouvez créer vos propres fichiers de ressources à partir de *.item sérialisation à l’aide des éléments CLI de Sitecore en tant que ressources brancher (version de CLI 4.0 ou plus récente). Vous ne pouvez pas supprimer des éléments du fichier de ressources, il est en lecture seule, mais cette astuce (par Jeroen DeGroot) vous aide à « supprimer » des éléments au niveau du fournisseur.
4. Application de mise à jour de Sitecore
Mais comment mettre à niveau, disons, les bases de données 8.2 vers 10.3 ?
À partir de la version 10.1, les bases de données n’ont plus de contenu – il s’agit de supprimer les éléments par défaut de la base de données SQL, en laissant le reste du contenu intact. Ce contenu par défaut proviendrait du fichier de ressources des éléments réels qui sera placé dans App_Data\Items dossier.
Pour mise à niveau à Sitecore 10.1 avec UpdateApp Tool, il s’agit simplement de remplacer les fichiers de ressources qui s’intègrent naturellement dans une manière de faire des affaires avec un système de fichiers conteneur.
C’est là qu’un nouvel outil entre en jeu, veuillez accueillir Sitecore UpdateApp Tool !
Cet outil met à jour le Core, Masteret Web bases de données de Sitecore Experience Platform. Vous devez télécharger et utiliser la version de l’outil qui convient à la version et à la topologie de Sitecore Experience Platform à partir de laquelle vous effectuez la mise à niveau. La version de UpdateTool lui-même reflète en quelque sorte la version de la plate-forme vers laquelle vous effectuez la mise à niveau – utilisez UpdateApp 1.2.0 pour la mise à niveau vers 10.2. et UpdateApp 1.3.1 si mise à niveau vers 10.3..
Cet outil fonctionne également avec les fichiers de ressources des modules officiels pour la mise à niveau des bases de données Core, Master et Web (tels que SXA, SPE, DEF, Horizon, les deux CRM, etc.).
5. Images d’actifs
Pour conteneuriser les modules, nous utilisons désormais des images Sitecore Asset, au lieu de packages comme nous le faisions auparavant. Mais pourquoi?
Tout d’abord, vous ne pourrez pas installer un package qui supprime la DLL en raison de l’instance \bin dossier verrouillé pour un utilisateur IIS.
Deuxièmement, les conteneurs sont immuables et sont supposés être supprimés et instanciés – toute modification apportée à un conteneur disparaîtra avec lui.
De plus, puisqu’un module est une unité logique de fonctionnalité avec son propre cycle de vie et ses propres actifs, il doit être traité selon le principe « fonctionne ensemble, est livré ensemble ». De plus, en tant que responsable de paquet, vous fournissez des exemples de Dockerfiles d’utilisation pour les rôles requis afin que vos utilisateurs puissent les récupérer facilement.
Les images Sitecore Asset sont en fait le stockage des actifs de votre module dans les dossiers pertinents, basés sur la plus petite image de fenêtres – nanoserver. Vous pouvez les créer manuellement, comme je le montre sur ce diagramme.
Avec la plate-forme récente, il existe deux façons de gérer les éléments : soit créer un fichier de ressources d’éléments, soit convertir le fichier zip du package en un package WebDeploy, puis extraire son fichier DACPAC et le placer dans le dossier DB. Dans les deux cas, la structure du fichier restera comme illustré dans le diagramme ci-dessus.
Il y a un outil appelé Docker Asset Image Creator qui fait exactement cela – automatise la création d’une image d’actif pour un module Sitecore donné (par Robert Hock).
Je recommanderais de parcourir ces documents pour une meilleure compréhension:
Dans l’ensemble, les modifications apportées à Sitecore 10.x en matière de mise à niveau et d’utilisation des conteneurs offrent de nombreux avantages et peuvent contribuer à rendre le processus de mise à niveau des plates-formes Sitecore plus efficace et plus fiable. Ces changements démontrent l’engagement de Sitecore à améliorer et à faire évoluer constamment sa plate-forme, et ils peuvent aider les développeurs à tirer parti des fonctionnalités les plus récentes et les plus avancées de Sitecore.
Dans le dernier chapitre de cette série de blogs, je parlerai des activités nécessaires à entreprendre avant la mise en ligne et immédiatement après.
Source link