Branching Model
flxbl projects follow Trunk Based Development. Developers work on short-lived feature branches, open a pull request, and — once validation passes and reviewers are happy — merge into the trunk, the main branch. Because flxbl uses an artifact-based deployment model, branches are delinked from production: each merge produces a release candidate, a versioned collection of artifacts, and that artifact is what gets deployed — not the branch.
How it works
A developer works on a small piece of functionality on a short-lived feature branch. When it is ready, they raise a pull request to integrate it into main. codev validates the change against a real org before it merges, and once reviewers approve, it merges immediately.
Each merge into main creates a release candidate for the impacted domain, deployable to production. A release candidate is a collection of artifacts and an associated version number, generated at every commit on the trunk — defined by a release definition and built automatically by codev on merge. The branch the work happened on plays no further part; the artifact is the unit of deployment.
flxbl recommends the ship / show / ask pattern for pull requests to keep throughput high. See ship/show/ask.
Scaling to multiple release lines
Most teams need only the trunk. When you have to support more than one release line at once — a long-running release/* branch alongside main, for instance to stabilise a release while the trunk moves on — flxbl scales to Scaled Trunk Based Development without changing the model.
codev treats a release branch like the trunk. Merges to a release/* branch build and validate the same way and produce their own release candidates. You can bind an environment to release/* so those builds deploy to it, and a cascade keeps the release branch and the trunk from drifting apart by opening and merging the integration pull requests automatically. If your team does not deploy continuously, or works in a single domain, the same machinery supports a branch-for-release approach.
Applying patches and hotfixes
High-throughput flxbl projects should prefer a roll-forward strategy over patching an existing release.
Because a flxbl project runs on multiple independently deployable domains, a patch or hotfix is scoped to a domain. codev creates a just-in-time release branch from the exact state of a release candidate — a temporary branch holding the artifacts that make up what is currently in production — applies the fix there, builds new artifacts, and deploys them. The fix is then propagated back into the trunk.
codev runs this from the Patch action on a release candidate; sfp-pro is the engine underneath. See Patch a release candidate.