Skip to main content

Core Principles

These concepts are foundational to adopting trunk-based development. Use them as a compass for team decisions, tooling choices, and delivery habits.

1. One shared line of development​

The central idea is simple: the team collaborates on one branch, usually main, and avoids long-lived development branches. The goal is to share your changes and ensure compatibility with the rest of your ecosystem.

main is where the whole team meets. Every change merged there should compile, validate, and be a legitimate step toward production readiness.

For Salesforce, that means:

  • Metadata and code are tracked in version control.
  • Work-in-progress metadata and code are hidden from users and do not break existing behavior.
  • Validation and tests run on every pull request.
  • The post-merge build on main is treated as authoritative.

2. Daily integration is the threshold​

Changes are merged often, and branches should usually live for no more than one day. Keep changes flowing. The number of changes is directly related to the risk of breakage. Put simply: the more change you introduce at once, the more likely you are to destabilize the environment. Smaller changes mean smaller risk.

For Salesforce teams, that means:

  • Ensuring ways to hide your WIP from your users.
  • Changes should not break what is already delivered.
  • main should always be deployable to production at any point in time.
  • No manual sandbox changes that are untracked or did not originate from main.

3. Short-lived branches: ship, show, ask​

Pull-request workflows are fine if branches are short-lived and owned by one developer or one pair. As the team matures, move toward "ship, show, ask": integrate continuously, keep changes visible, and avoid using review as a long-running holding pattern.

When using feature-branches, they should be:

  • Branch from main.
  • Short-lived.
  • Owned by one developer or one pair.
  • Merged back to main.
  • Deleted immediately after merge.

That rule matters even more in Salesforce, where metadata conflicts become painful quickly.

4. Optimize for merge frequency, not branch comfort​

Many small integrations beat large delayed ones. That is the practical defense against merge hell.

For Salesforce teams:

  • Prefer one small metadata or Apex change set per pull request.
  • Break stories into slices that can merge independently.
  • Avoid bundling unrelated object, flow, permission, and code changes together.

5. Continuous integration is a practice​

Continuous integration is not a tool. It is not Jenkins, Azure DevOps, GitHub Actions, GitLab Pipelines, Copado, AutoRABIT, Gearset, or Bitbucket. Continuous integration is a set of practices that let teams merge frequently without fear of breaking the system.

Ask yourself:

  • Do we merge into main daily?
  • Are we protected by automated tests?
  • Can we merge safely multiple times per day?
  • Is the main branch always deployable?
  • Do we have small, deployable, individually validatable changes?

If the answer to these questions is mostly no, you do not have CI. You have a build server.

6. Incomplete work belongs behind toggles, not in branches​

When work cannot be completed in one small slice, the guidance is to keep integrating incrementally and hide incomplete behavior with feature flags or similar runtime controls.

Salesforce-friendly controls include:

  • Public Group Membership
  • Custom permissions
  • Permission sets
  • Custom metadata-driven switches
  • Hierarchy custom settings
  • Routing through Apex service abstractions
  • Connecting Components last
  • LWC Template switches

Flags are a release strategy, not a test strategy. Every commit still needs to build, validate, and remain deployable.

Temporary release flags should have:

  • An owner
  • A removal date
  • A retirement plan once the feature is stable

7. Releases ARE NOT Deployments​

Do not confuse deployments with releases.

Deployments move code or configuration into an environment. That act is technical in nature, and it should happen frequently. Nobody should need a release ceremony because you added a log statement or adjusted an internal flow path.

Releases are making the behavior changes to your users.

If every deployment automatically exposes unfinished or unapproved behavior to users, your release controls are too weak.

8. Deployments should be boring​

Teams should not have to "prepare" for a deployment. Deployments should happen frequently, like a train: consistent, predictable, and reliable.

Releases should not force deployment freezes just because a business date is approaching.

9. Avoid orgs as branching substitutes​

Sandboxes and scratch orgs are useful environments, but they should not become hidden branch models:

  • Do not let a sandbox contain a manual change.
  • Do not let a feature exist in only one sandbox. One branch should serve every environment, including production.
  • Do not let different sandboxes carry different truths for the same feature.
  • When multiple workstreams need isolated validation, deploy the same code and activate different features.

10. It takes a village​

This practice is not just for engineers. Product, project management, delivery leadership, QA, and clients all need to understand the operating model.

Do not let work sit long enough to go stale.

This practice requires participation:

  • Stories must be small enough to deliver safely. Cut them vertically, not horizontally.
  • Weak or missing tests must be treated as delivery risks. Acceptance tests are first-class citizens in the definition of done.
  • Engineers control deployments, Product controls releases.
  • Get feedback as early as possible. Production deployment is also feedback: it proves the change did not break the system in real conditions.

11. Measure branch age and integration health​

Before changing policy, establish baseline metrics. A Salesforce team should track at least:

  • Branch lifetime: average time from branch creation to merge.
  • Integration health: merge conflicts per week and time spent resolving them.
  • Delivery speed: time from commit to validated deployment.
  • Quality indicators: pipeline duration, test failure rate, and deployment incidents.

Good starting targets:

  • Branch lifetime moves from weeks to days, then to hours.
  • Each developer integrates to trunk at least once per day.
  • The main validation pipeline is fast enough to support frequent merges.

12. Small commits and behavior-focused tests​

Small, atomic commits make frequent integration possible. The matching safety net is behavior-focused testing.

In practice:

  • Split work into mergeable slices.
  • Prefer tests that protect observable behavior instead of internal implementation.
  • Use short Three Amigos (Engineering, Product, QA) conversations when a story is fuzzy or likely to branch in several directions.

13. What this means for Salesforce teams​

The practical goal is not to look more modern in Git. The goal is to shorten the time between change, integration, validation, and release confidence.

For Salesforce teams, that means:

  • Stop treating long-lived sandboxes and long-lived branches as the place where integration happens.
  • Keep pull requests narrow enough that Apex, metadata, permissions, and automation can still be reviewed together.
  • Validate the same source package shape locally and in CI.
  • Make deployments boring: reliable, on time, and repeatable.
  • Protect what already works with tests.

References​