Yudi Nugraha - AI Solutions Engineer

In the previous article, we covered why CI/CD matters. Now it's time to break down what actually makes up a CI/CD pipeline. Think of it like getting familiar with the kitchen tools before you start cooking — so that once we move into hands-on practice with GitHub Actions, the terminology that comes up won't be confusing anymore.

Trigger — What Makes a Pipeline Run?

A trigger is the event that makes a pipeline start running automatically. Without a trigger, a pipeline never runs on its own. Some common triggers:

Push — every time a new commit is pushed to a given branch (e.g. main or develop).

Pull Request — every time a PR is opened or updated, usually to run tests before merging.

Schedule — the pipeline runs automatically at a set time, e.g. every night at 2am (a cron job).

Manual trigger — run manually via a button, usually for production deploys that need a human decision.

In the hands-on sessions later, we'll use the push and pull_request triggers for CI, and a push to the main branch trigger for deployment.

Stage, Job, and Step — The Structure Inside a Pipeline

Once a pipeline is triggered, its contents are structured. To stay consistent, we'll use the same terminology as GitHub Actions:

Workflow — the entire pipeline, defined in a single .yml file.

Job — a collection of steps that run on one runner. Examples: the test job, the build job, the deploy job.

Step — one specific command/action inside a job. Examples: checkout code, install dependencies, run tests.

Important point: jobs can run in parallel or sequentially. By default, several jobs can run at the same time (in parallel) to speed up the pipeline. But if job B needs the result of job A — for example, the deploy job needs the test job to pass first — we can make it wait (sequential) using a dependency between jobs.

A typical CI/CD pipeline flow looks like this:

Trigger: push to main branch
  └── Job: test        (checkout → install deps → run test)
  └── Job: build        (checkout → install deps → build artifact)
        └── Job: deploy  (download artifact → deploy to server)

Runner, Artifact, and Environment

Runner (also called an agent)

A runner is the "computer" that actually executes our job. It can be a temporary virtual machine provided by the CI/CD platform (e.g. a GitHub-hosted runner: Ubuntu, Windows, macOS), or it can be your own server (a self-hosted runner). Each job usually gets a fresh, clean runner — so results are consistent and don't carry over "leftovers" from a previous run.

Artifact

An artifact is a file produced by a job that we want to keep or pass along to the next job. For example, the build job produces a compiled dist/ folder — that folder gets uploaded as an artifact, so the deploy job can download and use it without having to build from scratch again.

Environment

An environment is the "place" where our deployment actually runs — for example staging and production. Each environment usually has its own configuration and credentials. Later we'll also cover environment protection rules — a way to lock down the production environment so it can only be deployed to after approval.

A Branching Strategy That Fits CI/CD

Last topic: what branching strategy pairs well with CI/CD? There are many models, but two are most relevant for beginners:

Git Flow — has many long-lived branches: main, develop, feature/*, release/*, hotfix/*. Good for software with a scheduled release cycle that needs multiple QA stages. But for beginners, it's fairly complex and doesn't move as "fast" as the CI/CD philosophy of integrating often.

Trunk-Based Development — every developer works on short-lived branches (feature/xyz) that get merged back into a single main branch (main or trunk) quickly, ideally within hours to 1-2 days. The main branch is always in a deployable state.

For this series, and for most small-to-medium teams, we'll use an approach close to trunk-based: work on a short feature branch, open a Pull Request into main, let CI run automatically on that PR, and only merge after it passes and gets reviewed. Every merge to main can trigger a deployment.

feature/add-endpoint  ──PR──►  main  ──merge──► triggers CD
     (CI runs here)                    (deploy to production)

Summary

A pipeline is started by a trigger (push, PR, schedule, manual).

A pipeline is organized into jobs and steps, run on a runner.

A job can produce an artifact that's used by other jobs, and it deploys toward a given environment.

For branching, keep it simple: short feature branch → PR → main.

Anatomy of a CI/CD Pipeline: Trigger, Job, Runner, and Artifact

On This Page