A contract with the repository
CI/CD pipelines
A pipeline is a written promise: every push gets built, tested, and only then deployed. It lives in the repository, so it is reviewed like code and versioned with the thing it ships.
Stages, not steps
Build, test, deploy — each stage only starts when the previous one passed. That ordering is the value: a red test stops a deploy without anyone remembering to check.
Jenkins keeps this in a Jenkinsfile (`pipeline { stages { ... } }`); GitHub Actions keeps it in `.github/workflows/*.yml` with `jobs` and `needs:` to declare the order. Same idea, different syntax.
Fail fast, and leave evidence
A pipeline that continues after a failure is worse than no pipeline, because it reports success. Make each command's non-zero exit fail the job, and keep the artefacts a human will need when it does.
Secrets belong in the platform's secret store, injected at run time — never in the YAML, which is committed and mirrored to every fork.
Commands in this lesson
Every one of these runs in the sandbox — no real account, no real bill.
| Command | Why |
|---|---|
echo " steps { sh 'npm ci && npm test' }" >> Jenkinsfile | One stage, one contract: install exactly and test. |
echo ' - uses: actions/checkout@v4' >> /home/student/.github/workflows/ci.yml | The job starts with the repository at that commit. |
echo ' - run: npm ci' >> /home/student/.github/workflows/ci.yml | `ci` installs from the lockfile — reproducible, unlike `install`. |
echo ' needs: build' >> /home/student/.github/workflows/ci.yml | The dependency that makes 'test' wait for 'build'. |
Now do it
Reading the model makes the first attempt faster. Only the lab makes you able to do it.
- Open the lab
Jenkins: A Declarative Pipeline
Intermediate · 18 min · members
- Open the lab
CI/CD: GitHub Actions Workflow with Build, Test, Deploy
Intermediate · 25 min · members
CI/CD pipelines · OphirCloud Academy · all lessons