GitHub Actions
The CI/CD tool built into GitHub — workflows, jobs, and the YAML that wires them together.
1.5 hrOverview
GitHub Actions runs workflows defined in YAML files under .github/workflows/ — triggered by events like a push or pull request, running jobs made of steps on GitHub-hosted (or your own) runners.
Why it matters
It's already wired into the repo you're using for version control, with no separate CI server to provision or maintain. For a portfolio or a small team, that's the entire CI/CD setup cost, versus standing up Jenkins.
How backend developers use it
A workflow triggered on push to main: checkout code, set up the JDK, run mvn test, and only on success build and push a Docker image tagged with the commit SHA — the tag makes every deployed image traceable back to an exact commit.
Common mistakes
Warning
Not caching dependency-manager downloads (Maven's ~/.m2 or npm's global cache), so every run re-downloads the dependency tree. Do not cache node_modules across incompatible installs.
Warning
One giant workflow file instead of separate workflows for PR checks vs. deploy — a typo in the deploy logic then blocks every PR's test run too.
Warning
Using repository secrets for a value that changes per environment (staging vs. production) instead of GitHub Environments, which scope secrets and require approval gates per environment.
Warning
No branch protection rule requiring the workflow to pass before merge — the pipeline exists but nothing enforces it.
Warning
Using mutable action tags without a review process — production workflows should pin third-party actions to full commit SHAs and keep a version comment for maintainability.
Example commands
Minimal workflow: test on every push
name: CI
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
- uses: actions/setup-java@c1e323688fd81a25caa38c78aa6df2d33d3e20d9 # v4.8.0
with:
java-version: '21'
distribution: 'temurin'
- run: mvn testResources
Retrieval check
Before you continue
- Explain what this tool or practice changes in the delivery lifecycle.
- Name one common failure it helps you diagnose or prevent.
- Repeat one example command from memory, then verify it.