DevOps line
CI/CD
Every change goes down an automatic assembly line that checks it, boxes it and ships it, so mistakes are caught before customers see them.
Stops explain each step. The film plays the whole ride.
- Request
- Waiting for a yes
- Reply or result
- Something went wrong
You place an order
You finish a change and hand it in at the order desk, like placing an order. The desk writes it down and wakes up the assembly line.
Next stop: The line gets a fresh workstation
All stops
The everyday version
A factory assembly line works the same way. Every stop has a twin on the factory floor.
- Youis the Developer
Place the order by handing in a finished change.
- The order deskis the GitHub repo
Writes down each order and starts the assembly line.
- The fresh workstationis the Runner
A clean bench lent for one order, where the work is built and inspected.
- The warehouseis the Registry
Keeps every numbered box, new and old, on its own shelf.
- The shipping manageris the Environment gate
Reads the checklist and signs before anything leaves the building.
- The storeis the Production
Where customers meet the finished goods.
- The front dooris the Router
Sends customers to one production server, then can switch.
- The live roomis the Blue
The production server customers are using right now.
- The spare roomis the Green
The other production server, where the new box lands first.
- A broken boxis a failed test or a bad deploy
If an inspector finds a mistake, the line stops and nothing ships. If a bad box slips through, the store goes back to the old one.
Interview questions
Say the short answer first. Go deeper only if they ask.
What is the difference between CI, continuous delivery and continuous deployment?
CI merges and tests every change often. Delivery keeps each build ready to release, and deployment releases it automatically.
In continuous delivery the final decision to go live is a person’s, such as a required reviewer on an environment. In continuous deployment it happens automatically, with no approval step. Both still need tests you trust.
“CI/CD is just a deploy script.”
What is the difference between a workflow, a job, a step and a runner?
A workflow runs jobs, a job is a list of steps, and each job runs on a runner.
Jobs run in parallel unless needs orders them, and each gets its own fresh runner, so they share no filesystem. Pass files between jobs with artifacts. Steps run in order on one runner and share its filesystem. Self-hosted runners are not guaranteed clean.
“Steps run in parallel”, or “jobs share a filesystem”.
How do you handle secrets in a pipeline?
Store them as encrypted GitHub secrets, never in the repo, and read them with ${{ secrets.NAME }}.
Secrets are redacted in logs and, except GITHUB_TOKEN, not passed to workflows triggered from forks. Environment secrets reach only jobs that pass the environment’s rules. Prefer OIDC, which swaps a short-lived token for cloud access, over a long-lived key.
“Put the key in the workflow file, or commit a .env.”
How do you speed up a slow pipeline?
Cache dependencies, run independent jobs in parallel and run only what changed.
actions/cache keys on a lock-file hash, and unused caches are evicted after 7 days, with a default 10 GB cap per repository. Docker builds can reuse layers with cache-from: type=gha. Use paths filters to skip irrelevant runs and a matrix to spread work.
“Buy bigger runners first.”
How do you deploy safely?
Deploy immutable images tagged with the commit SHA, gate production, and keep rollback easy.
Tag with github.sha, not latest, so a rollback is just deploying an older tag. On pull_request that value is the merge commit, not the branch head. Use an environment with reviewers and a concurrency group so two deploys never overlap, and keep database migrations backward-compatible. Blue-green keeps two production servers and switches the router after the idle one is healthy.
“Deploy latest straight to production.”
What can start a workflow?
Events listed under on:, such as push, pull_request, a schedule or a manual workflow_dispatch.
schedule uses POSIX cron, runs only on the default branch and at most every 5 minutes. workflow_dispatch works only if the workflow file is on the default branch, and gh workflow run fires it. Branch and paths filters narrow push and pull_request.
“Workflows only run when you push.”
Why pin a third-party action to a commit SHA?
A tag like @v7 can be moved. A full commit SHA cannot, so it is the safe pin.
GitHub says pinning to a full-length commit SHA is currently the only way to use an action as an immutable release. Also set the default GITHUB_TOKEN permission to read-only for contents, and raise it per job only where needed.
“Use @main so we always get the newest.”
Cheat-sheet
Commands you will actually type.
on: { push: { branches: [main] }, pull_request: {} }Trigger on pushes to main and on pull requests.
uses: actions/checkout@v7Download your repository onto the runner. v7 is the current major version.
needs: [test]Wait for the test job. If it fails, this job is skipped.
strategy: { matrix: { os: [ubuntu-latest, windows-latest] } }Run the job once for each value or combination.
uses: actions/cache@v6Restore and save files such as dependencies, keyed on a lock-file hash. v6 is current.
environment: productionUse this environment: its secrets and required reviewers apply before the job runs. Read a secret with `${{ secrets.TOKEN }}`.
gh run view --log-failedPrint the logs of only the failed steps in a run.
gh run watch --exit-statusFollow a run until it ends, exiting non-zero if it fails. `gh run list` shows recent runs.
Sources
- GitHub Docs: understand GitHub Actions
- GitHub Docs: workflow syntax (needs, matrix, environment, steps)
- GitHub Docs: events that trigger workflows
- GitHub Docs: choose the runner for a job
- GitHub Docs: GitHub-hosted runners
- GitHub Docs: self-hosted runners
- GitHub Docs: exit codes for actions
- GitHub Docs: manage environments (required reviewers)
- GitHub Docs: review deployments
- GitHub Docs: control deployments with environments
- GitHub Docs: using secrets in GitHub Actions
- GitHub Docs: OpenID Connect
- GitHub Docs: OIDC in cloud providers (id-token: write)
- GitHub Docs: secure use of Actions (pin to a SHA)
- GitHub Docs: contexts (github.sha)
- GitHub Docs: dependency caching reference
- GitHub Docs: workflow artifacts
- GitHub Docs: matrix strategy
- GitHub Docs: concurrency
- GitHub Docs: re-run workflows and jobs
- GitHub Docs: protected branches (required checks)
- GitHub Docs: publishing Docker images to ghcr.io
- GitHub Docs: continuous integration
- GitHub Docs: continuous deployment
- AWS: continuous delivery vs continuous deployment
- Docker Docs: GitHub Actions cache backend
- actions/checkout (v7)
- actions/cache (v6)
- actions/upload-artifact (v7)
- GitHub CLI: gh run view
- GitHub CLI: gh run watch
- GitHub CLI: gh run list
- GitHub CLI: gh workflow run