Your CI/CD Pipeline Is Now Your Product

Remember when deployment was the easy part? Push to main, run the build, ship it. One pipeline, one path to production, maybe a nervous lunch while Jenkins did its thing.

Those days are gone, and they're not coming back.

Olaf Molenveld, technology advisor at CircleCI, frames the shift in terms I haven't heard before: "We are in the business of building the machines that allow you to deliver your software at scale with the right quality." Not managing code. Building the machines that manage code. The factory metaphor goes deeper than I expected.

The Factory That Builds Factories

Molenveld brings up Northvolt, the European battery manufacturer that went under a few months ago. The cause of death wasn't bad battery design—it was their inability to manage the automation machinery that produced batteries at scale. "There's only a few Chinese companies that are able to build these machines," he notes, "and they only have the engineers that are able to configure these machines."

The parallel to modern software delivery is uncomfortably precise. Your deployment pipeline isn't supporting infrastructure anymore. It's a product with its own failure modes, scaling challenges, and expertise requirements. When your pipeline breaks, your cars don't ship. And unlike Northvolt, you can't blame the Chinese.

What changed? Microservices, mostly. When everything lived in one monolithic codebase, you had one build to manage. Update the database schema, run the tests, deploy the artifact. Done. But slice that monolith into services, and suddenly you're managing dependencies between codebases. Update this service—does it break that one? Which tests need to run when you touch this corner of the monorepo?

"If I change something in my delivery pipeline, in my factory," Molenveld asks, "how do I make sure that it's not breaking something somewhere else in my ecosystem?" The same question we've been asking about code for decades, now applied one layer up.

The Pendulum Swings (Again)

Here's where it gets interesting: we've seen this movie before. Early CI/CD meant bash scripts and Groovy nightmares in Jenkins. Everyone hated maintaining them, so the industry moved to declarative YAML pipelines—structured, readable, deterministic. Problem solved.

Except now we're moving back to code. Why? Because YAML can't handle the complexity anymore. "I want to codify CI as code," Molenveld observes teams saying, "because then I can create tests and I can do all this automation that I want to do."

This isn't failure—it's the natural progression of any system that gets complex enough. We abstract until abstraction becomes a liability, then we drop down a level. The difference now is that we're doing it with better tools (Dagger, TypeScript SDKs) and combining approaches rather than replacing them wholesale. Use the CI/CD platform as orchestrator, write your logic in actual code, debug with proper tracing tools.

This hybrid approach feels like we're finally learning from past cycles rather than just repeating them. Maybe.

Deploy vs. Release (Yes, They're Different)

One distinction Molenveld emphasizes: deploying isn't releasing. "Deploying is effectively something technical, but releasing is more like opening it up to people that can start using it and then you start getting the feedback."

This matters more than it sounds. If you conflate the two, you lose the ability to deploy without exposing changes. No canary releases, no alpha testing, no gradual rollouts. You're back to crossing your fingers and hoping the deploy works for everyone at once.

The tooling has caught up to this distinction—CircleCI now supports both agent-based deployments to Kubernetes clusters and agentless approaches that monitor specific ports or metrics. The flexibility is necessary because "everywhere is different," as Molenveld puts it. What constitutes a successful deployment at your company might mean something entirely different at mine.

AI: The Obligatory Topic

We can't talk about developer tools in 2024 without mentioning AI, apparently. AWS's Julian Wood opened the conversation noting he was "coding with AI assistants this morning and building some awesome scripts which just blew my mind how productive I can be as a terrible coder."

Fair enough. AI-assisted coding is genuinely useful for generating scripts and boilerplate. But here's what the conversation didn't explore: if AI makes writing code dramatically easier, does that mean we'll write more code? And if we write more code, do our deployment pipelines become even more complex?

Molenveld's focus remains on the question that predates AI and will outlast the current hype: "Why do we write software?" His answer: "We write software because we want to create value for the users of the software." Getting that software into users' hands—regardless of whether you wrote it with Copilot or vi—remains the actual challenge.

"You can write the most beautiful code, like really awesome regular expressions that you're super proud of," Molenveld says. "If nobody's using that code or the application that code is making up, then what's the use? You design this beautiful car with the most awesome features, but there's no factory line."

The Pipeline Problem Nobody Talks About

Here's what struck me: we've spent 25 years optimizing for developer productivity—better languages, better frameworks, better IDEs. But the thing that actually gets software to users? That's still black magic to most teams. You can have the world's best engineers writing immaculate code, and still fail because nobody can reliably deploy it.

The modern reality, as Wood notes, is "you never have one pipeline." Every feature branch, every microservice, every component can have its own pipeline that spins up dynamically, runs its checks, and tears down. This is powerful. It's also a coordination nightmare that makes the old Jenkins dashboard look quaint.

CircleCI's evolution reflects this: pipelines can now be triggered by anything—a Docker update, an S3 bucket change, a new ML model. "A pipeline can be anything," Molenveld explains. "It doesn't need to be kicking off integration tests. It can be doing a security scan, then pushing a container, and that push triggers another pipeline."

We've recreated event-driven architecture, but for deployment infrastructure. All the same benefits. All the same debugging nightmares.

The teams that figure out how to manage this complexity—how to build reliable machines that build reliable software—will have a genuine competitive advantage. The teams that don't will keep wondering why their brilliant engineers can't seem to ship anything.

Your pipeline isn't infrastructure anymore. It's your product. Time to treat it like one.

Mike Sullivan is a technology correspondent for Buzzrag.