CI/CD with GitHub Actions

Lesson 01 · 12 min

CI, CD and workflow anatomy

How delivery differs from deployment and what a GitHub Actions YAML file is made of.

12 minLesson 1 of 5Practice includedAsk AI on any point

What this course covers

  • Lesson 1. CI, continuous delivery and continuous deployment, workflow anatomy.
  • Lesson 2. A pipeline for Node and TypeScript: caching, lint, types, tests, build, a version matrix.
  • Lesson 3. Secrets, variables, environments with reviewers, GITHUB_TOKEN permissions, OIDC instead of long lived keys.
  • Lesson 4. Artifacts, a Docker image in a registry, deploy jobs and concurrency.
  • Lesson 5. Safe releases: branch protection, deploy strategies, rollback, reusable workflows, pinning by SHA.
  • Planned: self-hosted runners, monorepo pipelines, security of third-party actions in practice.

In the DevOps course we already ran a minimal CI: checkout, install, lint, tests. Here we go deeper: how a workflow is built, how to make it fast and safe, and how to get code to production so that a rollback takes a minute.

AI

You can ask about this point«What this course covers»

Three terms people mix up

  • Continuous integration (CI): every change is merged into a shared branch often, and each one is checked automatically: build, lint, tests. The goal: broken code never reaches main.
  • Continuous delivery (CD): every green commit on main is ready to release. The artifact is built, verified and can go to production with one human decision, such as a button or an approval.
  • Continuous deployment: the same pipeline, but without a human. A green main goes to production on its own. This needs very good test coverage, monitoring and automatic rollback.
AI

You can ask about this rule«The acronym CD is ambiguous»

AI

You can ask about this point«Three terms people mix up»

What a workflow is made of

A workflow is a YAML file in .github/workflows/. It has a trigger (on), one or more jobs, and each job has steps. By default jobs run in parallel on separate virtual machines (runners). Steps inside a job run one after another on the same machine and share the file system.

.github/workflows/ci.yml
  • on: the events that start the workflow. The most common: push, pull_request, workflow_dispatch (manual), schedule (cron), release, workflow_call (called from another workflow).
  • runs-on: where the job runs. ubuntu-latest, windows-latest, macos-latest or labels of your own runners.
  • needs: a dependency between jobs. Without it jobs start at the same time.
  • if: a condition on a job or a step, for example if: github.ref == 'refs/heads/main'.
AI

You can ask about this point«What a workflow is made of»

uses versus run

A step comes in two kinds. run executes a shell command on the runner. uses pulls in a ready-made action: code from another repository (actions/checkout@v4), from this repository (./.github/actions/setup) or a Docker image. Action parameters go in with, environment variables in env.

Both kinds in one job
AI

You can ask about this rule«Every job starts on a clean machine»

In the knowledge base
AI

You can ask about this point«uses versus run»

Check

Lock it in before you move on

  1. 1. How does continuous delivery differ from continuous deployment?

  2. 2. How do two jobs without needs run by default?

  3. 3. What does a step with the uses key do?

  4. 4. A step built dist/. Where is this folder available without extra work?

PracticeSolve the lesson tasksA few short tasks in the editor. Check your code right away and see where it goes wrong.Start practice