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:
masteranddmz masterbranch is always deployable and branchable- CI server is the only one allowed to push code to
master featureandbugbranches are created frommasterand pull-requested intodmz
- successful build of
dmzwill fast-forwardmastertoHEADofdmz releasebranches are cut frommasterhotfixbranches can be cut fromreleaseto 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.
