Skip to content
skillbld
CI/CD with GitHub Actions · 12-day planAll days
Day 1 of 12 25 min

Find out why teams automate testing and deployment, what continuous integration, delivery and deployment mean, and how GitHub Actions fits in. Then run your first workflow and learn to read what happened.

By the end of today you can

  • Explain continuous integration, continuous delivery and continuous deployment
  • Describe the problems CI/CD solves for a team
  • Name the parts of GitHub Actions - workflows, events, jobs, steps and runners
  • Read a workflow file and the log of a run
  • Explain where workflow files live in a repository

You push some code. Somewhere, a fresh computer downloads it, installs everything, runs the tests, builds the app and, if all is well, puts it live, while you get on with the next thing. That's CI/CD, and GitHub Actions is the most popular way to do it.

Mind map · click a dot to fold, drag to pan

Why automate?

Without automation, a team relies on everyone remembering to run the tests, on one person who knows how to deploy, and on "release day" being a stressful event. Problems hide until they're expensive to fix.

Sketch
A CI/CD pipeline from left to right. A developer pushes code or opens a pull request. Continuous integration then builds the code and runs linting and tests automatically. If anything fails, the developer is told within minutes. If everything passes, continuous delivery packages the app so it's ready to release, and continuous deployment releases it to production automatically. Each stage is a gate: only changes that pass move on.
TermMeans
Continuous integration (CI)Every change is built and tested automatically, many times a day
Continuous deliveryEvery change that passes is ready to release with one click
Continuous deploymentEvery change that passes is released automatically

The benefits: bugs are caught minutes after they're written, everyone's code is checked the same way, and releasing becomes routine instead of risky.

GitHub Actions in one picture

Sketch
The parts of GitHub Actions. An event, such as a push or a pull request, triggers a workflow: a YAML file in .github/workflows. The workflow contains jobs; each job runs on its own runner, a fresh virtual machine. A job is a list of steps that run in order: each step either runs shell commands with run: or uses a ready-made action with uses:, such as actions/checkout.
PartIs
WorkflowA YAML file in .github/workflows/: the whole automation
EventWhat starts it: a push, a pull request, a schedule… (on:)
JobA group of steps that runs on one machine
RunnerThe machine: a fresh Linux, Windows or macOS virtual machine
StepOne command (run:) or one ready-made action (uses:)

Your first workflow

Below is a real workflow file. Press Run to see what GitHub would do when you push it to main:

.github/workflows/hello.yml · editable

Choose an event and press Run to see what GitHub would do. Nothing really runs: it's a simulation of a repository called ana/shop.

Tap the greet job, then each step, to open its log. Notice:

  • GitHub adds Set up job (preparing the runner) and Complete job steps around yours.
  • Each run: step shows the commands, then their output.
  • ${{ github.ref_name }} was replaced by main: an expression, filled in before the step runs.

This editor simulates a repository called ana/shop: nothing really runs, but the behaviour follows GitHub's rules. Try changing the message, or pick Push to feature/login from the Event menu and run again.

When things fail

Change echo in the first step to ecko and press Run. The step fails, its log shows command not found, and the job stops: later steps are skipped. A red ✗ appears next to the commit on GitHub, and you'd get an email.

That's the heart of CI: a failing command fails the step, the job and the run, so nothing broken slips through unnoticed.

Where workflows live

my-repo/
├── .github/
│   └── workflows/
│       ├── ci.yml        ← tests on every push and pull request
│       └── deploy.yml    ← deploys when main changes
├── src/
└── package.json

Commit a file to .github/workflows/ and GitHub runs it on the next matching event. Results appear in the repository's Actions tab and next to each commit and pull request. Public repositories get hosted runners free; private ones get a generous monthly allowance of free minutes.

Recap

  • CI builds and tests every change; continuous delivery keeps it releasable; continuous deployment releases it automatically.
  • A workflow (YAML in .github/workflows/) runs on an event; it has jobs, which run steps on a fresh runner.
  • Steps either run: commands or uses: an action.
  • A failing command fails the step, the job and the run.

Tomorrow: the anatomy of a workflow file, line by line.

Knowledge check

Test what you learned

5 questions · pick an answer to see if you're right

0/5
  1. 1

    What is continuous integration (CI)?

  2. 2

    What's the difference between continuous delivery and continuous deployment?

  3. 3

    Where must GitHub Actions workflow files be saved?

  4. 4

    What is a runner?

  5. 5

    What starts a workflow run?

Finished day 1?

Mark complete and continue to Day 2: Workflow Anatomy

Was this lesson helpful?

Need a breather? Take a two-minute break

Day 2 Workflow Anatomy

Keep going