Before You Start: The Words This Series Keeps Using
The handful of terms this CI/CD with GitHub Actions series uses constantly: pipeline, workflow, job, runner, artifact, secret, trigger. Explained once in plain language.
This series teaches CI/CD by building a real pipeline with GitHub Actions, one stage at a time. It assumes you can already use Git and GitHub: cloning a repo, committing, opening a pull request. It does not assume you already know any CI/CD vocabulary.
This page exists to close that gap. Read it once before starting, or come back any time a word shows up later and doesn't immediately click. Simplifying the sentences around a word is not the same as skipping the word, this series keeps the real terms on purpose, because they're exactly what you'd use at a real job.
The Words This Series Uses Constantly
CI (Continuous Integration)
Automatically checking that a change is good the moment it's proposed: does it build, does it lint, do the tests pass. CI answers one question: is this change safe to merge?
CD (Continuous Deployment / Delivery)
Automatically getting an already-good change out into the world once it's merged. CD answers a different question than CI: is this change now live? Why these are kept as two separate jobs.
Pipeline
The generic name for the whole automated process, from a code push to a live deploy. "Pipeline" is the concept; on GitHub specifically, that concept is built out of one or more workflows.
Workflow
GitHub's specific word for one automation file: a YAML file sitting in .github/workflows/ that defines what runs, when it runs, and where.
Job
One unit of work inside a workflow, made of a sequence of steps. Each job gets its own fresh virtual machine, so nothing carries over between jobs unless you explicitly hand it off. build and deploy are usually two separate jobs, not one.
Step
One instruction inside a job: check out the code, install dependencies, run a command. Steps run in order, one after another, on the same runner.
Runner
The actual machine a job executes on. runs-on: ubuntu-latest picks the runner. Full explanation of "on" vs "runs-on".
Trigger
What makes a workflow start running: a push, a pull request, or a manual click (workflow_dispatch). Set with the on key at the top of a workflow file.
Artifact
A file (or folder) one job produces and hands off for another job to use, since jobs don't share a filesystem. A build job uploads the compiled output as an artifact; a deploy job downloads that same artifact instead of rebuilding it. Full explanation.
Secret
An encrypted value (an API key, an access token) stored on the repo or organization, referenced in a workflow but never shown in plain text. Never confuse this with a repo vars, which does render in plain text. Why a secret can still go badly wrong.
Branch Protection
A GitHub setting on a branch (usually main) that blocks direct pushes and requires checks or a review before a merge is allowed. This is also what stops a deploy job from ever being triggered by a single developer acting alone.
YAML
The plain-text data format every GitHub Actions workflow is written in. It's just structured data (keys, values, lists) until GitHub Actions layers logic on top with ${{ }} expressions.
Semver / Caret (^)
Semantic versioning: a version number's three parts (major.minor.patch) signal how big a change is. A caret in package.json, like ^5.0.0, allows npm to install any newer minor or patch release automatically. Why pinning the exact version instead is often safer.
Keep this page open in another tab for the first few posts. Once these words stop needing a second look, you won't need it anymore.
Keep reading