bongoDev

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.

CI, continuous delivery and continuous deployment

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:

Text

Developer change
    ↓
Git push / Pull Request
    ↓
Workflow event
    ↓
Jobs scheduled to runners
    ↓
Build + test + scan
    ↓
Artifact/image
    ↓
Environment policy / approval
    ↓
Deploy
    ↓
Verify + observe

GitHub Actions building blocks

Workflow: automation definition stored under .github/workflows/.
Event: the trigger such as push, pull_request, workflow_dispatch, schedule, or workflow_call.
Job: a set of steps that normally runs on one runner.
Step: either a shell command (run) or an action (uses).
Action: reusable automation packaged as JavaScript, Docker, or composite steps.
Runner: the execution machine for a job.
Artifact: data retained from a run, such as binaries, reports, or packaged output.
Environment: deployment target such as staging or production, optionally protected by approval and branch rules.

The execution boundary

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.

CI/CD as a graph

Jobs can run independently or form a dependency graph:

YAML

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.

Production delivery principles

A strong pipeline should answer:

What source revision is being delivered?
What tests and checks passed?
What artifact was produced?
Who or what authorized deployment?
Which credentials were used?
What environment changed?
How do we verify or roll back?