Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
The First Time I Saw a Pipeline Run
I still remember the first time I watched a CI/CD pipeline run from start to finish.
A developer pushed their code to GitHub. Within seconds, a series of automated steps fired off on their own — tests ran, the application was packaged into a container, and it was deployed to a live environment. Nobody pressed a button. Nobody sent an email saying “please deploy this.” It just happened.
My first reaction was: this looks incredibly simple. A few lines in a YAML file, push some code, and everything just happens on its own. I genuinely thought — how hard can this be?
Then I tried to set one up myself in OpenShift.
What followed was hours of staring at cryptic error messages, pipelines that failed for reasons that made no sense, permissions that were wrong in ways I could not explain, and configuration files where a single misplaced space broke everything. I am not exaggerating when I say that one missing environment variable cost me an entire afternoon.
The humbling truth about CI/CD pipelines is that they look effortless when someone else has already built them. The first time you build one yourself — especially in an enterprise environment like OpenShift — you quickly discover there is a lot happening behind those few lines of YAML.
But here is what I want you to take away from that experience: the concept really is simple. The frustration comes from the setup details, not from the idea itself. And once you understand what a pipeline actually does and why, those error messages start to make a lot more sense. So let us start from the very beginning — no IT background required.
Let’s Start With a Real World Analogy
Imagine you work at a bakery. Every morning you follow the same process:
- Mix the ingredients
- Bake the bread
- Check the bread is cooked properly
- Package it up
- Deliver it to the shop
You do those same five steps every single day, in the same order, without skipping any of them. Because if you skip step 3 and the bread is not cooked, customers get raw dough. If you skip step 4, the bread gets damaged in transit.
Now imagine you could automate that entire process. Every morning, the moment the ingredients arrive, a machine mixes them, bakes them, checks them, packages them, and delivers them — automatically, consistently, without anyone having to remember the steps.
That is exactly what a CI/CD pipeline does for software.
Every time a developer saves their code, the pipeline automatically runs through a set of steps — testing the code, building the application, and delivering it to users. Same steps, every time, no human error.
What Does CI/CD Actually Stand For?
CI — Continuous Integration
This is the first half of the pipeline. Every time a developer adds new code, it is automatically merged with everyone else’s code and tested immediately. The goal is to catch problems early — before they grow into big expensive disasters.
Think of it like a spell checker that runs the moment you finish typing a sentence, rather than waiting until you have written the entire document.
CD — Continuous Delivery or Continuous Deployment
This is the second half. Once the code passes all the tests, it is automatically prepared and delivered to production — the live environment that real users interact with.
Continuous Delivery means the code is ready to deploy at the push of a button. Continuous Deployment goes one step further — it deploys automatically with no human involvement at all.
Together, CI/CD turns what used to be a stressful, manual, error-prone process into something that happens quietly and reliably in the background dozens of times a day.
A Day in the Life of a Pipeline
Here is what actually happens when a developer pushes code. Let us walk through it step by step in plain English:
Step 1 — Code is pushed to GitHub
A developer finishes their work and pushes it to a branch on GitHub. This single action wakes the pipeline up.
Step 2 — Tests run automatically
The pipeline runs a series of automated checks. Does the code work? Does it break anything that was already working? Does it meet the team’s quality standards? If anything fails, the pipeline stops and alerts the developer immediately.
Step 3 — The application is built and packaged
If all tests pass, the pipeline packages the application — often into a Docker container as we covered in Article 4 — ready to be deployed.
Step 4 — Deployment to a test environment
The packaged application is deployed to a staging environment first — a copy of production where the team can do a final check before it goes live.
Step 5 — Deployment to production
Once everything looks good, the pipeline deploys to the live environment that real users are using. Done. No late night deployment calls, no manual steps, no crossed fingers.
The whole process can take minutes. And it happens the same way every single time.
The Tools That Make It Happen
GitHub Actions
GitHub Actions is built directly into GitHub — the platform where most developers store their code. It is the tool I use most and the one that genuinely impressed me when I first saw it in action.
You define your pipeline in a simple file called a workflow, and GitHub takes care of the rest. Here is a real example that shows exactly what a basic pipeline looks like:
# .github/workflows/pipeline.yml
name: Build, Test and Deploy
on:
push:
branches:
- main
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- name: Get the code
uses: actions/checkout@v3
- name: Run tests
run: npm test
- name: Build container image
run: docker build -t my-app:latest .
- name: Deploy to production
run: ./deploy.sh
In plain English this says: every time someone pushes to the main branch, get the latest code, run the tests, build the container, and deploy it. That is your entire pipeline in about fifteen lines.
The first time I set one of these up and watched it run on its own, it felt like automation magic. The frustrating hours came later — when something broke and I had to figure out why. But that is a story for another day.
ArgoCD
If GitHub Actions is the engine that builds and tests your code, ArgoCD is the specialist that handles the deployment side — particularly in Kubernetes environments like OpenShift, EKS, or AKS.
ArgoCD watches your GitHub repository and automatically keeps your live environment in sync with whatever is in your code. If you change a configuration file in GitHub, ArgoCD notices and updates your running application to match.
This approach is called GitOps — using Git as the single source of truth for both your application and your infrastructure. We mentioned this briefly in Article 3. ArgoCD is one of the most popular tools that puts GitOps into practice.
In my experience, ArgoCD is genuinely elegant once it is set up correctly. Getting it set up correctly — especially in OpenShift — is where the hours disappear. But when it works, watching it automatically sync your deployments is deeply satisfying.
Why This Matters Even If You Are Not a Developer
You might be reading this thinking — I am not a developer, why does any of this matter to me?
Here is why.
Every digital product you use — your banking app, your food delivery service, your streaming platform — is updated constantly. New features, bug fixes, security patches. Without CI/CD pipelines, every one of those updates would require a team of people to manually test, package, and deploy the changes. It would be slow, expensive, and full of human error.
CI/CD pipelines are why your banking app can add a new feature on a Tuesday without taking the whole system down. They are why Netflix can update its recommendation algorithm without you ever noticing any disruption. They are the invisible infrastructure that keeps the digital world running smoothly.
Understanding CI/CD does not require you to be able to build one from scratch. But knowing what it is and why it exists makes you a far more informed collaborator in any technology team — whether you are in product, operations, finance, or leadership.
The Things Nobody Tells You About Pipelines
Since we are keeping it real on this blog, here are a few honest truths about CI/CD that tutorials often leave out:
Pipelines break. A lot. Especially when you are first setting them up. A missing environment variable, a wrong file path, a version mismatch — any of these can bring a pipeline down and leave you staring at error logs. This is normal. Every engineer has been there.
Start simple. The most common mistake beginners make is trying to build the perfect pipeline on day one. Start with just two steps — run the tests and deploy. Add complexity gradually once the basics are working reliably.
Read the logs. When a pipeline fails, the answer is almost always in the logs. Learning to read pipeline error output quickly is one of the most valuable skills you can develop. It is not glamorous but it will save you hours.
Quick Recap
Here is everything we covered today:
- CI/CD stands for Continuous Integration and Continuous Deployment — it automates the process of testing and delivering software
- Every time a developer pushes code, the pipeline automatically tests it, packages it, and deploys it — no manual steps required
- GitHub Actions is the most beginner friendly pipeline tool and lives directly inside GitHub
- ArgoCD handles the deployment side in Kubernetes environments and powers GitOps workflows
- CI/CD pipelines are not just for developers — they are the infrastructure behind every digital product you use every day
What’s Next?
We have now covered DevOps, Linux, Git, Docker, and CI/CD pipelines. You have the full foundation.
In Article 6 we are going to talk about Kubernetes — the platform that manages all those containers we built in Article 4 at massive scale. We will cover what it actually is, why the industry adopted it so quickly, and how EKS, AKS, GKE and OpenShift fit into the picture.
See you in Article 6.
Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
Found this useful? Share it with someone — in tech or not — who has ever wondered how apps get updated without anyone noticing. Follow along for a new article every week.
Top comments (0)