My progress
Menu

Level 6 · Cloud Computing, DevOps and Cybersecurity · Course 6.3 DevOps and Operations

Module 71: CI/CD

Goal: make every change to your CRM build, test and deploy itself the same careful way every time, using GitHub Actions, with quality gates that stop bad changes and a quick way back when something slips through.

You'll need: your CRM on GitHub, its tests (Modules 29, 46 and 59), the containerised set-up and deploy script from Modules 69 and 70, and a staging server.

Lessons

  1. 1Principles of CI/CD15–25 minutes✓
  2. 2Automated builds15–25 minutes✓
  3. 3GitHub Actions15–25 minutes✓
  4. 4Tests and quality gates15–25 minutes✓
  5. 5Pipelines and rollback15–25 minutes✓

🛠️Module practice: Project C, part 1, an automated pipeline

  1. A CI workflow on every pull request: install, typecheck, lint, migrate, test with a real database, build, audit.
  2. Branch protection on main requiring the CI check.
  3. A deploy workflow: build and push a commit-tagged image, deploy to staging, smoke-test.
  4. A production job that needs your approval, with secrets in a GitHub environment.
  5. A tested rollback workflow and a note in your operations guide on how to use it.

✅Module check

Explain in a few sentences, in your own words:

What is CI/CD, and how does it make releases safer?

Show a good answer

A good answer mentions: small changes integrated often and automatically built and tested on clean machines (exact dependencies, type checks, lint, real-database tests); quality gates (tests, audits, secret scanning, review) made compulsory with branch protection, kept fast and free of flaky tests; images built once and tagged by commit; deployment to staging with smoke tests before an approved production release; secrets stored in GitHub environments with least privilege; and a practised rollback workflow, with every deploy recorded.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. What's the difference between continuous delivery and continuous deployment?

Why each option is right or wrong

  • “They're the same practice, just named differently by each company” (Incorrect): They differ in whether the final release step is automatic.
  • “Delivery releases automatically; deployment needs someone to approve it” (Incorrect): That's the wrong way round.
  • “Delivery is for websites; deployment is only for mobile apps” (Incorrect): Both apply to any kind of software.
  • “Delivery keeps changes ready to release; deployment releases them automatically” is correct.

    With continuous delivery, every change that passes the pipeline could go live, but a person presses the button. With continuous deployment, passing changes go to production automatically, with no manual step.

    • Both need: reliable automated tests.
    • Many teams: start with delivery, then move to deployment.

📖 Revise: Lesson 1: Principles of CI/CD

Question ID module-71-q1 · Report a mistake in this question
2. Why do small, frequent changes make releases safer?

Why each option is right or wrong

  • “Small changes skip the need for any automated testing” (Incorrect): They still need tests; they're just easier to test.
  • “Servers handle small files more quickly than large ones” (Incorrect): File size isn't the reason; risk and debugging are.
  • “Frequent releases mean nobody has to review the code” (Incorrect): Reviews still matter; small changes make them easier.
  • “Each is easy to test, and problems are quick to find and roll back” is correct.

    A release with one small change has little that can go wrong, and if something does, the cause is obvious. A big release with months of changes is hard to test and harder to debug.

    • Habit: merge small pull requests often.
    • With feature flags: unfinished work can ship switched off.

📖 Revise: Lesson 1: Principles of CI/CD

Question ID module-71-q2 · Report a mistake in this question
3. Why use npm ci instead of npm install in a build?

Why each option is right or wrong

  • “It installs the newest version of every package available” (Incorrect): It does the opposite: it sticks to the locked versions.
  • “It skips installing development dependencies to save time” (Incorrect): By default it installs them; the key is exact versions.
  • “It runs the tests automatically after installing” (Incorrect): It only installs; tests are a separate step.
  • “It installs exactly what the lock file says” is correct.

    npm ci deletes node_modules and installs the exact versions in package-lock.json, failing if the lock file and package.json disagree. Builds are then repeatable, while npm install may update versions within allowed ranges.

    • Commit: the lock file.
    • Local development: npm install is fine for adding packages.

📖 Revise: Lesson 2: Automated builds

Question ID module-71-q3 · Report a mistake in this question
4. Why build on a clean machine?

Why each option is right or wrong

  • “Clean machines run the build much faster than laptops” (Incorrect): Speed varies; the point is repeatability.
  • “Developers' laptops can't install the packages the app needs” (Incorrect): They can, but leftover tools and files may hide steps the build is missing.
  • “It's required by the npm licence terms” (Incorrect): There's no such licence term.
  • “To prove the build doesn't depend on someone's computer” is correct.

    A build that works only on a developer's laptop may rely on a globally installed tool, a leftover file or a setting nobody wrote down. Building from scratch in CI catches those hidden dependencies.

    • CI runners: start fresh every time.
    • Docker builds: give the same benefit.

📖 Revise: Lesson 2: Automated builds

Question ID module-71-q4 · Report a mistake in this question
5. Where should a registry token for a workflow be stored?

Why each option is right or wrong

  • “Written directly in the workflow YAML file” (Incorrect): The file is in the repository, so the token would leak.
  • “In the README, so the team knows where it is” (Incorrect): READMEs are widely read; secrets don't belong there.
  • “In a code comment next to the deploy step” (Incorrect): Comments are part of the code and visible to everyone with access.
  • “In the repository's Actions secrets” is correct.

    GitHub Actions secrets are encrypted, hidden from logs, and given only to workflows that use them. Writing the token in the workflow file would expose it to anyone who can read the repository.

    • Use: ${{ secrets.REGISTRY_TOKEN }} in the workflow.
    • Limit: the token's permissions to what the workflow needs.

📖 Revise: Lesson 3: GitHub Actions

Question ID module-71-q5 · Report a mistake in this question
6. Why does a CI workflow start a PostgreSQL service?

Why each option is right or wrong

  • “GitHub needs a database to store the workflow results” (Incorrect): GitHub stores results itself; the service is for your tests.
  • “To back up the production database during every run” (Incorrect): CI shouldn't touch production data.
  • “So the app can be deployed straight from the database” (Incorrect): Deployment doesn't come from the database.
  • “So integration tests run against a real database” is correct.

    Repository tests check real SQL, constraints and transactions. A PostgreSQL service container gives each CI run a fresh, real database, so those tests run automatically on every change.

    • Run migrations first: so the schema matches.
    • Use test credentials: not production ones.

📖 Revise: Lesson 4: Tests and quality gates

Question ID module-71-q6 · Report a mistake in this question
7. What does branch protection add to CI?

Why each option is right or wrong

  • “It runs the tests twice to make sure they really pass” (Incorrect): It doesn't rerun tests; it requires them to pass.
  • “It hides the main branch from other developers” (Incorrect): Everyone can see it; protection controls how changes arrive.
  • “It backs up the branch to another server every night” (Incorrect): It's about merge rules, not backups.
  • “It makes checks compulsory before changes reach main” is correct.

    Without protection, someone can merge while tests are failing, or push straight to main. Branch protection requires passing checks, and optionally reviews, before merging.

    • Common rules: required status checks, required review, no force pushes.
    • Admins: can be included so nobody skips the rules.

📖 Revise: Lesson 4: Tests and quality gates

Question ID module-71-q7 · Report a mistake in this question
8. What should you do with a flaky test?

Why each option is right or wrong

  • “Rerun the pipeline until it passes” (Incorrect): That trains everyone to ignore failures.
  • “Leave it, since it passes most of the time” (Incorrect): Occasional false failures still erode trust in the pipeline.
  • “Mark every test as optional” (Incorrect): That removes the safety net completely.
  • “Fix it or remove it quickly” is correct.

    A test that fails at random teaches the team to ignore red builds and rerun until green. Then real failures get ignored too. Find the cause, often timing or shared data, and fix it, or remove it until it's fixed.

    • Track: which tests fail intermittently.
    • Common causes: fixed waits, shared state, real network calls.

📖 Revise: Lesson 4: Tests and quality gates

Question ID module-71-q8 · Report a mistake in this question
9. What does a GitHub environment with required reviewers add?

Why each option is right or wrong

  • “It reviews the code automatically using AI” (Incorrect): Reviewers here are people who approve the deployment.
  • “It speeds up the deployment by skipping tests” (Incorrect): It adds a check; it doesn't skip tests.
  • “It lets anyone with the link deploy to production” (Incorrect): It restricts deploys to approved runs.
  • “A person must approve before the job runs” is correct.

    Jobs that deploy to a protected environment, like production, pause until a listed reviewer approves. This adds a deliberate human check for the riskiest step while keeping everything else automated.

    • Environment secrets: are released only to approved jobs.
    • Use for: production deploys.

📖 Revise: Lesson 5: Pipelines and rollback

Question ID module-71-q9 · Report a mistake in this question
10. Why run smoke tests after deploying to staging?

Why each option is right or wrong

  • “To make staging faster for real customers” (Incorrect): Staging isn't for customers; smoke tests check the deploy.
  • “Because unit tests can't run in CI” (Incorrect): Unit tests run in CI; smoke tests check the deployed app.
  • “To delete old releases from the server” (Incorrect): Clean-up is separate from testing.
  • “To prove the deployed app actually works” is correct.

    Unit tests passed before the build, but deployment can still break things: a missing environment variable, a wrong database address or a broken route. A few quick checks against the deployed app, like loading the home page and calling the health endpoint, catch these.

    • Keep them fast: a minute or two.
    • Then: promote to production.

📖 Revise: Lesson 5: Pipelines and rollback

Question ID module-71-q10 · Report a mistake in this question

ProLearners Assist