A strategy for working around bugs that appear in the branch that content editors use to visually edit their site.
Netlify Create’s visual editing experience uses the code from a configured working Git branch. This is rarely the production branch, and it is often used to stage changes prior to releasing to production.
As a result, it’s possible that a bug gets introduced which prevents content editors from making further changes to the site until the issue is resolved.
To protect against this (and improve quality), you can establish an intermediary environment where all code changes considered ready to deploy by developers can be reviewed easily by content editors (or dedicated QA) before being approved and deployed.
Assuming you have a site called
awesome-site with typical configuration, you can set up a QA environment with the following steps:
- Create a branch in your repository for the site (e.g.
- Create a new project by selecting Use my repository, and choose
previewas the target branch and your new branch (
qa) as the working branch. Append “QA” to the end of the project name (e.g.
The new workflow could then move like this:
- Once this site is established, developers would merge their code from feature branches into
qa(and not into
- Those who have access to the new
awesome-site (QA)project can then visually review new code in the
- Users with an Owner or Developer role for that project will be able to publish, which would merge the code from
preview. (This could also be done on GitHub.)
- Once these changes are merged, editors working in the
awesome-siteproject can then edit with confidence that the code in the branch is production-ready.
If your project uses a headless CMS, you can decide whether to have the QA project connect to the same CMS content. Or it could use staging or placeholder content that you configure using the project creation wizard.