Skillnaija All courses →

Design a CI/CD Pipeline and Containerisation Plan for a Sample App

The capstone project for DevOps Foundations — a free Data & Tech course. Pass it and you earn a certificate anyone can verify.

Start the course free Download the project workbook

The project unlocks once you complete the lessons. The workbook is free to download now so you can see exactly what is expected.

What you will submit

A single document (or a public GitHub repo containing it as a README/markdown file) with all six parts: app description + pipeline stages, an annotated Dockerfile, a GitHub Actions workflow outline, the branching/safety explanation, the monitoring plan, and the secrets note. Submit the document text or the repo URL.

What to do, step by step

  1. Pick a simple sample app (e.g. a small Node.js or Python web app — even a naira-to-dollar converter API) and write a one-paragraph description of what it does, then list each CI/CD pipeline stage in order (checkout, build, test, package, deploy) and write one sentence explaining what each stage does for THIS app.
  2. Write a basic Dockerfile for the app and annotate every line with a short comment explaining it (e.g. FROM node:20-alpine with a note that alpine keeps the image small), covering FROM, WORKDIR, COPY, RUN install, EXPOSE, and CMD as taught in the Docker lesson.
  3. Sketch a GitHub Actions workflow outline (the .github/workflows/ci.yml structure) showing name, the on: trigger, a job with runs-on, and the steps — checkout, setup, install, test — and note where a deploy step gated to the main branch (if: github.ref == 'refs/heads/main') would go.
  4. Explain your branching and safety approach in a few sentences: which branching strategy you'd use (e.g. GitHub Flow), why you never deploy directly from a feature branch, and how the pull request plus automated tests act as a safety gate before code reaches main.
  5. Describe how you'd monitor the app once deployed: name what you'd LOG, one or two metrics you'd MONITOR, and one alert rule you'd set (e.g. alert if failure rate exceeds 5% for two minutes), naming at least one real tool from the monitoring lesson.
  6. Add a short note on handling secrets safely (use .gitignore for .env, store keys in GitHub Secrets and reference them as ${{ secrets.NAME }}, never paste them in the YAML or Dockerfile).

Files to work with

Project workbook (fill in, then submit)The whole brief, an evidence checklist, the grading rubric as a self-check and the link-sharing steps in one file. Opens in Word, Google Docs or WPS.Word · 7 KB

How it is graded

CriterionWeight
Pipeline stages are correctly listed in order (checkout, build, test, package, deploy) with a clear, app-specific explanation of what each does25%
The Dockerfile is valid and every line is correctly annotated (FROM, WORKDIR, COPY, RUN install, EXPOSE, CMD), showing real understanding of images vs containers25%
The GitHub Actions workflow outline is structurally correct (name, on trigger, job, runs-on, steps) and shows where a main-gated deploy step fits20%
Branching strategy and the pull-request-plus-tests safety gate are explained correctly, showing why main stays deployable15%
Monitoring/logging plan and secrets-handling note are present, sensible, and reference real tools and practices from the course15%

You need 65% overall to pass. A failed submission comes back with feedback and can be revised and resubmitted.

Before you submit: make your link public

If your work lives in Google Drive or Google Docs, open Share → General access and change “Restricted” to “Anyone with the link” (Viewer). Then paste the link into a private browser window: if it opens without sign-in, you are ready. A private link cannot be graded — it is the single most common reason a good project fails.

Frequently asked questions

Do I have to finish DevOps Foundations before submitting the project?

Yes. The submission screen opens once every lesson in DevOps Foundations is marked complete. The lessons are where the methods, the Nigerian context and the worked examples the project depends on are taught.

How is the project graded?

An examiner scores each rubric criterion from 0 to 100 and weights them as shown on this page; you need 65% overall to pass. Most submissions are graded within minutes and you get written feedback on what was strong and what to improve.

Can I resubmit if I fail?

Yes. A failed project comes back with feedback; revise the weak parts and resubmit. A passed project is final — the certificate is issued and cannot be re-rolled.

What do I actually submit?

A write-up of what you did (under 5,000 characters) plus a public link to your work — a Google Drive folder, Google Doc, spreadsheet, GitHub repository or video. The link must open without sign-in; a private link cannot be graded. The free project workbook on this page walks you through all 6 steps.

Is the certificate real?

Yes. Passing this project issues a certificate with a unique verification code. Anyone — an employer, a client, a school — can open the verification page and see that the certificate is genuine and which project earned it.

More Data & Tech projects

Ready to earn this certificate?

DevOps Foundations is free and self-paced. Finish the lessons, complete this project, and the certificate is yours to share.

Start learning free