Meilleures pratiques Sitecore Headless DevOps – Partie 3

Bienvenue pour le dernier article de ma série sur les meilleures pratiques DevOps liées aux implémentations Sitecore Headless. Dans la partie 3, nous allons examiner le déploiement continu de nos applications Sitecore et Next.js suivant un modèle bleu/vert. Si vous n’avez pas vérifié Partie 1 et/ou Partie 2je recommanderais de faire une pause ici et de le faire car nous continuerons à construire sur les fondations posées dans ces régions.

Conditions préalables

Les processus couverts dans le post supposent ce qui suit :

1. Vanilla Sitecore a été déployé dans une configuration PaaS.
2. Connexions de services avec des abonnements Azure ont été créés. Je recommande une connexion de service différente pour chaque environnement en suivant le principe du moindre privilège.
3. Vous disposez de solutions Sitecore et Next.js compatibles avec Azure Pipelines.

Présentation de Vercel

j’ai mentionné Vercel plusieurs fois dans les messages précédents, mais nous n’en avons pas spécifiquement parlé, alors faisons un rapide tour d’horizon. Vercel est une plate-forme pour les frameworks frontaux et les sites statiques, conçue pour s’intégrer à votre contenu, votre commerce ou votre base de données sans tête. Ils sont un partenaire technologique de Sitecore ainsi que les créateurs de Next.js, ce qui en fait un excellent choix pour l’implémentation utilisée au cours de cette série. Ils soutiennent un large gamme de cadres Ainsi, même si vous n’utilisez pas Next.js, Vercel et les processus décrits dans cet article peuvent toujours être utilisés dans votre implémentation. Actuellement, ils n’ont pas d’intégration avec Azure Repos, je vais donc souligner comment utiliser le CLI de Vercel pour effectuer certaines des actions intégrées que vous obtiendriez si vous utilisiez l’une des intégrations Git existantes.

Pour démarrer avec Vercel, vous devez d’abord créer un projet en exécutant le Vercel commande décrite ici dans le l’extrémité avant répertoire (voir Partie 1 pour la configuration du référentiel). Lorsque le nouveau projet est créé, la CLI détectera automatiquement le framework utilisé.

Pendant que nous parlons de Vercel, allons-y et créons un jeton d’accès que nous utiliserons pour authentifier nos commandes CLI. Vous pouvez trouver les étapes pour créer le jeton ici.

Préparation pour Bleu/Vert

À ce stade, nous avons notre site Sitecore vanille fonctionnant sur Azure PaaS, un projet vide créé dans Vercel, des solutions Sitecore et Next.js fonctionnelles, et un processus d’intégration continue en place. Avant de créer les versions de livraison continue, nous devons configurer les ressources pour prendre en charge le bleu/vert.

Dans notre modèle de déploiement bleu/vert, nous allons utiliser des créneaux de déploiement sur notre CD App Service et le concept de déploiements en avant-première dans Vercel. Je ne couvrirai pas la création de l’emplacement de déploiement, mais vous pouvez trouver plus d’informations ici. Je ferai référence aux machines à sous en tant que production et mise en scène pour rester en phase avec le verbiage de Microsoft. Une fois que l’emplacement intermédiaire a été créé pour le CD App Service, voici quelques configurations/décisions clés que je souhaite souligner.

1. Déplacez les valeurs de chaîne de connexion jusqu’au niveau App Service.
   • Cela rend le système plus sûr et permet une gestion plus facile.
     
2. Notre créneau intermédiaire ne fonctionnera que pendant un déploiement. Toutes les autres fois, il sera arrêté.
   
3. Nous aurons deux bases de données Web : une de production permanente utilisée par CM et CD et une copie créée lors de la sortie pour être utilisée uniquement par le créneau de mise en scène du CD.
   • Remarque : Nous utilisons Content Hub pour la gestion des ressources multimédias, ce qui maintient la base de données Web à une taille raisonnable pour l’approche de copie. Si votre base de données Web est trop volumineuse pour cela, vous pouvez également disposer d’une base de données Web secondaire permanente et configurer la réplication.
     
4. Nous devons connaître l’état de l’environnement.
   • Connaître l’état nous permet de savoir quelle version de l’application est en cours d’exécution dans chaque emplacement. Cela peut être fait en ajoutant un paramètre d’application, NOM DE L’APPLICATION, à chaque fente de CD. Les valeurs doivent correspondre au rôle de chaque emplacement, ce qui dans notre cas sera Produit et Mise en scène. Ce réglage doit ne pas être un paramètre d’emplacement de déploiement.
     
5. Pour utiliser efficacement les déploiements de prévisualisation Vercel, il est recommandé d’avoir un domaine personnalisé spécifiquement pour la prévisualisation. Par défaut, Vercel attribuera un domaine aléatoire aux déploiements de prévisualisation, mais nous ne voulons pas rechercher cette valeur pour chaque déploiement.
   • Nous verrons comment utiliser l’interface de ligne de commande pour attribuer le domaine de prévisualisation aux déploiements ultérieurement. Vous pouvez en savoir plus sur l’ajout de domaines personnalisés à un projet Vercel ici.

Créer un pipeline de versions

Maintenant que notre travail de préparation est terminé, nous pouvons créer notre pipeline de versions. J’ai vu des implémentations utiliser des pipelines de construction écrits en YAML pour leurs versions afin qu’elles puissent être contrôlées par la source, mais je préfère utiliser des pipelines de version pour la facilité de gestion, d’approbation et d’automatisation.

J’aime avoir deux pipelines de publication, un utilisé pour le déploiement dans l’environnement de développement et un pour tous les environnements supérieurs. Le fait de disposer d’un pipeline dédié à l’environnement de développement nous aide à permettre à l’équipe de travailler à grande vitesse, car les règles et les calendriers peuvent être définis spécifiquement en tenant compte du développement. En outre, cela évite que le pipeline des environnements supérieurs ne soit encombré de versions susceptibles d’avoir un travail instable. Le pipeline pour les environnements supérieurs a une seule étape pour chaque environnement et chaque étape est composée de plusieurs tâches (à la fois agent et sans agent) et les travaux sont constitués de tâches et de groupes de tâches.

Avant d’examiner la logique d’une étape, nous devons ajouter des artefacts à consommer par notre pipeline. Puisque nous avons deux applications, nous aurons deux artefacts. Le premier est le résultat de notre pipeline de build Sitecore référencé dans Partie 2. Il contient les packages de déploiement Web et les éléments sérialisés à déployer sur nos Azure App Services. La seconde est une référence au référentiel qui sera utilisé par les tâches Vercel CLI.

Lorsque nous exécutons le pipeline de versions, nous créons une version contenant une version spécifique de nos artefacts. La création de versions peut être automatisée via un déclencheur ou un calendrier pour s’adapter à la cadence de vos équipes, en savoir plus à leur sujet ici.

Créer des tâches et des groupes de tâches

Une fois le pipeline créé, nous pouvons commencer à créer les tâches à effectuer lors d’une version. Étant donné que les tâches pour différents environnements seront en grande partie les mêmes, nous pouvons encapsuler les tâches dans des groupes de tâches pour centraliser leur gestion et permettre leur réutilisation. Je ne couvrirai pas tous les détails de la création de groupes de tâches, vous pouvez en savoir plus à leur sujet icimais il y a quelques points que je veux souligner :

1. Les groupes de tâches sont créés à partir de tâches existantes.
   
2. Les paramètres des tâches à inclure dans un groupe doivent être définis comme des variables.
   
   
3. Lorsqu’un groupe de tâches est référencé dans un pipeline et que vous modifiez la définition du groupe de tâches, cette modification sera reflétée dans toutes les références, ce qui assurera la cohérence de votre implémentation.

Par souci de concision, je ne détaillerai pas la configuration de chaque travail, tâche et groupe de tâches, mais j’ai inclus un résumé de la commande avec des descriptions et quelques scripts clés.

1. Poste d’agent : Déploiement des slots CM et CD
   • Groupe de travail : Déploiement CM
     • • Supprimer les fichiers Licorne : Inline Azure PowerShell pour vider le dossier Unicorn sur le CM, car nous ne voulons pas d’éléments persistants qui ne soient plus inclus dans nos artefacts.
         

         $ResGroupName = "$(RES_GROUP_NAME)" 
         $WebAppName = "$(CM_WEBAPP_NAME)" 
         
         # Get publishing profile for web application 
         $WebApp = Get-AzWebApp -Name $WebAppName -ResourceGroupName $ResGroupName$publishingProfile = Get-AzWebAppPublishingProfile -WebApp $WebApp 
         
         # Create Base64 authorization header 
         $username = $publishingProfile.publishData.publishProfile[0].userName 
         $password = $publishingProfile.publishData.publishProfile[0].userPWD 
         $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password))) 
         
         $bodyToPOST = @{   
             command = "find . -mindepth 1 -delete"
             dir = "/home/site/wwwroot/App_Data/Unicorn"   
         }   
         
         # Splat all parameters together in $param   
         $param = @{   
             # command REST API url
             Uri = "https://$WebAppName.scm.azurewebsites.net/api/command"   
             Headers = @{Authorization=("Basic {0}" -f $base64AuthInfo)}   
             Method = "POST"   
             Body = (ConvertTo-Json $bodyToPOST)   
             ContentType = "application/json"   
         }   
         
         # Invoke REST call   
         Invoke-RestMethod @param

     • État de l’environnement de repos : Inline Azure PowerShell pour vérifier le NOM DE L’APPLICATION paramètre pour les fentes de CD et pour l’existence d’une base de données Web en double. Doit toujours commencer et se terminer par la production dans l’emplacement de production et avec une seule base de données Web.
       

       $app=Get-AzWebApp -ResourceGroupName "$(RES_GROUP_NAME)" -Name "$(CD_WEBAPP_NAME)" 
       $appSettings=$app.SiteConfig.AppSettings 
       foreach ($appSetting in $appSettings){ 
           if($appSetting.Name -eq 'APP_NAME'){ 
               if($appSetting.Value -eq 'Staging'){ 
                   Switch-AzWebAppSlot -SourceSlotName "staging" -DestinationSlotName "Production" -ResourceGroupName "$(RES_GROUP_NAME)" -Name "$(CD_WEBAPP_NAME)" 
               } 
           } 
       } 
       $webdeploydb=Get-AzSqlDatabase -ResourceGroupName "$(RES_GROUP_NAME)" -ServerName "$(SQL_SERVER)" -DatabaseName "$(WEB_DB_NAME)_deploy" -ErrorAction SilentlyContinue 
       if ($webdeploydb){ 
           Remove-AzSqlDatabase -ResourceGroupName "$(RES_GROUP_NAME)" -ServerName "$(SQL_SERVER)" -DatabaseName "$(WEB_DB_NAME)_deploy" 
       } 
       else{ 
           continue 
       }

     • Service d’applications Azure déployer Forfaits spécifiques CM
     • Copier la base de données Web : Inline Azure PowerShell
       

       New-AzSqlDatabaseCopy -ResourceGroupName "$(RES_GROUP_NAME)" -ServerName "$(SQL_SERVER)" -DatabaseName "$(WEB_DB_NAME)" -CopyResourceGroupName "$(RES_GROUP_NAME)" -CopyServerName "$(SQL_SERVER)" -CopyDatabaseName "$(WEB_DB_NAME)_deploy"

   • Groupe de travail : Démarrage/permutation de la fente du CD
     • Tâche de gestion Azure App Service pour démarrer l’emplacement intermédiaire du CD.
     • Tâche de gestion Azure App Service pour permuter les emplacements de CD.
   • Groupe de travail : Synchronisation Licorne
   • Groupe de travail : Déploiement de l’emplacement du CD
     • Service d’applications Azure déployer Packages spécifiques au CD vers l’emplacement intermédiaire.
       
2. Poste d’agent : Déploiement de l’aperçu de Vercel
   • Script Bash en ligne : Notez à la ligne 14 où je capture la sortie de la commande vercel. Cette valeur sera le domaine attribué au hasard que je peux ensuite charger dans une variable à utiliser dans la commande alias. Cela affectera notre domaine personnalisé au déploiement de la préversion afin que l’équipe puisse vérifier les modifications dans un emplacement connu.

     [[ -d .vercel ]] || mkdir mkdir .vercel 
     
     echo write .vercel/project.json file 
     echo \{\"orgId\":\"${VERCEL_TEAM}\"\,\"projectId\":\"${VERCEL_PROJECT}\"\} > .vercel/project.json 
     
     echo .vercel/project.json content 
     cat .vercel/project.json 
     
     echo run npm install -g vercel 
     npm install -g vercel  
      
     echo run vercel 
     vercel --confirm --debug --token $(VERCEL_TOKEN) > .vercel/deployment_url.txt 
     
     echo set variable 
     deployment_url=$(cat .vercel/deployment_url.txt) 
     
     echo run alias 
     echo $deployment_url 
     vercel alias set $deployment_url staging.demo.com --token $(VERCEL_TOKEN) --scope my-team --debug

3. Tâche sans agent : Confirmer la mise en scène
   • Intervention manuelle : Répertorier les domaines où les utilisateurs peuvent prévisualiser le dernier déploiement et affecter des utilisateurs qui doivent approuver avant de passer à la tâche suivante.
     
4. Poste d’agent : Remplacement de la fente CD par la production
   • Groupe de travail : Échange de fente de CD
     • Tâche de gestion Azure App Service pour permuter les emplacements de CD
       
5. Poste d’agent : Vercel Production Déploiement
   • Groupe de travail : Vercel Production Déploiement
     • Script Bash en ligne : La dernière ligne appelle vercel avec l’indicateur –prod qui déclenchera le déploiement en production.

       [[ -d .vercel ]] || mkdir mkdir .vercel  
       
       echo write .vercel/project.json file  
       echo \{\"orgId\":\"${VERCEL_TEAM}\"\,\"projectId\":\"${VERCEL_PROJECT}\"\} > .vercel/project.json  
       
       echo .vercel/project.json content  
       cat .vercel/project.json  
       
       echo run npm install -g vercel  
       npm install -g vercel   
       
       echo run vercel --scope my-team ls demo-com  
       vercel --token $(VERCEL_TOKEN) --scope my-team ls demo-com  
       
       echo run vercel --prod  
       vercel --prod --token $(VERCEL_TOKEN)

6. Tâche sans agent : Approbation de la production
   • Intervention manuelle : À ce stade, la dernière version de chaque application est en ligne. Si tout est stable, l’étape peut être approuvée pour passer au travail final.
     
7. Poste d’agent : Fente pour CD de synchronisation
   • Groupe de travail : Service d’application de synchronisation de CD

Sommaire

Donc, nous l’avons. Un processus CI/CD complet pour une implémentation Sitecore Headless sur Azure PaaS avec Next.js/Vercel qui permet des déploiements rapides et réguliers sans temps d’arrêt et avec une intervention manuelle minimale. Si vous avez des questions ou des réflexions, postez un commentaire ci-dessous.