menu
Do you separate CI and CD?

Do you separate CI and CD?

posted 1 min read

In a lot of setups I’ve seen, CI is responsible for everything—build, test, deploy, and even rollback.

I'm convinced that this approach is not that efficient. Even the most basic things become harder than they should be. It’s no longer immediately clear what’s actually running in production, who approved the release, or what the last stable version was. And when something goes wrong, rolling back quickly without rebuilding turns into a stressful, manual process.

The information is scattered across pipeline logs, commits, and chats.

So I'm curious how you handle this. Do you separate CI and CD? If yes, what tools do you use? Or do you keep everything inside pipelines?

Let's discuss!

20 Comments

•

I recently updated the deployment flow for my app and it ended up being a useful reminder that CI and CD should solve different problems.

I used to rely on GitHub Actions and GitHub Pages for development deploys, but for my current setup I moved production deployment to a webhook-based flow. I also replaced the older FTP-style approach, which was slower and less convenient, with a webhook trigger that makes releases much faster and simpler.

What I like most about this change is the clearer separation of concerns: CI is about validating code quality and catching issues early, while CD is about shipping changes efficiently and reliably. The deployment side now feels much leaner, and the overall release process is smoother.

Small infrastructure change, but a meaningful improvement in day-to-day developer experience.

1 vote
•

@[Ionuț RUSU] That’s a great example of what I mean! It’s interesting how even a relatively small change like that can make the whole process feel clearer

I went a bit further in that direction and started experimenting with a separate release layer on top of CI for the same reason. It made a noticeable difference, especially around rollback and understanding what’s actually running.

1
•

@[TechFace] Believe me the webhook approach was the best choice i ever had, i used to rely on github actions for production deployment which was taking forever, going file by file. Loosing connection, not connecting, at the very begging to a simple approach where a webhook creates a tz file deploys it and unzip it. All in matter of 1, 2 seconds, the user never knows that i have updated recipe-finder.org, without him knowing. Mycurrent setup is CI: integration testing, testing: unit and e2e, server and front, git integration, then CD on both server and front. All in matters of seconds. I am never going back to ftp or other ones...from my experience, time is precious and i don't want to waste it on CD.

1
•

@[Ionuț RUSU] That sounds like a solid setup Super fast too! If you ever need a bit more control around releases/rollback, https://orbnetes.cloud/ could fit nicely on top of it. I'd really love to hear your feedback on it btw

1
•

We separate CI and CD, but more importantly, we introduce a semantic validation layer between them. In PADI, nothing is deployable unless it passes ontology constraints, RDF projection, and SPARQL validation, so deployment becomes state promotion, not guesswork.

2 votes
•

@[peculiarlibrarian] The main problem I was trying to solve was having better control over deployments and releases.

So that different people can be responsible for different parts of the process — for example, some can trigger deployments, others approve them and monitor the rollout, and others handle rollback if something goes wrong.

0
•

All in one place, Jenkins, a solid setup.

1 vote
•

@[Mark Kazakov] Nice, Jenkins can definitely cover everything
How does it hold up when you need more control over approvals or rollback?

0
•

Good point. Separating CI and CD usually brings about more clarity. CI focuses on building and validating artifacts, while CD handles controlled releases and approvals. Keeping them distinct makes it easier to track what’s deployed, roll back quickly, and avoid mixing concerns. Pipelines are powerful, but without separation, they can become hard to reason about.

1 vote
•

@[Gift Balogun] Exactly. Once CI just builds the artifact and CD handles promotion, it’s much easier to see what’s running and roll back without guessing. Pipelines are great for running steps, but not for tracking release state.

0
•

Tight coupling of CI and CD is common, but it often creates the issues you mentioned: unclear production state, harder rollbacks, and fragmented context.

Separating them usually improves traceability: CI focuses on building and testing, CD on controlled promotion of versioned artifacts. Many teams also use a hybrid approach to automated CI and staged CD (staging/canary/prod) via tools like Argo CD or similar.

2 votes
•

@[Gimi] That’s exactly how I see it. CI/CD separation is where things start to fall into place.

Yeah, I’ve seen similar setups with Argo CD. It works really well for that, especially in Kubernetes environments. But I ended up experimenting with a lighter approach for the same idea (Orbnetes), mainly to keep the release side explicit without adding too much complexity.

1
•

There are so many reasons to keep them loosely coupled! CI produces and validates your artifact, that's where it should end and it a perfect seam for keeping things loosely coupled. Once CI has lodged the package in a safe place, it's done. Your CD process should take that package and progress it through the pipeline like a bubble of immutability that includes the artifact and the deployment process, so nothing changes as it makes it's way to production.

I guess lots of teams have never seen it done well, so they don't recognize the mess they're in.

With continual headlines about supply chain issues causing security in the CI process, you don't want your CI tool to have access to your production infrastructure.

3 votes
•

@[Steve Fenton] Really like how you described this, Steve! And also I loved your article about CI/CD a bunch! I wrote a piece around the same topic recently too, looking at how release processes become fragile when CI starts doing everything.

I’ve been exploring this direction in practice and ended up building a release layer on top of CI called Orbnetes, just to keep that separation clearer.

If you ever have a moment to check it out, I’d really appreciate your honest feedback

1
•

Since the dawn of time, it's been referred to as "CI/CD", and people - including myself in the past, especially when learning all this "DevOps stuff" - have assumed that means it is one thing.

But the slash in CI/CD is a good reminder that these are separate parts of the software delivery lifecycle, and CI aims to solve different problems than CD, and vice-versa. Treat the slash as a diving line, not a bridge.

For smaller organizations with simple deployment needs, extending a CI tool to also handle deployments can make a lot of sense. But as soon as you scale past a couple of apps, simple deployments like "deploy this package to a web app", and need control and visibility with your delivery process, you'll find yourself outgrowing the capabilities of what most CI tools offer for CD. Unfortunately, that usually comes after trying to bolt a heap of solutions together with custom bash scripts, API calls, duct tape, and twine.

2 votes
•

@[Matt Allford] “slash as a dividing "line"—that's a great way to put it!

Also very relatable how teams only feel this once things grow and the pipeline turns into a mix of scripts and workarounds.

1
•

Oh man, this hits home.

I run a bash scripting resource site (BashSnippets.xyz) and I've debugged enough busted/fragmented pipelines for one lifetime

You're absolutely right that the "CI does everything" approach creates chaos. I've seen teams where a failed deployment means digging through 800 lines of GitLab YAML trying to figure out which step exploded at 2am.

Here's what worked for me after one too many rollback nightmares:

Separate the concerns. CI validates and builds. CD deploys with a clear manual gate before production. That gate is where humans make the call. Not automated triggers that don't understand "oh sh*t it's Black Friday maybe don't push right now."

I use GitHub Actions for CI (lint, test, build artifacts) and then a separate bash-based deployment script that handles the actual release. Sounds old school, but it means:

Rollbacks are literally ./deploy.sh rollback. Tired of dealing with pipeline structure at the basic level

I can see what's running in prod by checking a simple state file

The deployment script has proper error handling (I wrote an entire article on bash pipeline failures because set -euo pipefail saved my ass more times than I can count)

The "everything in one pipeline" model optimizes for convenience during the happy path, but absolutely falls apart when you need to troubleshoot under pressure. The moment you're grepping Jenkins logs at 1am trying to find which env var was set wrong, you realize separation of concerns isn't just academic—it's survival.

What's your rollback process look like right now? That's usually where this setup shows its cracks first.

3 votes
•

@[BashSnippets] That’s painfully relatable especially the 2am YAML debugging.

I like the script approach. having rollback as an actual command already makes a huge difference. I hit a similar stage and later ran into challenges around tracking what’s deployed and coordinating releases across environments.

Curious how you handle that part today?

1
•

@[TechFace] Honestly the “what’s actually deployed where?” problem is what pushed me away from trying to make CI/CD feel “perfect" and toward making it painfully obvious instead.

Right now my setup is intentionally boring.

Every deployment creates a tiny release manifest on the server itself:

git commit hash
deployment timestamps
branch/tag
who triggered it
previous release references

For now, it's just a flat file + symlink structure I can inspect in 5 seconds over SSH without opening a dashboard or clicking through three different SaaS products.

I learned the hard way that during incidents.. People seem to want:
“what changed?”
“when did it change?”
“how do we undo it?”

So my deploys basically work like this:

CI builds and validates artifacts
artifacts get versioned
deployment script pulls a specific artifact/version
current release becomes a symlink
previous release stays intact

That last part saved me multiple times. One bad nginx config and rollback becomes changing a symlink back + restarting a service instead of rebuilding/redeploying/re-praying.

For coordinating environments, I stopped trying to fully automate promotion chains because they became harder to reason about than the app itself. Staging and production are explicit actions now. Humans choose when prod changes. Especially after I had a deployment start while I was actively debugging another issue once. That was a special kind of misery.

I know some people hear “bash deployment scripts” and think duct tape, but honestly I trust 200 lines of readable bash more than 2,000 lines of abstracted YAML magic hidden behind marketplace actions I didn’t write.

The funny part is the older I get, the more I optimize for:
“Can sleep-deprived me understand this at 2am?”

If the answer is yes, it’s probably a good deployment system.

Cheers! <3

1
•

@[BashSnippets] love your approach! I ended up going a similar direction, just moved that release state into a small layer on top of CI https://orbnetes.cloud/ to keep the same simplicity but make it easier to track and roll back without SSH.

1

More Posts

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

What Is an Availability Zone Explained Simply

Ijay - Feb 12

Why most people quit AWS

Ijay - Feb 3

Why CI/CD Changed Software Development Forever

md.mijanur.molla - Apr 24
chevron_left

More From TechFace

What have you been working on lately?

7 Signs Your Release Process Is More Fragile Than You Think

How do you get developers to actually try your pet project?

Related Jobs

View all jobs →

Commenters (This Week)

11 comments
6 comments
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!