CI/CD Pipelines: How Your Code Goes from a Laptop to the Real World

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 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 couldn't explain, and configuration files where a single misplaced space broke everything. I'm not exaggerating when I say that one missing environment variable cost me an entire afternoon.

The reality of 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's a lot happening behind those few lines of YAML.

But here’s 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.

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’s 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've written the entire document.

CD — Continuous Delivery or Continuous Deployment

This is the second half. Once the code passes all the tests, it's 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's what actually happens when a developer pushes code. Let's 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's the tool I use most and the one that impressed me most 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's 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's 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's 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 elegant once it's 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're Not a Developer

You might be reading this thinking — I'm not a developer, why does any of this matter to me?

Here's 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're why Netflix can update its recommendation algorithm without you ever noticing any disruption. They're the invisible infrastructure that keeps the digital world running smoothly.

Understanding CI/CD doesn't 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're in product, operations, finance, or leadership.

The Things Nobody Tells You About Pipelines

Here are a few things about CI/CD that tutorials often leave out:

Pipelines break. A lot. Especially when you're 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's not glamorous but it'll save you hours.

Quick Recap

• 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 aren't just for developers — they're the infrastructure behind every digital product you use every day

What’s Next?

We've now covered DevOps, Linux, Git, Docker, and CI/CD pipelines. You've got the full foundation.

Next up is Kubernetes — the platform that manages all those containers we built in Article 4 at massive scale. We'll cover what it actually is, why the industry adopted it so quickly, and how EKS, AKS, GKE and OpenShift fit into the picture.