Meilleures pratiques Sitecore Headless DevOps – Partie 1

Bienvenue dans ma série sur Meilleures pratiques DevOps liées à Sitecore Headless implémentations. Dans la partie 1, nous ferons un examen de Git DMZ Flow et verrons comment implémenter les principaux dans Azure DevOps.

Qu’est-ce que Sitecore Headless ?

Avant de plonger dans les détails techniques, alignons-nous sur ce qu’est Sitecore Headless. L’architecture Headless de Sitecore sépare les fonctions de contenu back-end des fonctions front-end. Du point de vue DevOps, cela signifie que nous avons deux applications que nous devons gérer. Vous avez le choix entre plusieurs options pour le back-end et le front-end. Dans cette série, nous utiliserons Sitecore XM Azure PaaS traditionnel pour notre back-end et une application React et Next.js hébergée sur Vercel pour notre front-end.

Qu’est-ce que le flux Git DMZ ?

Si vous n’avez pas revu Daniel Spiewak aperçu détaillé de Git DMZ Flow Je recommanderais de le faire, mais voici les points qui seront essentiels pour nous.

Flux DMZ Git :

• a un référentiel principal avec deux branches clés : master et dmz 
• master la branche est toujours déployable et branchable
• Le serveur CI est le seul autorisé à pousser le code vers master 
• feature et bug les branches sont créées à partir master et pull-demandé dans dmz 

• construction réussie de dmz avancera rapidement master à HEAD de dmz 
• release les branches sont coupées de master 
• hotfix les branches peuvent être coupées de release pour résoudre les problèmes critiques

Implémentation du flux Git DMZ dans Azure DevOps

1) Configuration générale du référentiel

Comme je l’ai mentionné plus tôt, nous avons deux applications distinctes pour le back-end et le front-end. Nous hébergeons les deux applications dans le même référentiel :

La master et dmz les branches sont définies sur ce dépôt avec dmz défini par défaut.

2) Restreindre l’accès à la branche master

Pour garder le master branche complètement verrouillée de tout le monde à l’exception du serveur CI, nous utiliserons les paramètres de sécurité de la branche. Pour définir la sécurité des branchesélire Dépôts > Succursales puis sélectionnez l’icône Plus d’options à côté de la branche. Sélectionnez Stratégies de branche dans le menu contextuel. Vous pouvez également obtenir la sécurité de la succursale en vous rendant sur Paramètres du projet > Référentiel > [Repository Name] > Sécurité > [Branch Name].

Une fois que vous avez ouvert les politiques de la branche pour le master branche, définissez l’autorisation de contribution sur Permettre pour seulement le Project Collection Build Service Accounts et assurez-vous que l’autorisation est définie sur Refuser pour tous les autres groupes.

3) Définir les politiques de branche dmz

Activation des stratégies de branche sur le dmz succursale satisfera à l’exigence selon laquelle tous les changements apportés à dmz se faire via une pull request. Pour définir des stratégies de branche, sélectionnez Dépôts > Succursales puis sélectionnez l’icône Plus d’options à côté de la branche. Sélectionnez Stratégies de branche dans le menu contextuel. Une fois les branches définies, l’icône de stratégie s’affichera à côté du nom de la branche. Vous pouvez sélectionner l’icône pour accéder directement aux paramètres de politique de la branche. Vous pouvez également obtenir les politiques de branche en allant sur Paramètres du projet > Référentiel > [Repository Name] > Stratégies > Stratégies de branche > .

Les politiques spécifiques définies sont :

• Vérifier les éléments de travail liés : obligatoire
• Vérifier la résolution des commentaires : Obligatoire
• Limiter les types de fusion : Squash

4) Avance rapide Maître à dmz

Une fois qu’une demande d’extraction a été fusionnée avec succès dans dmzune version complète de la branche HEAD arrivera. S’il réussit, alors le master branche devrait être automatiquement redirigé vers la HEAD de dmz. Cette avance rapide est effectuée par le script ci-dessous.

- script: |
ECHO clean
git add . && git reset --hard
ECHO git checkout master --quiet
git checkout master --quiet
ECHO git merge origin/dmz --ff-only --quiet
git merge origin/dmz --ff-only --quiet
ECHO git push origin master --quiet
git push origin master --quiet
displayName: Fast-forward master to dmz
failOnStderr: true
condition: and(eq(variables['Build.SourceBranch'], 'refs/heads/dmz'), ne(variables['Build.Reason'], 'PullRequest'), not(canceled()))

Dans la partie 2 (à venir !), nous examinerons de plus près les pipelines de construction où cette avance rapide se produit et verrons comment voir comment valider notre application frontale avant l’envoyer à Vercel.