1. Courses
  2. Developer Foundations

Developer Foundations line, station 8 of 9

Ship a Project End to End

Take one small app from issue to tagged release and hotfix, write the playbook your team ships by, and work safely with AI coding assistants.

  • 3lessons
  • 2 hto read and do
  • Advancedlevel
  • 3podcast episodes
  • 3checked exercises
Start the courseCheck what you know

Tools you'll use in this course

The lessons open these with a template ready. They work for your own job too, no course needed.

About this course

This is the capstone course of Kolom's Developer track and the Full-Stack Developer path. Earlier courses taught one tool at a time; here you use all of them together on a real delivery path. You build a store stock checker for Mangrove Market, a fictional grocery chain, as a small Node and TypeScript API with a web page, and take it from a GitHub issue through CI on two Node versions, review, a squash merge and a tag-triggered release to GitHub Pages and a container registry, then ship a test-first hotfix the next morning.

The second lesson turns that path into team rules: a short CONTRIBUTING.md, a PR template, CODEOWNERS and rulesets that enforce what a tool can enforce. You measure whether the rules help with DORA's four keys, read straight from tags, pull requests and incident issues, and learn to turn the numbers into one process change instead of a ranking. The third lesson adds a new kind of teammate, AI coding assistants, with an instruction file, a test-first prompt, a review checklist and a CI guard.

Each lesson has diagrams, a worked Mangrove example, real commands and outputs, quick checks, practice tasks (some auto-checked in your browser), flashcards and a podcast episode. The course project is a small app of your own with a real release history, and the final exam earns a free certificate.

What you will be able to do

  • Take a feature from a GitHub issue to a reviewed, squash-merged pull request with required CI on two Node versions
  • Ship a static page to GitHub Pages and an API image to GitHub's container registry from a version tag, with least-privilege workflow permissions
  • Run a hotfix the safe way: failing test first, a small PR, a patch version and a written rollback plan
  • Write a team playbook (CONTRIBUTING.md, PR template, CODEOWNERS and rulesets) that enforces what tools can enforce
  • Measure delivery with DORA's four keys from tags, PRs and incident issues, and turn the numbers into one process change
  • Brief, review and guard AI coding assistants with an instruction file, test-first prompts and CI checks

Syllabus

3 stops, about 2 h in total. Each stop fills in when you complete the lesson.

  1. Project: ship a small app end to end

    Every earlier course on the Developer track taught one tool. This lesson uses all of them on one small project, in the order a real team would: an issue, a branch, commits, a pull request with a review, CI, a tagged release, a deployment, and a hotfix the next day. Follow along and you will have done, once, everything a product team's engineers do every week.

    40 minAdvancedEpisode1 exercise

    CI/CD with GitHub ActionsRelease managementHotfixes

  2. Your team's engineering playbook

    A playbook is the short set of rules your team agrees on: how branches are named, how big a PR may be, who approves, what "done" means, when you release and how you hotfix. A product manager does not write the code but is often the best person to get these rules written down, agreed and kept, and every developer is the one who follows them. This lesson gives you a complete starter set and a way to measure whether it works.

    40 minIntermediateEpisode1 exercise

    Engineering playbooksCode reviewDORA metrics

  3. Working with AI coding assistants

    AI assistants now write a real share of the code in many teams, from one-line completions to whole pull requests. They are fast and tireless, and they are confidently wrong often enough that the team's habits matter more than the tool. This lesson explains how they work in plain words and gives you the instruction file, prompt, review checklist and CI check that keep them useful and safe.

    30 minIntermediateEpisode1 exercise

    AI-assisted developmentAI code reviewCI guardrailsPrompt writing

  4. Capstone: Ship the Partner app's delivery slot checker

    A realistic project with a rubric and a model answer.

  5. Final exam and certificate

    10 questions drawn at random, 70% to pass.

Capstone project

Ship the Partner app's delivery slot checker

Mangrove Market's 1,800 partner corner shops keep phoning the distribution centres to ask when their next delivery arrives. Imran, the product manager for the Partner app, wants a small delivery slot checker: a shop enters its shop code and sees its next delivery slot (date, time window and DC), or a clear error for an unknown or badly formed code. Build it the way this course ships software, in a public GitHub repository: a small Node and TypeScript API with a JSON file standing in for the database, and a plain web page that calls it. You may start from the store stock checker in the first lesson. Take it from an issue to v1.0.0 through CI, a ruleset, a reviewed PR and a tag-triggered release, then plant and report a realistic bug (for example, shop codes with a new prefix are rejected) and ship v1.0.1 as a test-first hotfix. Add the team playbook files, and finish with a short delivery report from your repo's own data. If you cannot deploy the API to a server, run the image locally and say so in the README.

You will hand in

  • A public GitHub repo with at least four merged PRs (CI, feature, release workflow, hotfix), each linked to an issue
  • CI on Node 22 and 24, a ruleset that requires both checks, and a tag-triggered release workflow with job-level permissions
  • Tags v1.0.0 and v1.0.1 with GitHub Releases and a CHANGELOG.md, where v1.0.1 fixes the reported bug and the failing test came first
  • CONTRIBUTING.md, a PR template and CODEOWNERS, plus an AGENTS.md if you used an AI assistant
  • A one-page delivery report: lead time for each PR, number of deploys, change fail rate, and one playbook change you would make
Open the project brief

Check what you know

Already know some of this? Answer 3 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 2 minutes and nothing is graded.

Questions

How long does the course take?

About two hours for the three lessons, roughly 25 to 40 minutes each, plus 2 to 6 hours for the project. The first lesson is a follow-along build, so give it a quiet block of time and a terminal.

What should I know before starting?

You should be comfortable with Git branches, pull requests, GitHub Actions basics and JavaScript or TypeScript. GitHub for Teams and JavaScript in the Real World cover all of it, and every lesson here links back to the exact lesson it builds on.

Do I need a paid GitHub plan or my own server?

No. A free GitHub account with a public repository is enough for Actions, Pages and the container registry. To run the API image you need Docker or a container service; running it on your own laptop is fine for the project.

Is the certificate free?

Yes. All lessons, podcasts, quizzes, practice tasks, the final exam and the certificate you earn by passing it are free.

How does the final exam work?

Each attempt picks 15 random questions from the course's question bank, mostly short scenarios like the ones in the lessons. You need 70% to pass. If you don't pass, you can try again after 24 hours with a new set of questions. The answer key is never shown, which keeps the certificate meaningful.

Is it really free?

Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.