Mise à niveau des plates-formes Sitecore – Tactiques de mise à niveau

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

• Partie 1 : Planification de la portée
• Partie 2 : Tactiques d’amélioration
• Partie 3 : Migration de contenu
• Partie 4 : Mise à niveau de la base de code
• Partie 5 : Modifications si Sitecore 10.x
• Partie 6 : Test et mise en ligne

Tactiques de mise à niveau

Ensuite, parlons de quelques tactiques de mise à niveau qui peuvent considérablement aider votre processus de mise à niveau.

1. Basculer entre les états

Fixer les états et pouvoir basculer entre eux aussi rapidement que possible est crucial pour la productivité lorsque vous travaillez sur des mises à niveau d’instance. Les petites erreurs sont inévitables et nous avons en fait besoin d’une sorte de bouton Annuler pour l’ensemble du processus.

Nous avons déjà cette approche implémentée pour codebase – git, avec sa capacité à basculer entre les branches.

Mais qu’en est-il des sites publiés, des index, des certificats et du reste des mineurs qui comptent ? Même les sauvegardes de bases de données ne sont pas aussi simples et rapides.

L’apposition de l’état est cruciale :

• Il y aura des erreurs petites mais coûteuses en temps
• Nous avons besoin d’un bouton « Annuler » à chaque étape du processus
• Ça devrait tout défaire d’un coup
• La virtualisation peut-elle nous y aider ?

La seule et unique solution qui vient à l’esprit est de réparer l’ensemble de l’état d’une machine en état de marche. Quelque chose que l’on pourrait avoir avec une machine virtuelle. Heureusement, nous avons au moins une technologie adaptée :

2. Hyper-V

En fait, cette technologie de virtualisation de Microsoft coche toutes les cases :

• gratuit et inclus dans Win Pro
• extrêmement rapide avec SSD
• intégration maximale du système d’exploitation
• déplacer les sauvegardes entre les hôtes
• options de mise en réseau parfaites
• Gestion à distance
• lecteurs virtuels universels

Cependant, vous aurez besoin d’un SSD relativement rapide et vous devez faire attention à l’espace disque – il est facilement consommé par plusieurs instantanés au fur et à mesure que vous progressez. Avoir un disque de 1 To est probablement le minimum dont vous auriez besoin pour un travail productif et une mise à niveau.

3. Tirez parti de PowerShell

Maintenant, nous sommes sûrs de revenir rapidement sur les mauvaises choses. Mais que diriez-vous de refaire les étapes réussies ? Avec beaucoup d’actions monotones et répétitives, on peut perdre un temps précieux pour des choses qu’on va refaire encore et encore.

Pensons au cas où quelqu’un a passé les 2 dernières heures à mettre à niveau les références NuGet pour une solution Helix contenant 100 projets. Malheureusement, à la dernière minute, quelque chose s’est totalement mal passé – la restauration au dernier point de contrôle Hyper-V prendra moins d’une minute, mais faut-il répéter ces étapes monotones encore et encore ?

Vous suggéreriez probablement – pourquoi ne pas créer un point de restauration plus souvent. Eh bien, créer un point de restauration pour chaque étape mineure semble être une solution exagérée, car Hyper-V consommera rapidement tout l’espace de votre disque.

Il est assez difficile d’effectuer une mise à niveau de tout dès la première tentative. Nous devrons répéter les étapes réussies, encore et encore, donc la seule approche serait de les automatiser. PowerShell est déjà intégré au système d’exploitation et constitue la solution la meilleure et la plus naturelle pour de telles activités.

Vous pouvez tirer parti de PowerShell pour :

• Tout type d’automatisation, de tâches système et de travaux
• Remplacement en masse de la configuration et du code par des expressions régulières
• Sauvegarder et restaurer les bases de données et l’application Web
• Gestion de votre infrastructure : en local ou dans le cloud
• Tirer parti de SPE Remote pour exploiter votre instance :
• Gestion du contenu, de la sécurité, de la publication et de l’indexation

Alors, pour quoi serait et pourrait être une bonne idée d’écrire ces scripts ? En plus des points ci-dessus, envisagez de créer des scripts pour certaines activités qui prennent plus de temps à accomplir ou qui entraînent des modifications textuelles mineures dans les fichiers.

Revenons au cas ci-dessus de mise à niveau des références NuGet dans une solution volumineuse, qui a pris 2 heures – sur votre disque, il se retrouve avec seulement quelques lignes de différence dans un fichier de projet ou de packages. Cela signifie, en comparant la différence (à l’aide d’un outil de comparaison) « avant et après » un changement est assez facile à automatiser à l’aide de PowerShell en utilisant des expressions régulières pour conduire de tels remplacements. N’étant pas un maître des expressions régulières, il est peu probable que vous réussissiez du premier coup, mais avec des options de restauration de point de contrôle rapides et faciles, vous le maîtriserez rapidement. De plus, vous vous retrouverez avec les artefacts : des scripts réussis qui pourraient être utilisés pour vos futures mises à niveau avec peu ou pas de modifications.

J’ai écrit un bon long article sur Bonnes pratiques PowerShell et tous les aspects de l’exploitation de ce langage de script intégré. C’est une longue lecture, mais très précieuse.

4. Preuve de concept rapide

Dans certains cas, lorsque vous effectuez un saut vers la version suivante (ou peut-être quelques versions antérieures) et si votre solution est relativement simple, restant proche d’une installation Sitecore vanille, il est logique d’essayer une preuve de concept rapide ( PoC). Cela vous donnera soit une victoire rapide, soit sinon, au moins identifiera la plupart des pièges et des choses à améliorer. Avoir des PoC ouvre de meilleures opportunités pour planifier la véritable mise à niveau.

Idéalement, il devrait s’inscrire dans un cadre de travail d’une journée pour un seul professionnel.

5. Essayez d’obtenir une sauvegarde récente d’une base de données principale

Il est hautement souhaitable d’obtenir une sauvegarde relativement récente de la base de données principale. Je me rends compte que ce n’est pas toujours possible : parfois en raison de la grande taille ou plus souvent en raison de la politique de sécurité de l’organisation, surtout lorsque vous travaillez pour une agence partenaire ou que vous êtes un prestataire externe.

Mais pourquoi auriez-vous besoin de ça ?

Tout d’abord, vous le restaurez avec la solution existante pour vérifier que la base de code que vous avez obtenue fonctionne exactement de la même manière sur le ou les sites Web publiés. Bien sûr, si vous travaillez pour une organisation donnée et que vous étiez responsable du projet en cours de mise à niveau dès le premier jour, cette étape pourrait être ignorée, car vous connaissez assez bien la base de code, l’infrastructure, l’historique des décisions prises tout au long de la durée de vie du projet, et la plupart des pièges potentiels.

Mais ce qui est plus important, vous devrez mettre à niveau et utiliser cette base de données avec une nouvelle instance de solution pour vous assurer qu’elle ressemble et fonctionne comme avant. Cela vous aiderait à éliminer la plupart des bugs et erreurs non évidents juste avant le début des tests de régression, ce qui vous fera gagner beaucoup de temps.

Un bon exemple tiré de ma propre expérience : j’ai commis une mise à niveau de 8.2.7 à 10.0.1 et tout s’est plutôt bien passé. J’ai utilisé une base de données principale complète mise à niveau. Je comparais visuellement les anciens sites exécutés sur l’instance de production existante avec ceux que j’ai mis à niveau localement vers la dernière version de Sitecore. Accidentellement, j’ai remarqué que certaines petites icônes SVG manquaient sur un site mis à jour. L’étude de ce problème m’a amené à l’un des changements de rupture qui serait difficile à repérer – les versions de la base de code, aucune erreur d’exécution et aucun problème de journal évident.

6. Que se passe-t-il si une version plus récente de Sitecore arrive pendant la mise à niveau ?