Are you really doing CI/CD?

No. There's no such thing as 'CI/CD'. CI and CD are two distinct things, and you're probably not doing them either. This is Part 1: how to actually do trunk-based development.

What it is

Everyone commits directly to trunk (master or main). Short-lived branches that last for hours are acceptable, long-lived feature branches that live for days are not.

This is the foundation for continuous integration (CI). You cannot integrate continuously if you are not frequently integrating to the same place.

Trunk-based development using TDD and small batch sizes greatly simplifies code integration.

On feature branches. Open source projects accept contributions from unknown parties. There is, and should be, zero trust. Feature branching and pull requests make sense in that context.

Many closed-source teams have adopted the same workflow under a completely different context. In a team where everyone is trusted, long-lived feature branches simply add integration pain with no real benefit. They are an isolation chamber. The longer a branch lives, the further it drifts from trunk, and the more painful the merge. It's a form of safety theatre that disguises deferred pain.

How to actually do it

Commit to trunk at least once a day. If you use branches, keep them short-lived. The head of master stays deployable at all times.

This requires three things:

1. Strategies that decouple the act of deploying code from the act of releasing the code
2. A test suite that is fast, and gives you the confidence that every commit is releasable
3. Small, incremental changes instead of large batch deliveries

Deploy-Release Decoupling strategies

To commit incomplete work to trunk without breaking what is already there, you need ways to decouple deployments from releases. These are the techniques that make trunk-based development safe.

Feature flags

Ship the code, hide the feature behind a conditional. Users do not see it until you flip the flag. Remove the flag when the feature is released and verified.

When to use: UI changes, risky features, gradual rollouts. Any work that will take more than a day and touch code paths users interact with.

This technique requires tests for both the flag on and off conditions to run while active. Once released, a clean-up step is performed to remove the flag, the inactive path, and its tests. This isn't "technical debt", it's a path to continuous integration.

Ruby

if feature_enabled?(:new_checkout)
  render_new_checkout
else
  render_current_checkout
end

Python

if feature_enabled("new_checkout"):
    render_new_checkout()
else:
    render_current_checkout()

Java

if (featureEnabled("newCheckout")) {
    renderNewCheckout();
} else {
    renderCurrentCheckout();
}

TypeScript

if (featureEnabled("newCheckout")) {
  renderNewCheckout();
} else {
  renderCurrentCheckout();
}

On feature flag platforms. Feature flags as described here are a development technique. A conditional that exists temporarily so incomplete work can live on trunk safely. The feature rollout and the flag share the same lifecycle.

In recent years, an entire industry has grown up around feature flags that has twisted the term from the original use case. In that world, flags are permanent infrastructure, managed in a third party system's dashboard, with targeting rules, audience segments, percentage rollouts, and analytics. This type of flag is a business facing feature flag, and often a permanent fixture. There is a distinction between development and business feature flags.

The result is that many teams now associate "feature flags" with a platform they pay for and a dashboard they maintain, rather than an if/else block they delete next week. The technique predates the platforms by decades. You do not need a vendor to put a conditional in your code.

If you have hundreds of flags in production and no plan to remove any of them, you do not have a trunk-based development practice. You have a configuration management problem wearing a different hat.

Branch by abstraction

Introduce an abstraction layer (interface, facade, adapter) in front of the existing implementation. Build the new implementation behind the same interface. Route traffic through the abstraction layer. This could be a hard switch, percentage-based, or per-tenant.

When to use: replacing infrastructure, swapping libraries, rewriting subsystems. Unlike a feature flag, branch by abstraction (BBA) is structural. The abstraction layer stays after the migration. You can shift traffic incrementally, e.g. 10% to the new implementation, monitor, increase, rather than flipping a boolean.

Ruby

# Step 1: Introduce abstraction in front of existing code
class PaymentGateway
  def initialize
    @legacy = LegacyGateway.new
  end

  def charge(amount)
    @legacy.charge(amount)
  end
end

# Step 2: Build new implementation behind the same interface
class NewGateway
  def charge(amount)
    new_provider.create_charge(amount)
  end
end

# Step 3: Route through the abstraction layer
class PaymentGateway
  def initialize(rollout_pct: 0)
    @legacy = LegacyGateway.new
    @new = NewGateway.new
    @rollout_pct = rollout_pct
  end

  def charge(amount)
    if rand(100) < @rollout_pct
      @new.charge(amount)
    else
      @legacy.charge(amount)
    end
  end
end

# Step 4: 100%, remove legacy
class PaymentGateway
  def initialize
    @new = NewGateway.new
  end

  def charge(amount)
    @new.charge(amount)
  end
end

Python

# Step 1: Introduce abstraction in front of existing code
class PaymentGateway:
    def __init__(self):
        self._legacy = LegacyGateway()

    def charge(self, amount):
        self._legacy.charge(amount)

# Step 2: Build new implementation behind the same interface
class NewGateway:
    def charge(self, amount):
        new_provider.create_charge(amount)

# Step 3: Route through the abstraction layer
class PaymentGateway:
    def __init__(self, rollout_pct=0):
        self._legacy = LegacyGateway()
        self._new = NewGateway()
        self._rollout_pct = rollout_pct

    def charge(self, amount):
        if random.randint(0, 99) < self._rollout_pct:
            self._new.charge(amount)
        else:
            self._legacy.charge(amount)

# Step 4: 100%, remove legacy
class PaymentGateway:
    def __init__(self):
        self._new = NewGateway()

    def charge(self, amount):
        self._new.charge(amount)

Java

// Step 1: Introduce abstraction in front of existing code
class PaymentGateway {
    private final LegacyGateway legacy = new LegacyGateway();

    void charge(BigDecimal amount) {
        legacy.charge(amount);
    }
}

// Step 2: Build new implementation behind the same interface
class NewGateway {
    void charge(BigDecimal amount) {
        newProvider.createCharge(amount);
    }
}

// Step 3: Route through the abstraction layer
class PaymentGateway {
    private final LegacyGateway legacy = new LegacyGateway();
    private final NewGateway next = new NewGateway();
    private final int rolloutPct;

    PaymentGateway(int rolloutPct) {
        this.rolloutPct = rolloutPct;
    }

    void charge(BigDecimal amount) {
        if (ThreadLocalRandom.current().nextInt(100) < rolloutPct) {
            next.charge(amount);
        } else {
            legacy.charge(amount);
        }
    }
}

// Step 4: 100%, remove legacy
class PaymentGateway {
    private final NewGateway next = new NewGateway();

    void charge(BigDecimal amount) {
        next.charge(amount);
    }
}

TypeScript

// Step 1: Introduce abstraction in front of existing code
class PaymentGateway {
  private legacy = new LegacyGateway();

  charge(amount: number) {
    this.legacy.charge(amount);
  }
}

// Step 2: Build new implementation behind the same interface
class NewGateway {
  charge(amount: number) {
    newProvider.createCharge(amount);
  }
}

// Step 3: Route through the abstraction layer
class PaymentGateway {
  private legacy = new LegacyGateway();
  private next = new NewGateway();

  constructor(private rolloutPct = 0) {}

  charge(amount: number) {
    if (Math.random() * 100 < this.rolloutPct) {
      this.next.charge(amount);
    } else {
      this.legacy.charge(amount);
    }
  }
}

// Step 4: 100%, remove legacy
class PaymentGateway {
  private next = new NewGateway();

  charge(amount: number) {
    this.next.charge(amount);
  }
}

Dark launch

Run the new code path in production alongside the old one, untethered from any existing user facing interface.

When to use: performance-critical paths, algorithm changes, or switching over a backend capability with a new one. Validation happens in production with real data.

The shadow path is removed when the team is confident in the new implementation.

Ruby

def calculate_shipping(order)
  legacy_result = LegacyShipping.calculate(order)

  NewShipping.calculate(order).then do |new_result|
    if new_result != legacy_result
      log_discrepancy(order, legacy_result, new_result)
    end
  end

  legacy_result
end

Python

def calculate_shipping(order):
    legacy_result = LegacyShipping.calculate(order)

    new_result = NewShipping.calculate(order)
    if new_result != legacy_result:
        log_discrepancy(order, legacy_result, new_result)

    return legacy_result

Java

BigDecimal calculateShipping(Order order) {
    BigDecimal legacyResult = legacyShipping.calculate(order);

    CompletableFuture.runAsync(() -> {
        BigDecimal newResult = newShipping.calculate(order);
        if (!newResult.equals(legacyResult)) {
            logDiscrepancy(order, legacyResult, newResult);
        }
    });

    return legacyResult;
}

TypeScript

function calculateShipping(order: Order): number {
  const legacyResult = LegacyShipping.calculate(order);

  NewShipping.calculate(order).then((newResult) => {
    if (newResult !== legacyResult) {
      logDiscrepancy(order, legacyResult, newResult);
    }
  });

  return legacyResult;
}

Common misconceptions

"Long-lived branches are safer"

They may feel safer because the integration is deferred, but it still needs to happen. The risk accumulates with both the batch size and delay.

"But I merge master into my branch continuously"

Do you also merge every other team member's branch into yours in that transaction? They do not have your code either. Merging master into your branch is one-directional. That's pulling a delta view of the real code in flight, not integrating. Your changes are invisible to everyone else until you merge back, which might be days or weeks later. That's not integration either.

"We need code review before merging to trunk"

Pair programming gives you continuous code review with no delay. If you pair on the work, the review already happened. If you need asynchronous review, keep the branch to hours - review it the same day. The alternative is comments about code structure or formatting that arrive days later, when the context is gone and the cost of change is high.

"Our team is not ready for this"

Start with one story. Commit it to trunk behind a feature flag. See what happens. The practice is learned by doing it, not by preparing for it.

"But we use 'AI' and agentic workflows"

Higher code output velocity makes trunk-based development in small increments with TDD and CI more important, not less. When code is generated faster, integration risk grows faster too. A tool that produces a thousand lines on a branch in an hour creates the same merge problem as a developer who did it in a week.

Summary

Teams that develop on long-lived feature branches cannot do continuous integration. Teams that cannot do continuous integration cannot do continuous delivery. The branch and pull request model is the bottleneck.

---

This is part of the Mainline documentation. Mainline is a project management tool for teams that ship continuously.