DEV Community: Nat Young

Done means released. Everything else is inventory.

Nat Young — Fri, 29 May 2026 13:08:35 +0000

Part 3. Part 1 was trunk-based development. Part 2 was continuous integration. Trunk-based development and CI enable Continuous Delivery.

What it is

Continuous Delivery means the head of master/main is always kept in a deployable state. The functionality is releasable to users, on demand, whenever the business decides.

Release is a business decision. The code is always ready to go. The question is whether you want to release it now.

On "CD won't work here." Every organisation thinks it is special. There are special rules and regulations that mean CD is not possible at their particular company. Despite evidence to the contrary from the research output from DORA data across thousands of organisations, including regulated industries, government, and finance. The rules blocking CD may or may not really exist, but they are rarely examined closely enough to find out.

How to actually do it

CD is the result of everything before it working together:

Trunk-based development - everyone commits to trunk, decoupling strategies keep incomplete work hidden
Continuous integration - every commit is verified by a fast automated build and test suite
Automated deployment - deploying is a scripted, repeatable, non-event
Monitoring and rollback - you can detect problems quickly and recover quickly

When any of these are missing, teams batch up changes, deploy infrequently, and accumulate risk.

Deploy and release are separate

Deploy: the code made it through to production.
Release: users are experiencing the change.

These are two different events. The gap between them should be a deliberate business decision, not an accident or a "big bang" release. When it is, risk accumulates.

You can deploy many times before releasing. Each deploy is a technical (non) event. Code moves to production, behind a feature flag or dark launch. Release is the human decision to make the change visible to users.

"Done" means released to end users. Not the dev environment, or done but "waiting for QA".

Tracking it with Mainline

The world's premier upcoming project management tool for teams that don't suck and are really good looking, Mainline, separates deploy and release as distinct events in a story's lifecycle.

Deploy events are recorded via webhook from your pipeline. Automated, system-level, no human action needed. The deploy count on each story shows how many times code has been pushed to production.
Release is a human decision. Someone on the team marks the story as released when users are experiencing the change.
Inventory shows the gap - stories that have been deployed but not released. In Flight (0-3 days) is normal. Aging (4+ days) is worth noticing. Stale means a decision hasn't been made.

The goal is that nothing sits in inventory by accident. Every unreleased story should be a conscious decision, not a forgotten deploy.

The progression

Trunk-based development enables continuous integration. Continuous integration enables continuous delivery. Each practice builds on the last.

The practices are a chain, and the weakest link determines what is actually possible. A team developing on feature branches has a ceiling regardless of what else it does well.

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

You have a CI pipeline. You're probably not doing CI.

Nat Young — Wed, 27 May 2026 15:19:00 +0000

Part 2. Part 1 covered trunk-based development. This is what comes next: the practice that most teams claim to do but almost none actually are.

The difference between "we have a CI pipeline" and "we practice continuous integration" is the difference between owning running shoes and running.

What it is

CI is the practice of integrating code to trunk (main, master) continuously, at least once a day. Every integration is verified by an automated build and test suite. If the build breaks, fixing it is the team's immediate priority.

Nobody pushes on a broken build. If the build is not fixed within a reasonable timeframe, the breaking change is reverted to unblock the rest of the team.

How to actually do it

If you have trunk-based development in place, CI requires three things:

Small commits. Each commit is either a complete, working increment or an unfinished increment that lives under one of the decoupling strategies mentioned in Part 1. It is a change that leaves the system working.
A fast automated build. The regression tests must run on every single commit. If this takes more than ten minutes, it is too slow. Developers will stop running it.
Fix broken builds immediately. A red build means trunk is broken and nobody can integrate until it is fixed. The team stops and fixes it, pulling a cord and "stopping the line".

On separate QA teams. Teams that practice CI bake quality into the product through executable specifications written in tandem with the production code instead of trying to inspect it in later. A separate QA process hinders integration because it introduces a batch-and-queue stage between writing code and knowing if it works. The developer commits, moves on to the next thing, and days later gets a defect report from a different team with different context.

Quality is built in to the product by the people writing the code through TDD, pairing or ensemble programming (QA included), and automated tests that run on every commit. A separate QA team testing after the fact is an attempt to inspect quality into a system after it has already been built. At that point, it's too late.

The pipeline

A CI pipeline verifies every commit to trunk. Keep it fast.

Stages

Lint and static analysis. Catches formatting, style violations, some security concerns, and obvious errors.
Unit tests. Fast and isolated. The bulk of the test suite.
(Component) Integration tests. Verify components work together across local boundaries.
Build artefact. Produce the deployable thing.
Deploy. Automated deployment to non-production and production environments.

On distributed systems. The above example is the shape of a bare minimum pipeline for a single deployable unit/monolith. Distributed systems introduce complications, as each service now needs its own pipeline, and a mechanism to detect if a change to one service breaks another without having to wait for every other service to be deployed to a shared environment.

Contract-driven development solves this problem by allowing each service to be tested in isolation without standing up the whole system.

See also: Specmatic, Pact

One path to production

The CI pipeline should be the only way to get code from the local machine into production. Shortcuts and "hotfix" branches are a symptom of a missing CI practice.

Test-driven development

TDD matters for CI because of what it produces:

When you write the test first, you get two things: a test suite that actually covers the behaviour (because every behaviour was driven by a test), and small, incremental steps (because you only write enough code to pass the next test). Both of these are exactly what CI needs, good coverage and small commits.

Critically, you are building up a regression suite beside the code. This regression suite serves to replace the separate "testing phases" that denote waterfall development.

Teams that write tests after the fact tend to have gaps in coverage and larger, riskier commits. Teams that practice TDD tend to commit more frequently and with more confidence.

TDD doesn't just include unit tests. The process often begins with something higher level, such as a contract test or integration test.

Common misconceptions

"We have a CI pipeline, so we do CI"

Most teams that say they do CI are running a pipeline on pull requests against feature branches. CI requires the pipeline to run against trunk on every commit. Everything else is just a build system.

"We can't do CI because we need code review for compliance"

Pair programming satisfies review requirements. Two people wrote and reviewed the code together, in real time. The commit log can be used to show who was on the story. If your compliance framework requires evidence that code was reviewed before production, a pairing record is stronger evidence than a rubber-stamp approval on a PR that sat in a queue for days, then was read by someone else, who was working on something else.

If your organisation genuinely requires asynchronous sign-off, find out exactly which policy mandates it and what it actually says.

Always ready to release

If you are doing trunk-based development and CI, the head of master is always in a releasable state. Every commit passed the pipeline. Every commit is a complete increment or under a deployment-release decoupling strategy.

On how long it takes. Ask your team: how long does it take to get a one-line change to production? If the answer is days or weeks, the bottleneck is delivery. The code was ready in minutes. Everything after that is process, ceremony, and waiting.

In this case, the Theory of Constraints and Value Stream Mapping can be used to help to identify and release bottlenecks in the system.

Goldratt, E.M. (1984) The Goal. Great Barrington: North River Press.

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

Are you really doing CI/CD?

Nat Young — Wed, 20 May 2026 20:40:26 +0000

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:

Strategies that decouple the act of deploying code from the act of releasing the code
A test suite that is fast, and gives you the confidence that every commit is releasable
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.