Gnu Group Learning AcademyGnu Group ↗
CI/CD Fundamentals · Module 01 of 12

CI/CD foundations and feedback loops

Understand continuous integration, continuous delivery and continuous deployment as engineering feedback systems rather than a collection of automation tools.

Learning objectives

By the end of this module, you should be able to:

  • Distinguish CI, continuous delivery and continuous deployment.
  • Explain why small, frequent changes reduce integration risk.
  • Map source, build, test, artifact and deployment evidence through a delivery flow.

CI is frequent integration with automated evidence

Continuous integration combines small changes into a shared branch frequently and validates them with automated checks. The objective is fast feedback about whether the change can safely join the shared codebase, not merely running a script after a push.

Delivery and deployment are different

Continuous delivery keeps a validated change in a releasable state and can retain a human promotion decision. Continuous deployment goes further and automatically releases each qualifying change to production.

Pipelines should shorten learning loops

A useful pipeline answers concrete questions: can the code build, do tests pass, is the artifact identifiable, and can the release be promoted or rolled back? Faster feedback is valuable only when the checks are trustworthy.

Worked examples

See the idea in practice.

A minimal delivery flow

commit -> build -> test -> package -> deploy staging -> verify -> promote
  • Each stage produces evidence or an artifact.
  • A failure should stop unsafe downstream work rather than being hidden.
Hands-on lab

Lab — Build a local CI feedback loop

Goal: Create a tiny application plus test script and make the pipeline fail fast when behavior is wrong.

Before you start

  • Bash and Node.js are sufficient for the validator.
  • The lab is local and does not require a GitHub account.
STEP 1

Create the application

mkdir -p ~/gnu-cicd-labs/module01 && cd ~/gnu-cicd-labs/module01
printf 'const n=Number(process.argv[2]||0); console.log(n*2);\n' > app.js
STEP 2

Create a test

cat > test.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
[ "$(node app.js 4)" = "8" ]
EOF
chmod +x test.sh
STEP 3

Create a fail-fast pipeline

cat > ci.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
node --check app.js
./test.sh
echo 'CI PASS'
EOF
chmod +x ci.sh
STEP 4

Run it

./ci.sh

Verify

  • The JavaScript syntax check succeeds.
  • The test succeeds and CI PASS is printed.

Expected outcome

  • A reproducible local feedback loop proves the same commands a hosted CI runner can execute.

If it fails

  • If node is missing, install a supported Node.js runtime.
  • If permission is denied, chmod +x the shell scripts.
Real-world connection

Teams should be able to reproduce the core CI commands locally instead of depending on opaque runner-only behavior.

Avoid these traps

Common mistakes

  • Calling any scheduled script 'CI' without frequent integration.
  • Treating continuous delivery and continuous deployment as synonyms.
  • Allowing failed checks to continue into deployment.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What is the central purpose of CI?

Integrate changes frequently and get automated feedback about whether they can safely join the shared codebase.

2Can continuous delivery include a manual production approval?

Yes. It keeps software releasable while promotion can remain a controlled decision.

3Why should a pipeline fail fast?

To stop downstream work when an earlier prerequisite or quality gate has already failed.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.