Réparer un échec de déploiement XM Cloud / Blogs / Perficient

Introduction 📖

La semaine dernière, j’ai remarqué que les déploiements sur Sitecore XM-Cloud échouaient sur l’un de mes projets. Dans cet article de blog, je passerai en revue les étapes de dépannage que j’ai suivies et la nature du problème. Pour fournir un peu plus de contexte sur la configuration DevOps pour ce projet particulier, un Azure DevOps le pipeline exécute un script. Ce script utilise le CLI Sitecore et le plugin Sitecore XM Cloud déploiement cloud commande à déployer sur XM Cloud. Le dernier déploiement réussi remonte à quelques jours seulement et il n’y a pas eu beaucoup de changements de code depuis. Au départ, j’étais assez perplexe mais bon, que faire à part commencer par le haut…

Dépannage 👷‍♂️

1. Quiconque a travaillé avec des services SaaS basés sur le cloud sait que les pannes passagères existent, et XM Cloud ne fait pas exception. La première chose que j’ai essayée a été de simplement réexécuter l’étape défaillante de notre pipeline pour voir s’il ne s’agissait que d’un « simple problème ». Hélas, plusieurs tentatives de déploiement ultérieures ont échoué avec la même erreur. D’accord, très bien, ce n’était pas un problème passager 😞.
2. En examinant les journaux dans l’interface XM Cloud Deploy, l’étape de construction échouait systématiquement. En explorant les journaux, plusieurs erreurs de compilation se sont produites faisant référence à des assemblys Sitecore manquants. Par exemple: erreur CS0246 : le type ou le nom de l’espace de noms « Item » est introuvable (il vous manque une directive using ou une référence d’assembly ?). Cela suggérait un problème avec la restauration NuGet ou avec la compilation de manière plus générale.
3. Réexécution des étapes ayant échoué dans un pipeline Azure DevOps utilise le même commit qui a été associé à la première exécution–le dernier code de la branche n’est pas extrait à chaque tentative de réexécution. Cela signifiait que le code utilisé pour le dernier déploiement réussi c’était le même code utilisé pour les tentatives ultérieures. En d’autres termes, ceci probablement n’était pas un problème de code (derniers mots célèbres, non 😅 ?).
4. Juste pour être sûr, j’ai comparé plusieurs commits récents sur notre branche de développement et, oui, il n’y a eu aucun changement qui aurait pu interrompre la compilation depuis le dernier déploiement réussi.
5. Pour continuer les vérifications d’intégrité, j’ai extrait le commit spécifique localement et vérifié que je pouvais :
   1. Restaurer les packages NuGet, via l’interface utilisateur et la console
   2. Construire/reconstruire la solution Visual Studio
6. Après avoir revisité et comparé les journaux XM Cloud Deploy, j’ai remarqué que la version de msbuild avait changé entre le dernier déploiement réussi et les déploiements échoués les plus récents. J’ai téléchargé la même version, plus récente, de msbuild et vérifié, une fois de plus, que je pouvais restaurer les packages NuGet et créer la solution.
7. Enfin, j’ai confirmé que le build de validation configuré pour la branche de développement (via politiques de succursale dans Azure DevOps) fonctionnait comme prévu et créait avec succès la solution à chaque fois qu’une nouvelle demande d’extraction était créée.

À ce stade, pendant que je continuais à analyser les journaux de déploiement, j’ai ouvert un ticket d’assistance Sitecore pour leur donner mon avis 🙋‍♂️. J’ai fourni une assistance avec les derniers journaux de build fonctionnels connus, les derniers journaux de build ayant échoué et la liste de mes étapes de dépannage jusqu’à ce point.

La solution 🩹

Après avoir reçu une réponse du support Sitecore, il s’est avéré que Sitecore avait récemment modifié la façon dont le buildTargets propriété dans le xmcloud.build.json Le fichier a été consommé et utilisé dans le cadre des déploiements. Pour citer l’ingénieur du support :

Il y a eu quelques changements dans le processus de construction, et maintenant les cibles de construction sont chargées à partir de la liste « buildTargets ». Les versions de travail précédentes utilisaient directement le fichier « .sln ».
Il semble que cela ait empêché la construction de fonctionner correctement pour certains projets.

Le correctif suggéré consistait à cibler spécifiquement le fichier de solution Visual Studio pour garantir que la restauration et la compilation du package NuGet de déploiement XM Cloud fonctionnaient comme prévu. Mon interprétation du changement était « XM Cloud Deploy était utilisé pour pas se soucier/respecter buildTargets… mais maintenant c’est le cas.

Après avoir créé une pull request pour modifier le buildTargets propriété à partir de ceci (ciblant le projet spécifique de niveau supérieur) :

{
  ...
  "buildTargets": [
    "./src/platform/Project/Foo.Project.Platform/Platform.csproj"
  ]
  ...
}

…à ceci (ciblant la solution) :

{
  ...
  "buildTargets": [
    "./Foo.sln"
  ]
  ...
}

…le prochain déploiement sur XM Cloud (via CI/CD) a fonctionné comme prévu. ✅🎉

Après avoir demandé à l’ingénieur du support Sitecore où ce changement avait été documenté, ils l’ont gracieusement signalé en interne et publié un nouvel événement sur le site. Page d’état du sitecore pour reconnaître le changement/le problème : Le déploiement ne parvient pas à se construire.

Si vous remarquez que vos déploiements XM Cloud échouent lors de l’étape de génération lors de la compilation de votre solution Visual Studio, assurez-vous de cibler le fichier de solution (.sln) et non un fichier de projet spécifique (.csproj) dans le buildTargets propriété dans le xmcloud.build.json dossier… parce que c’est important maintenant, apparemment 😉.

Merci pour la lecture! 🙏