Promote Code Through Dev, Stage, and Production

Cloudberrie uses three Git branches and three separate Cloudflare Pages projects.

Git branch	Cloudflare project	Purpose
develop	cb-<project>-dev	Active development and internal testing
staging	cb-<project>-stage	QA and release-candidate validation
main	cb-<project>	Production release

Important Cloudflare terminology

Cloudflare labels the primary branch deployment inside every Pages project as Production. Therefore, the deployment shown as “Production” inside cb-studio-board-dev is the production deployment of the development Pages project. It is not the Cloudberrie live production environment.

A *.pages.dev URL is publicly hosted by Cloudflare and can be opened from other devices. Public accessibility does not change its lifecycle classification as Development or Staging.

Promote develop to staging

Pull-request workflow is preferred:

1. In GitHub, create a pull request.
2. Set base to staging.
3. Set compare to develop.
4. Review the changed files and checks.
5. Merge the pull request.
6. Verify the staging Pages deployment and URL.

Command-line alternative:

git switch develop
git pull origin develop
git switch staging
git pull origin staging
git merge develop
git push origin staging

Promote staging to production

After QA approval:

1. Create a pull request with base main and compare staging.
2. Confirm the exact release candidate was validated.
3. Merge the pull request.
4. Verify the production deployment and custom domain.

Command-line alternative:

git switch staging
git pull origin staging
git switch main
git pull origin main
git merge staging
git push origin main

Verification checklist

• Working tree is clean before switching branches.
• Dev URL reflects the latest develop commit.
• Stage URL reflects the promoted staging commit.
• Authentication and Firestore data are validated in staging.
• No sample data appears in production mode.
• Material icons load as icons rather than text.
• Production release is performed only after approval.