Mise à niveau des plates-formes Sitecore – Test et mise en ligne

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.

Teneur

Ceci est le dernier article de ma série sur la mise à niveau de la plate-forme Sitecore. À ce stade, nous nous attendons à ce que la mise à niveau de votre solution soit presque terminée, cependant, il reste encore plusieurs activités à terminer.

Test et mise en ligne

Je suppose qu’à ce moment-là, vous avez déjà établi de nouveaux Canalisations CI/CD afin que vous ayez le contrôle des versions automatisées. Si ce n’est pas le cas, veuillez le configurer avant d’aller plus loin. De l’extérieur, la publication et le déploiement doivent fonctionner comme un ensemble d’opérations atomiques reproductibles résultant de l’état actuel de votre solution. Vous ne pouvez tout simplement pas effectuer de tests tant que vous n’avez pas stabilisé le processus de publication, car avec les versions (semi) manuelles, il existe de nombreuses possibilités d’erreurs fantômes.

En ce qui concerne les tests, vous devrez certainement effectuer au moins un (ou si les choses tournent mal – une série de) des types de tests suivants :

• Tests de charge – depuis que nous avons mis à niveau vers un nouveau système, nous devons nous assurer qu’il est conforme aux scénarios de charge attendus.
• Tests d’intrusion – pour vérifier la solution mise à niveau pour les vulnérabilités connues et pour résoudre les problèmes avant la mise en ligne.
• Tests de bout en bout – pour confirmer que le système fonctionne dans des conditions et des scénarios réels
• Tests de régression – pour s’assurer que le système mis à jour fonctionne de la même manière que l’ancien système.

Puisque nous parlons dans le contexte de l’exécution d’une mise à niveau, je voudrais me concentrer sur Les tests de régression. La première question vient préciser, que tester exactement ?

En fonction de l’étendue de la mise à niveau, vous devrez au moins vous assurer des éléments suivants :

• Apparence et convivialité globales du ou des sites
• Les intégrations tierces ne sont pas cassées
• L’expérience d’édition n’est pas cassée
• Les tâches/correctifs les plus récents fonctionnent bien

Autre question, comment testeriez-vous : manuel, automatisé ou un mélange des deux ?

Étant donné que vous effectuez la mise à niveau vers une nouvelle instance de Sitecore en parallèle à celle existante, vous devez absolument effectuer des tests de charge avant que cette nouvelle instance ne devienne opérationnelle. Les métriques ne doivent pas nécessairement être meilleures qu’auparavant, car les nouvelles versions de Sitecore ont beaucoup de nouvelles fonctionnalités et le nombre d’assemblages dans \bin dossier grandit toujours. Mais dès qu’il respecte le SLA prévu, cela devrait aller.

Surveillance est également crucial lors de la mise en ligne. Une fois que la nouvelle instance Sitecore est opérationnelle, la première chose à vérifier serait les journaux Sitecore pour inspecter et corriger les erreurs enregistrées. Nous disposons d’un ensemble complet de tests d’interface utilisateur automatisés qui couvrent la majorité des cas d’utilisation professionnelle et sont exécutés du jour au lendemain. Le strict minimum que vous devriez faire régulièrement serait :

• Inspectez tous les journaux pour toute exception
• Surveillez les métriques pour les anomalies

Cela peut sembler évident, mais assurez-vous que la surveillance fonctionne bien dans les environnements de destination préalable au trafic factuel de commutation vers la nouvelle instance. La dernière chose que vous voulez expérimenter est un nouvel environnement écrasant sans avoir aucun moyen d’identifier pourquoi exactement.

Un autre exercice à entreprendre avant de passer en direct serait Renforcement de la sécurité – le processus de sécurisation d’un système en réduisant sa surface de vulnérabilité, qui est élevée pour des systèmes réalisant plus de fonctions comme Sitecore. De Versions plus anciennesSitecore propose le Guide de renforcement de la sécurité et considérations être suivi. Il comprend:

• Sécurisation de la gestion de contenu – idéalement, l’environnement CM ne devrait pas être exposé à Internet. Vous pouvez soit utiliser le filtrage IP pour les clients de la liste blanche, soit configurer un accès VPN au réseau hébergé par CM.
• Réinitialiser Sitecore admin mot de passe, ou mieux encore – entièrement désactiver admin compte dans un environnement CM de production.
• En plus de ce qui précède, limitez l’accès à /sitecore/admin dossier.

Considérations sur le référencement sont parfois exclus par erreur de la portée du processus de mise à niveau. Cependant, c’est une partie cruciale de la mise en ligne. Au minimum, vous devez vérifier que vous avez implémenté les éléments suivants :

• Fichiers robots.txt et sitemap.xml
• sitemap.xml ne contient pas de liens brisés
• Les erreurs 404 et 500 sont correctement gérées
• là où des redirections ont lieu, elles doivent utiliser des codes d’état corrects, c’est-à-dire. 301, 302
• GTM est en place et est correctement configuré

Assurez-vous que les fonctionnalités liées au référencement sont correctement implémentées

Au cas où vous auriez le luxe d’organiser Gel du contenu pour la période Go Live – c’est super ! Sinon, vous devrez récupérer et prendre soin du delta de contenu produit pendant la mise en ligne. La meilleure chose à conseiller serait d’utiliser les extensions PowerShell pour identifier et emballer tout le contenu produit à un horodatage spécifique. Après l’installation de ce package, le delta serait appliqué à l’instance mise à jour.

D’autres éléments à vérifier peuvent inclure :

• Votre solution utilise-t-elle la messagerie, par exemple pour récupérer les mots de passe oubliés ? À moins que vous n’utilisiez des services externes, vérifiez que les paramètres SMTP sont correctement définis et que les e-mails sont effectivement transmis.
• Avez-vous le bon certificat SSL pour l’environnement HTTPS de production, et si vous avez des sous-domaines, ils fonctionnent également bien avec HTTPS (avez-vous un certificat générique ?)
• Comment faire des sauvegardes et les restaurer ? Avez-vous un plan de reprise après sinistre en place et a-t-il été testé ?

Le véritable moment de la mise en ligne est celui où vous changer les enregistrements DNS d’une instance précédente à la nouvelle. Une fois cela fait, le trafic ira et sera servi par l’instance mise à jour. Il y a cependant quelques considérations :