DEV Community

Cover image for Build once, deploy everywhere (why this is still weirdly hard)
<devtips/>
<devtips/>

Posted on

Build once, deploy everywhere (why this is still weirdly hard)

#git #github #webdev #programming

GitHub Actions finally gave us the tools to stop rebuilding the same app three times but most of us are still fighting our pipelines instead of trusting them.

I swear we’ve automated everything except the part where deployments stop feeling cursed.

We have containers. We have IaC. We have CI/CD platforms that can spin up runners faster than my coffee cools down. And yet somehow, every team still has that one Slack message:

“Uh… it works in staging.”

That phrase has survived Docker, Kubernetes, and at least three rebrands of CI tooling. It’s the cockroach of modern software delivery.

The pitch sounds so clean: build once, deploy everywhere. One artifact. Multiple environments. No surprises. No “just this one tiny prod change.” No YAML copy-pasta that slowly mutates into three incompatible pipelines over six months.

And yet… here we are.
Staring at GitHub Actions workflows that look identical but behave like completely different species.

What changed recently isn’t that GitHub Actions suddenly became good. It’s that teams finally started using it differently. Reusable workflows. Artifact promotion. Environment-aware deploys that don’t rebuild the universe every time you switch from dev to prod.

The tooling caught up. Our habits didn’t.

TL;DR:
Most multi-environment pain isn’t about complexity it’s about duplication.
If you treat builds as disposable and environments as special snowflakes, your pipeline will lie to you. If you treat builds as sacred and deploys as boring, everything gets calmer. GitHub Actions can do this now… if you let it.

The real problem isn’t environments it’s duplication

Let’s be honest for a second:
most “multi-environment complexity” is self-inflicted.

Not because environments are hard, but because we keep copy-pasting the same workflow and calling it architecture.

You start with one GitHub Actions file. It’s clean. It works. Life is good.
Then someone says, “We need staging.”
So you duplicate the file. Change a few env vars. Maybe a different secret name. Done.

Then prod shows up. Duplicate again.
Now you have three workflows that look the same but absolutely are not.

This is how pipelines slowly drift apart. Not in dramatic ways. In tiny ones.

A flag added here.
A step reordered there.
A permissions tweak someone forgot to backport.

Six months later, nobody can explain why prod deploys take longer, staging skips a step, and dev somehow still passes even when the build is broken.

I’ve literally diffed two workflows named deploy.yml and deploy-prod.yml that were “basically identical” except for twelve small differences that all mattered.

This is the part nobody likes to admit:
humans are terrible at keeping duplicated YAML in sync.

We already learned this lesson with infrastructure. Nobody writes three Terraform stacks by hand anymore and hopes they stay aligned. We abstract. We parameterize. We reuse.

But CI?
For some reason we still treat it like a copy-paste zone.

And it gets worse as teams grow.

Once more than one person touches the pipeline, ownership disappears. Everyone’s afraid to refactor it because “it works right now.” Changes get layered on top instead of folded inward. The workflow becomes folklore instead of code.

At that point, environments stop being environments.
They become personalities.

Dev is chill.
Staging is suspicious.
Prod is aggressive and remembers everything you’ve ever done wrong.

And when something breaks, the postmortem always sounds the same:

“We don’t know why prod behaved differently. The workflows are basically the same.”

They’re not.
They just used to be.

This is why “build once, deploy everywhere” isn’t a slogan it’s a defense mechanism.
The moment you stop duplicating logic is the moment environments stop gaslighting you.

And yes, GitHub Actions finally gives us the tools to do that properly.
We just have to unlearn the habit of cloning YAML and hoping for the best.

“Build once” doesn’t mean “deploy blindly”

This is where a lot of teams accidentally faceplant.

They hear build once, deploy everywhere and translate it into:
“Cool, we’ll just ship the same thing to prod and hope nothing explodes.”

That’s not the point.
That’s how you end up rebuilding trust tickets instead of software.

Build once isn’t about skipping checks or pretending environments don’t exist. It’s about deciding that the build is the single source of truth — and everything after that is just controlled exposure.

Think about how most pipelines still work today.

Dev builds the app.
Staging builds the app again.
Prod builds it one more time, just in case.

Same repo. Same commit. Three different builds.

On paper, that sounds harmless. In reality, you’ve just created three parallel universes. Slightly different dependencies. Slightly different runners. Slightly different timing. And suddenly your “same code” is not actually the same code anymore.

I learned this the hard way when a hotfix went through staging perfectly, then behaved differently in prod. Same commit hash. Same Dockerfile. Different build. Different outcome. Nobody felt great about it.

That’s when it clicked: rebuilding per environment breaks traceability.

If prod fails, you want to know exactly what failed.
Not which of the three builds lied to you.

This is why artifact-first thinking matters.

You build once.
You name it.
You tag it.
You checksum it if you’re paranoid (you should be).

That artifact whether it’s a Docker image, a binary, or a packaged bundle is now immutable. Dev, staging, and prod don’t get their own versions of reality. They all consume the same thing.

The differences move out of the build and into deployment.

Secrets.
Feature flags.
Config injected at runtime.

That’s where environments are supposed to differ.

And no, this doesn’t mean deploying blindly. You still gate prod. You still run checks. You still require approvals. The difference is that you’re validating promotion, not rebuilding the universe every time you cross an environment boundary.

Once you make that shift, failures become clearer.

If dev fails, the build is broken.
If staging fails, your config is wrong.
If prod fails, it’s either data, scale, or reality reminding you who’s boss.

That clarity is underrated.

It’s also why teams that stop rebuilding per environment suddenly feel calmer. Fewer “but staging worked” arguments. Fewer mystery bugs. Fewer nights spent diffing logs that shouldn’t be different in the first place.

Build once doesn’t remove risk.
It contains it.

And that’s the whole game.

Reusable workflows are the cheat code nobody explained properly

This is the part where GitHub Actions quietly fixed the problem… and almost nobody noticed.

For years, Actions felt powerful but awkward. You could do a lot, but reuse was basically vibes and copy-paste. Then workflow_call showed up, and suddenly workflows stopped being scripts and started acting like APIs.

Most teams still haven’t mentally caught up.

A reusable workflow isn’t “advanced GitHub Actions.”
It’s just stopping YAML duplication with extra steps.

Here’s the mental shift that matters:

  • One workflow builds
  • Other workflows call it
  • Environments stop owning logic they just pass inputs

Instead of this (you’ve seen this):

# deploy-dev.yml
steps:
  - run: npm ci
  - run: npm run build
  - run: deploy --env=dev
# deploy-prod.yml
steps:
  - run: npm ci
  - run: npm run build
  - run: deploy --env=prod

You do this once:

# .github/workflows/build.yml
name: build

on:
  workflow_call:
    outputs:
      image:
        description: built image tag
        value: ${{ jobs.build.outputs.image }}
jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.meta.outputs.image }}
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .
      - id: meta
        run: echo "image=myapp:${{ github.sha }}" >> $GITHUB_OUTPUT

Now environments become thin wrappers instead of snowflakes:

# deploy-prod.yml
jobs:
  build:
    uses: ./.github/workflows/build.yml

deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: deploy --image ${{ needs.build.outputs.image }} --env prod

That’s it.
No magic. No ceremony. Just one place where building happens.

The payoff isn’t fewer lines of YAML. It’s fewer lies.

When a build breaks, it breaks everywhere.
When a deploy breaks, you know it’s environment-related.
And when someone wants to “just tweak prod,” they have to do it in the open.

Reusable workflows force discipline not by policy, but by structure.

They also scale weirdly well. One team can own the build workflow. Other teams consume it. You version it. You review it. You stop treating CI like a haunted attic nobody wants to clean.

Are they perfect? No. Debugging cross-workflow failures can be annoying. Inputs take getting used to. You’ll swear at needs.outputs at least once.

But compared to cloning YAML and praying?
This is a massive upgrade.

Once you treat workflows like shared infrastructure instead of disposable scripts, “build once, deploy everywhere” stops being a Medium slogan and starts being… boring.

And boring, in CI, is elite.

Environments should be boring and that’s a compliment

If your environments have personalities, something already went wrong.

Dev shouldn’t be “chill.”
Staging shouldn’t be “weird but mostly fine.”
Prod definitely shouldn’t feel like a boss fight.

Environments are not supposed to behave differently. They’re supposed to run the same thing under different constraints. Different data. Different scale. Different blast radius. That’s it.

The moment behavior starts drifting, people compensate in the worst ways. Extra conditionals. Special cases. “Only in prod” flags that live forever. Suddenly your pipeline isn’t enforcing reality anymore it’s negotiating with it.

Boring environments fix that.

When you build once and promote the same artifact, environments stop owning logic. Config moves to runtime. Feature flags replace env-specific builds. Secrets live where they belong instead of being sprinkled through workflows like landmines.

This is where GitHub Environments actually shine. Not as protection theater, but as guardrails. Approvals, secrets, and deploy rules live outside the build. You don’t need three pipelines you need one build and a calm, predictable promotion path.

The best sign you’re doing this right?

A junior dev can deploy without a checklist.
A rollback doesn’t require archaeology.
Nobody says “don’t touch prod” anymore.

Boring doesn’t mean careless.
It means under control.

And in CI/CD, that’s the highest compliment you can earn.

Conclusion build once isn’t about tools, it’s about trust

At some point, this stops being a GitHub Actions conversation and turns into a people one.

When you rebuild per environment, you’re implicitly saying: I don’t fully trust this build.
When you duplicate workflows, you’re saying: I don’t trust abstraction.
When prod behaves differently, the team stops trusting the pipeline and then nobody wins.

Build once, deploy everywhere flips that.

One build. One truth. Everything else is just controlled exposure.

It’s not about being fancy or chasing “best practices.” It’s about making failures legible. When something breaks, you should immediately know whether it’s the code, the config, or reality doing its thing. No archaeology. No YAML diff marathons.

GitHub Actions didn’t magically solve CI/CD. It just finally gave us the primitives to stop lying to ourselves. Reusable workflows. Artifact promotion. Boring environments.

The rest is a mindset shift.

The future of delivery isn’t more automation it’s less ambiguity. Fewer pipelines. Fewer special cases. Fewer rituals passed down like tribal knowledge.

If your deploys feel calmer than they did last year, you’re doing it right.

And if they’re boring?

Congrats. That’s the goal.

Helpful resources

Top comments (0)