Sitecore Headless DevOps Best Practices – Part 1

Welcome to my series on DevOps Best Practices related to Sitecore Headless implementations. In Part 1 we will do a review of Git DMZ Flow and see how to implement the principals in Azure DevOps.

What is Sitecore Headless? 

Before we dive into the technical details, let’s align on what Sitecore Headless is. Sitecore Headless architecture separates back-end content functions from front-end functions. From the DevOps perspective, this means we have two applications that we need to manage. There are multiple options to choose from for both the back-end and front-end. In this series we will be using traditional Sitecore XM Azure PaaS for our back-end and a React and Next.js application hosted on Vercel for our front-end. 

What is Git DMZ Flow? 

If you haven’t reviewed Daniel Spiewak’s detailed overview of Git DMZ Flow I would recommend doing so, but below are the points that will be key for us. 

Git DMZ Flow: 

• has a main repo with two key branches: master and dmz 
• master branch is always deployable and branchable 
• CI server is the only one allowed to push code to master 
• feature and bug branches are created from master and pull-requested into dmz 

• successful build of dmz will fast-forward master to HEAD of dmz 
• release branches are cut from master 
• hotfix branches can be cut from release to address critical issues

Implementing Git DMZ Flow in Azure DevOps 

1) General Repository Setup 

As I mentioned earlier, we have two separate applications for back-end and front-end. We are hosting both applications in the same repository:

The master and dmz branches are defined on this repo with dmz set as the default. 

2) Restrict Access to master branch 

To keep the master branch completely locked down from everyone except for the CI server, we will use branch security settings. To set branch security select Repos > Branches then select the more options icon next to the branch. Select Branch policies from the context menu. You can also get the branch security by going to Project Settings > Repository > [Repository Name] > Security > [Branch Name].

Once you’ve opened the branch policies for the master branch, set the Contribute permission to Allow for only the Project Collection Build Service Accounts group and make sure the permission is set to Deny for all other groups.

3) Set dmz branch policies 

Enabling branch policies on the dmz branch will satisfy the requirement that all changes to dmz be made via a pull request. To set branch policies, select Repos > Branches then select the more options icon next to the branch. Select Branch policies from the context menu. Once branch policies have been defined, the policy icon will display beside the branch name. You can select the icon to go directly to the branch’s policy settings. You can also get the branch policies by going to Project Settings > Repository > [Repository Name] > Policies > Branch Policies > <Branch Name>.  

The specific policies defined are: 

• Check for linked work items: Required 
• Check for comment resolution: Required 
• Limit merge types: Squash

4) Fast-forward master to dmz

After a pull request has been successfully merged into dmz, a full build of the branch HEAD will occur. If it is successful, then the master branch should automatically be fast-forwarded to the HEAD of dmz. This fast-forward is done by the below script.

- 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()))

In Part 2 we will take a closer look at the build pipelines where this fast-forward occurs and see how see how to validate our front-end application before sending it over to Vercel.