GitHub Actions CI/CD Tutorial: Build Your First Pipeline (2026 Guide)

📌What Is GitHub Actions?

GitHub Actions is a built-in CI/CD platform that runs automated workflows directly from your repository. Every time you push code, open a pull request, or cut a release, it can build, test, and deploy your app — no separate CI server needed. It's the most popular CI/CD tool in 2026. Master it in our Git & GitHub Actions course.

📌The Core Concepts

Workflow — an automated process defined in a YAML file under .github/workflows/

Event — what triggers it (push, pull_request, schedule)

Job — a set of steps that run on the same runner; jobs run in parallel by default

Step — a single task: run a command or use an action

Action — a reusable unit (e.g. actions/checkout)

Runner — the machine that executes the job (GitHub-hosted or self-hosted)

📌Your First Workflow

Create .github/workflows/ci.yml:

name: CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'
          cache: maven
      - name: Build and test
        run: mvn -B verify

Push this file and GitHub runs it automatically. Green check = passing, red X = failing. That's continuous integration.

📌Adding Deployment (CD)

Extend the pipeline to deploy only after tests pass:

deploy:
    needs: build-and-test        # waits for tests to pass
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to server
        run: ./deploy.sh
        env:
          SSH_KEY: ${{ secrets.SSH_KEY }}

The needs keyword creates a dependency, so deploy runs only if the build job succeeds.

📌Secrets & Environment Variables

Never hardcode credentials. Store them in Settings → Secrets and variables → Actions, then read them as ${{ secrets.MY_SECRET }}. They're encrypted and masked in logs.

📌Building & Pushing a Docker Image

- name: Log in to registry
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: myapp:latest

📌A Matrix Build (Test Across Versions)

strategy:
      matrix:
        java: [ 17, 21 ]
    steps:
      - uses: actions/setup-java@v4
        with:
          java-version: ${{ matrix.java }}
          distribution: 'temurin'

This runs your tests against multiple Java versions in parallel — great for libraries.

📌Best Practices

1Cache dependencies (Maven/Gradle/npm) to speed up builds

2Pin action versions (@v4, not a moving tag) for reproducibility

3Fail fast — run linting and tests before deploy

4Use environments with required reviewers for production

5Keep secrets in Secrets, never in the YAML

6Split jobs so failures are easy to locate

📌Common Interview Questions

What triggers a workflow? Events like push, pull_request, schedule, or workflow_dispatch (manual).

Job vs step? A job runs on one runner; steps are the tasks inside it. Jobs run in parallel unless linked with needs.

How do you share data between jobs? Artifacts (upload-artifact/download-artifact) or job outputs.

CI vs CD? CI = automatically build and test every change. CD = automatically deliver/deploy that change.

📌Where This Fits

GitHub Actions is the automation layer on top of Git. If you're still shaky on Git itself, start with the Git commands cheat sheet, then automate everything here. This pairs perfectly with microservices and Spring Boot deployments.

📌Try It Now

Add a ci.yml to any repo you own, push, and watch the Actions tab. Seeing that first green check run automatically is the moment CI/CD clicks.