Free preview · Beginner · 20 min read
CI/CD Mental Model & GitHub Actions Architecture
Understand continuous integration, continuous delivery/deployment, GitHub Actions components, run lifecycle, trust boundaries and the production delivery mindset.
Free preview · Beginner · 20 min read
Understand continuous integration, continuous delivery/deployment, GitHub Actions components, run lifecycle, trust boundaries and the production delivery mindset.
A production CI/CD system is not “a YAML file that runs commands.” It is a controlled software delivery system that takes a change from source control through validation, packaging, security checks and deployment while preserving evidence of what happened.
| Practice | Main goal |
|---|---|
| Continuous Integration | Integrate changes frequently and prove they still build/test together |
| Continuous Delivery | Keep the system releasable and automate delivery up to a controlled production decision |
| Continuous Deployment | Automatically release every change that satisfies the delivery policy |
A useful mental model is:
Developer change
↓
Git push / Pull Request
↓
Workflow event
↓
Jobs scheduled to runners
↓
Build + test + scan
↓
Artifact/image
↓
Environment policy / approval
↓
Deploy
↓
Verify + observe
.github/workflows/.push, pull_request, workflow_dispatch, schedule, or workflow_call.run) or an action (uses).staging or production, optionally protected by approval and branch rules.GitHub orchestrates the workflow, but your runner executes the commands. That means the runner can see files, environment variables, credentials and network resources exposed to the job. Runner selection is therefore a security decision, not only a performance decision.
Jobs can run independently or form a dependency graph:
jobs:
test:
runs-on: ubuntu-latest
steps:
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
needs: test says deployment should not be scheduled until test succeeds.
A strong pipeline should answer: