Skip to main content

Starting Steps

This is the practical rollout sequence for a Salesforce team adopting trunk-based development.

1. Declare main as the only integration branch​

Set the rule first:

  • main is the shared line of development.
  • No long-lived feature branches.
  • No release train branches used for ongoing development.
  • If a short-lived branch is needed for review, it should merge within one to two days.

2. Make source control the system of record​

Before process changes can hold, the team needs one trusted representation of the app:

  • Use Salesforce DX source format.
  • Commit all metadata that materially affects behavior.
  • Minimize manual org-only configuration.
  • Document how scratch orgs and sandboxes are created from source.

If the repo is not the source of truth, trunk-based development will collapse under environment drift.

3. Standardize short-lived branch policy​

If the team uses pull requests, define the contract clearly:

  • One branch per small change.
  • One owner, or one pair.
  • Branch lifetime measured in hours or a couple of days, not weeks.
  • Delete the branch immediately after merge.

This is the main behavior change most teams need.

4. Put automated validation on every pull request​

At minimum, each pull request should run:

  • Source validation checks.
  • Linting and static analysis.
  • Targeted Apex tests or the agreed validation suite.
  • Deployment validation as early as possible.

Developers and CI should run the same build logic, and every incoming change should be verified.

Before tightening branch-age policies, audit whether the team can get useful feedback fast enough. If validation is slow, flaky, or too shallow to catch real defects, branch lifetime will grow again under pressure. Fix that first and automate it wherever possible.

5. Add a post-merge main pipeline​

Do not stop at pull-request checks. Also validate the actual shared trunk:

  • Re-run the authoritative pipeline on main.
  • Publish failures immediately.
  • Treat a broken trunk as urgent work.

Without this, the team only verifies candidate merges, not the branch everyone depends on.

6. Introduce feature rollout controls​

To avoid long-lived branches for unfinished work, add release-safe toggles:

  • Custom permissions for UI and action visibility.
  • Permission sets for audience rollout.
  • Custom metadata for behavior switches.
  • Custom setting for behavior switches and controlled rollout.
  • Abstraction-based routing for integrations and service logic.

This is the most important enabling practice for Salesforce teams that currently keep work isolated until business sign-off.

7. Release from trunk​

Do not create release branches for routine delivery. If it is built from main, it should also be released from main. Keep the cadence high and fix forward quickly.

8. Reduce dependence on long-lived sandboxes​

Keep sandboxes for integration testing, UAT, and production-like validation, but stop using them as hidden development branches.

Prefer:

  • Scratch orgs for daily isolated development.
  • CI-created validation environments when possible.
  • Repeatable setup over manually curated sandbox state.

9. Pilot with one team and a narrow scope​

Do not start with every team and every artifact type at once. A good pilot usually means:

  • One product area.
  • One repository.
  • A defined pull-request SLA.
  • A small required test suite.
  • A clear branch-age target.

Measure:

  • Average branch age.
  • Pull-request size.
  • Merge frequency to main.
  • Broken-build frequency.
  • Time from merge to validation.

10. Tighten the operating rules after the pilot​

Once the team is stable:

  • Lower acceptable branch age.
  • Require smaller pull requests.
  • Expand automation coverage.
  • Remove old release-branch habits.
  • Retire manual deployment steps that encourage divergence.

The goal is not "using Git differently". The goal is changing where and when integration happens.

11. Ship, show, ask​

Use short-lived branches to show and ask when:

  • Show and share changes to your peers.
  • Ask for review through approvals.
  • Automated validation exists but is not yet strong enough for direct trunk commits.
  • The group is moving off GitFlow or long-lived release habits in stages.

Once mature, you can ship directly when:

  • Tests catch real defects quickly.
  • Developers already review continuously through pairing or a comparable practice.
  • The team has strong shared ownership of quality.

12. Add explicit team agreements​

Agree on the working culture. Trunk-based development is not only for developers. It requires participation from everyone in the value stream.

  • Small, vertically cut stories that are verifiable.
  • Maximum branch age.
  • Expected pull-request turnaround time.
  • Required validation checks.
  • What counts as a temporary rollout control.
  • How quickly a broken main build must be addressed.
  • Deployments are not releases.

Without those working agreements, the old branch model usually reappears under schedule pressure.

13. Retrospect on friction, not just compliance​

After the first few weeks, inspect where the new flow hurts:

  • Which changes still take too long to slice.
  • Which tests are too slow to support daily integration.
  • Which metadata areas still create conflict hot spots.
  • Which flags or permissions are not being cleaned up.

That friction is where the next process improvement belongs.

References​