The publishing workflow

Feature branch workflow with protected main branch

For our websites, we use a type of Git workflow called feature branching. This means that any new work is made in a separate site in CloudCannon, then merged into the dev branch (also called Staging). The dev branch is then merged into the main branch (also called Production).

Our main branch (which is the live, public-facing site) cannot be published to directly, meaning the live site is very stable and protected from any mistakes.

What does this mean for me?

Mainly this means that unlike any other content management system (CMS) you might have used, everything has to be published twice – first to dev, then to main.

The publishing workflow

This is our publishing process:

1. You make your changes or additions on your designated branch, then save them and allow your branch to finish building.
2. You create a pull request to merge your branch into dev. If you have sufficient permissions, you can approve your own pull request, which will automatically merge your updates into the Staging site. If you cannot approve your pull request, someone with a publishing role will have to approve it for you.
3. Allow the staging site to finish building, then preview your changes at the Staging test URL. If everything is OK, create another pull request to merge dev into main.
4. Someone with a publishing role will approve your pull request and merge your changes into main – making your changes live on the website.

Staging test URLs

minderoo.org (dev): https://russet-coast.cloudvent.net/
minderoo.org (stories): https://lime-cookie.cloudvent.net/
minderoo.org (media): https://modest-banana.cloudvent.net/