CI/CD for Beginners: A Simple Guide to Shipping Code Without Stress

A short story to start

It is Friday evening. A developer has just finished a new feature. To put it live, he logs in to the server, copies some files across, restarts the app and goes home. On Saturday morning the phone rings. The website is down. He forgot one small file.

This story has happened in thousands of companies. Not because people are careless, but because people are human. We get tired, we rush, we forget steps.

CI/CD is the cure for this problem. It hands the boring, repeatable work to a robot that never gets tired and never forgets a step. In this guide I will explain it in plain words, show you some simple pictures, and walk you through your very first pipeline.

1. What is CI/CD, in one sentence?

CI/CD is a robot that builds, tests and delivers your code automatically every time you make a change.

That is really all it is. The letters stand for two ideas that work together:

• CI means Continuous Integration.
• CD means Continuous Delivery (and sometimes Continuous Deployment).

Let us look at each one.

CI: Continuous Integration

"Integration" simply means joining your code with everybody else's code. "Continuous" means doing it all the time, in small pieces, instead of once in a while in one big painful merge.

Each time someone pushes code, the CI robot:

1. Grabs the newest code.
2. Builds it (puts the app together).
3. Runs the tests (checks that nothing is broken).
4. Reports back with a green tick (all good) or a red cross (something broke).

Think of a bakery. Every loaf is checked before it leaves the kitchen. If one comes out burnt, you find out straight away, not when a customer complains.

CD: Continuous Delivery and Continuous Deployment

Once the code has passed all the checks, CD takes over and gets it ready to go live.

• Continuous Delivery: the code is always packaged and ready to release. A person still presses the final "go live" button.
• Continuous Deployment: there is no button. If all the tests pass, the code goes live by itself.

Most beginners and most companies start with Continuous Delivery. You keep a human in control of the last step until you trust your tests.

Figure 1: A simple pipeline. You write and push. The robot builds, tests and delivers.

2. Why should you care?

Here is the honest difference CI/CD makes in day to day work:

Figure 2: The same team, before and after CI/CD.

• Fewer mistakes. The robot follows the same steps in the same order every time.
• Faster feedback. You find out a change is broken in minutes, while you still remember what you changed.
• Less fear. When releasing is easy and safe, teams release small changes often instead of big risky ones.
• More time for real work. Nobody spends their evening copying files to a server.

This is also why almost every DevOps, cloud or software job advert today mentions CI/CD. It is a basic skill, like knowing how to use Git.

3. The words you will hear (made simple)

Word	What it means in plain English
Pipeline	The full list of automatic steps, from your code to the live app.
Trigger	The event that starts the pipeline, for example pushing code or opening a pull request.
Job	A group of steps that run together on one machine, for example "build and test".
Step	One single action, like "install Python" or "run the tests".
Runner	The computer that does the work. Often a fresh cloud machine that is thrown away afterwards.
Artifact	The finished package the pipeline produces, like a zip file or a Docker image.
Environment	A place your app runs, for example test, staging or production (the real live site).
Secret	A password or key the pipeline needs, stored safely and hidden from logs.

4. Popular CI/CD tools

There are many tools, but they all do the same basic job. Here are the ones you will meet most often:

• GitHub Actions: built into GitHub. Free for public projects and the easiest place to start.
• GitLab CI/CD: built into GitLab, very popular in companies that use GitLab.
• Jenkins: the old, trusted, open source workhorse. You run it on your own server.
• Azure DevOps Pipelines: Microsoft's tool, common in companies that use Azure.
• CircleCI and others: hosted services that connect to your code.

My advice: start with GitHub Actions. You probably already have a GitHub account, there is nothing to install, and what you learn carries over to every other tool.

5. Build your first pipeline with GitHub Actions

Let us build a real pipeline. It will run your tests every time you push code. You only need a GitHub account.

Figure 3: A trigger starts a workflow. A workflow has jobs. A job has steps.

Step 1: Make a tiny project

Create a new repository on GitHub and add two small Python files.

A file called calculator.py:

def add(a, b):
    return a + b

And a test file called test_calculator.py:

from calculator import add

def test_add():
    assert add(2, 3) == 5

The test simply checks that 2 plus 3 really gives 5.

Step 2: Add the pipeline file

In your repository, create this folder and file: .github/workflows/ci.yml. GitHub looks in that exact folder for pipelines. Put this inside:

name: My first pipeline

on: [push]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install pytest
      - run: pytest

Step 3: Understand it line by line

• name: the name you will see on GitHub.
• on: [push]: the trigger. Run this every time someone pushes code.
• jobs / build-and-test: one job with a name we chose.
• runs-on: ubuntu-latest: GitHub gives us a fresh Linux machine for free.
• actions/checkout: step one, download our code onto that machine.
• actions/setup-python: step two, install Python.
• pip install pytest: step three, install the testing tool.
• pytest: step four, run the tests.

YAML files care about spaces. Use two spaces for each level and never use the Tab key. Most beginner errors come from wrong spacing.

Step 4: Push and watch

Commit and push the files. Open your repository on GitHub and click the Actions tab. You will see your pipeline running. After a minute or so you should see a green tick. Congratulations, you just built a CI pipeline.

Step 5: Break it on purpose

This is the fun part. Change the add function so it returns a - b instead of a + b, then push again. The pipeline will run, the test will fail and you will see a red cross. Click it and read the error. This is exactly what CI is for: it caught the mistake before anyone else saw it.

Fix the code, push again, and watch it turn green.

Step 6: Adding the CD part later

When you are ready, you add a second job called deploy that only runs if the tests pass. It might upload your app to a cloud service such as Azure App Service, AWS or a simple static website host. The idea is always the same: tests first, deploy second, and only if the tests were green.

6. Good habits from day one

1. Push small changes often. Small changes are easy to test and easy to fix.
2. Keep your pipeline fast. If it takes an hour, people stop waiting for it. Aim for minutes.
3. Never write passwords in the YAML file. Use GitHub Secrets (Settings, then Secrets and variables) and the pipeline can read them safely.
4. Protect your main branch. Set a rule that code can only be merged when the pipeline is green.
5. Write tests. A pipeline with no tests is like a smoke alarm with no battery. It looks nice but protects nothing.
6. Fix red pipelines first. A broken pipeline that everyone ignores is worse than no pipeline.

7. Common beginner mistakes

• Putting the workflow file in the wrong folder. It must be .github/workflows/.
• Mixing tabs and spaces in YAML.
• Deploying straight to the live site before you trust your tests.
• Copying a huge pipeline from the internet without understanding it. Start small and grow it one step at a time.
• Leaving secrets in the code "just for testing". Bots search public repositories for leaked keys all day long.

8. A simple learning path

Stage	What to do
Week 1	Learn basic Git: commit, push, branch and pull request.
Week 2	Build the GitHub Actions pipeline from this guide and break it on purpose.
Week 3	Add tests to a small project of your own and run them in the pipeline.
Week 4	Add a deploy job that publishes a simple website to the cloud.
After that	Learn Docker images in pipelines, environments with approvals, and try Jenkins or Azure DevOps.

Final words

CI/CD sounds like a big technical word, but the idea is simple: let a robot do the boring checks every single time, so humans can focus on building good things.

Your challenge this week: build the small pipeline from this guide, watch it turn green, then break it and watch it turn red. Once you see that red cross catch your own mistake, you will never want to work without CI/CD again.

Happy building!