Bubble.io Branch Management

Bubble Branching SOP

Overview

This workflow keeps Main always stable, coordinates parallel development, ensures one daily integration into a shared QA environment, and allows sprint-based releases to production.

Branch Structure

Live                        → Production
Main                        → Stable release candidate
qa-test-branch              → Daily integrated build / QA environment
feature/<dev>/<ticket>      → Individual development branches

Core Principles

All feature work happens in feature/<dev>/<ticket> branches.
qa-test-branch is the shared integration environment, updated once per day at the end of the workday.
Developers pull updates from qa-test-branch into their feature branches daily to stay in sync.
Conflicts are resolved in feature branches, never in QA or Main.
Main only receives changes once QA has approved the sprint release.
QA tests are performed on the qa-test-branch, not Main.
Live is updated only during end-of-sprint release.
Team communicates in Slack for sensitive merges (conflict-heavy, pre-release, hotfixes).

Daily Development Workflow

1) Work Normally in Feature Branch

feature/<dev>/<ticket>

2) Preparing a Feature for QA (Move to Ready for Revision)

A feature may move to Ready for Revision only after:

Functionality completed and tested locally.
Perform sync:

Main → feature/<dev>/<ticket> qa-test-branch → feature/<dev>/<ticket>
Resolve conflicts in the feature branch.
Re-test locally.

3) Daily QA Integration (End of Workday)

Performed once per day:

qa-test-branch ← all feature branches in Ready for Revision

This creates a single stable daily build for QA.

4) Developers Sync With the New Baseline

After the daily QA merge is complete, every developer updates their feature branch:

feature/<dev>/<ticket> ← qa-test-branch

This ensures:

Everyone is working from the same unified integrated state
No one depends on Main for daily updates
Main remains clean and stable

5) QA and Client Testing (Next Day)

Result	Action
Approved	Feature waits in qa-test-branch for release
Rejected	Card moves to QA → Developer fixes in feature branch → Will be included in next day's integration merge

Release to Main (When Sprint QA Passes)

Performed by TL or Lead Dev

Condition	Action
Main unchanged since integration	`Main ← qa-test-branch`
Main changed since integration	`qa-test-branch ← Main` → quick smoke test → `Main ← qa-test-branch`

Sprint Release to Live

Performed once per sprint:

Live ← Main

Followed by QA smoke testing in production.

Board Columns

To Do → Doing → Ready for Revision → QA (if needed) → Done

Testing is tied to the daily integration.

Guardrails

Never merge feature branches directly to Main or Live.
Conflicts are always fixed in feature branches.
qa-test-branch receives merges once per day only.
Only TL or Lead Dev may:
- Merge qa-test-branch → Main
- Deploy Main → Live
Team must communicate via Slack during sensitive merges.

Process Summary Diagram

feature/<dev>/<ticket>
        ↓ (Ready for Revision)
[End of Day] qa-test-branch ← feature branches
        ↓
feature/<dev>/<ticket> ← qa-test-branch (next morning sync)
        ↓
QA tests qa-test-branch
        ↓
If approved batch → Main
If sprint done → Live

Contact Information

For questions or further clarifications, please contact:

Team Lead: Douglas Noldor douglas@lowcode.agency