Guide 12 · Developer docs

Performance, caching, deployment and go-live

How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.

L2–L3
Unit 03 · The deployment model

A branching strategy that works

The deployment model Page 15 of 34 Updated

The flow a production store on Core dna runs on two-week sprints: feature branches from an integration branch, one release per sprint, branch names and commit messages that keep history readable, and the one path that goes straight to production.

Who this is for. Leads setting up a team's git flow on a Core dna site, and developers joining one. Afterwards you can run a release, a hotfix and the merge-back that keeps them in step, without a push ever surprising production.

Because a push to master is a release (branches and environments), the branching strategy is the release process. This page describes the one a production store on Core dna follows, rather than a generic diagram. It has two long-lived branches, each connected to an environment, and short-lived branches that are never deployed on their own.

The branches

BranchDeploys toRules
masterProductionThe approved release, not every finished task. No direct commits; merges only through a pull request with at least one approval; branch rules forbid deleting it or rewriting its history.
stagingStagingThe integration branch. Every feature branch starts here and returns here; review and testing happen on the staging site.
Feature branchesNothingOne per task, cut from staging, merged back through a pull request by the reviewer, not the author.
Hotfix branchesNothing until mergedCut from master for an urgent production fix only (below).

A two-week sprint

  1. During the sprint: each task is done on its own branch from staging, reviewed, merged into staging by the reviewer, and tested on the staging site, which always shows everything merged so far, running against production's content.
  2. On the second Thursday: the sprint's changes go out together. A pull request from staging into master is approved and merged, and the release is tagged. That merge is the production deploy.
  3. Straight after: master is merged back into staging, so both long-lived branches start the next sprint from the same commit. A pipeline does this on every merge into master (below).

A fixed cadence is what makes this work. Releasing one task at a time sounds faster, but then each merge to master is tested alone and the site is never seen with all of a sprint's changes together until they are on production.

Branch names and commit messages

Name each branch after the ticket that justifies it, and start every commit message with the same name:

Shell 
git checkout staging && git pull origin staging
git checkout -b issue/sts-322
git commit -m "issue/sts-322 - Validate postcode on the checkout address step"
git push -u origin issue/sts-322

A follow-up on the same ticket after review is issue/sts-322.v2; hotfixes are hotfix/hf-1, hotfix/hf-2. With this convention, git log --oneline on master reads as the list of tickets released, and any line of code leads back to its ticket.

Hotfixes

A hotfix is the one change that reaches production without passing through staging first, so it carries its own rules:

  1. Only for a fault on production that cannot wait for the next release.
  2. Branch from master, not staging, so that nothing unreleased goes out with the hotfix.
  3. Keep it to the hotfix. Refactoring "while you are there" is how a hotfix causes the next incident.
  4. A pull request into master, reviewed and approved like a release.
  5. Once it is merged and deployed, test it on production.
  6. Get it into staging: the merge-back pipeline does it; without one, merge master into staging by hand at once.
Shell 
git checkout master && git pull origin master
git checkout -b hotfix/hf-1
# make the fix, commit it, push, open a pull request into master
# after it is merged and deployed, if no pipeline does the merge-back:
git checkout staging && git pull origin staging
git merge origin/master
git push origin staging

The merge-back is the step that is easiest to skip, and it is what keeps the hotfix from being lost: it carries the hotfix into staging, so staging tests the same site production runs, and a later change to the same lines does not reintroduce the issue the hotfix addressed. If a hotfix has to be undone, revert its pull request on master; the same merge-back carries the revert to staging.

Automating the merge-back

A pipeline can do the merge-back on every push to master, so it cannot be forgotten. The store's Bitbucket pipeline:

YAML bitbucket-pipelines.yml 
pipelines:
  branches:
    master:
      - step:
          name: Sync staging with master
          image: atlassian/default-image:4
          script:
            - git config user.name "Bitbucket Pipelines"
            - git config user.email "pipelines@example.com"
            - git fetch origin
            - git checkout staging
            - git merge origin/master --strategy-option theirs
            - git push origin staging

The two git config lines matter: a merge commit needs an author, and without one the step fails. --strategy-option theirs resolves conflicts in master's favour, which is right for a hotfix. The step's push to staging is itself a deploy to the staging environment, and the branch rules on staging must let the pipeline push. What CI can do for a theme repo shows where it fits beside the other checks.

Go deeper
GuideWhat CI can do for a theme repo GuideRollback GuideGit-based deploy

Was this page helpful?

Your answer goes to the docs team.