Theme deploys that do not need a developer awake

Shopify has a problem that no amount of good process fixes on its own: two sources of truth.

Developers work in git. Merchandisers work in the theme editor, on the live theme, because that is the tool they were given and it is the right tool for their job. Both are correct. But the moment a merchandiser changes a section setting in the admin, the repository is wrong, and nobody finds out until a deploy quietly reverts a week of their work.

I have watched that happen. It is a bad afternoon.

The version of this that does not work

The usual fix is a rule: nobody edits the live theme. Everything goes through a developer.

This fails for two reasons. It makes a developer the bottleneck for changing a heading, which is a waste of everybody. And it does not survive contact with a campaign launch, where somebody will absolutely edit the live theme at 6pm because they have to.

The rule loses to reality. So do not write a rule, write a workflow.

What we built

A GitHub Actions workflow that treats the live theme as an input rather than an output.

On a schedule, it pulls the live theme settings and templates, diffs them against main, and - if anything differs - opens a pull request with the changes and a readable summary of what moved.

That is the whole idea. What it buys you:

• The repository catches up automatically instead of drifting.
• Merchandising changes get a review, but after the fact, so nobody is blocked.
• A deploy can never silently revert someone’s work, because their work is already in the branch.
• The PR is a log. “When did this setting change and who changed it” has an answer.

The timezone part

The team I was on had merchandising split across Vietnam and the US. A release aligned to the US working day meant the Vietnam team either stayed late or handed over half-finished work.

Once the live theme is continuously reconciled into git, that dependency mostly disappears. The Vietnam team works in the editor during their day, the workflow picks it up, and the PR is waiting when the US team starts. The handover is a diff instead of a meeting.

I want to be honest that this is not a full CI/CD story. Theme deploys still need a human deciding when to publish. What changed is that the synchronisation stopped being human work, and synchronisation was where the errors were.

Things worth knowing before you build one

Diff the settings, not the whole theme. Shopify writes to files you do not care about. If your workflow opens a PR every time an asset hash changes, everybody will start ignoring the PRs, and then you have automation nobody reads.

Make the PR body human. “12 files changed” is useless. “Homepage hero heading and CTA link changed; Winter collection banner enabled” is a review someone can do in thirty seconds.

Decide what happens on conflict, early. When the same section changed in both git and the editor, someone has to choose. We made the workflow flag it loudly and leave it to a person. Automatic merge resolution on a live storefront is not a risk worth taking.

Do not let it publish. The workflow’s job ends at the pull request. The moment automation can push to the live theme unattended, you have built something you will eventually be frightened of.

What it is really for

The point is not saving deploy minutes. It is that the merchandising team stopped needing a developer to be available in order to do their own job, and the developers stopped losing work to a sync nobody owned.

That is usually where the time actually goes - not in the building, but in the coordination around it.