Back to path
LargePortfolio centerpiece ~31h· 6 milestones

Build a self-service platform slice with progressive delivery

Developers wait on the ops team for every deploy and every new service, and ops is the bottleneck for the whole org. You build the beginnings of an internal platform: developers ship safely on their own, with canary rollouts and observability built in.

Progressive deliveryArgo Rollouts / canaryHelmObservability (metrics/logs/traces)Secrets managementPolicy as codeDeveloper self-serviceChaos engineeringLoad testing to failureBlameless postmortemsInfra cost modeling

What you'll build

A platform slice where a new service goes from repo to production via a templated golden-path pipeline, deploys progressively (canary/blue-green) with automated rollback on bad metrics, and is observable by default.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

template/cookiecutter.jsonjson
{
  "service": "my-service",
  "port": "3000",
  "owner": "team-platform"
}

Reading this file

  • "service": "my-service"The only questions a developer answers. A short input list is what makes self-service fast and hard to get wrong.
  • "port": "3000"Feeds the generated chart and probes so the service is wired correctly without manual edits.
  • "owner": "team-platform"Captures ownership up front so every generated service is labeled with who is responsible for it.

The three inputs a developer answers to scaffold a valid, deployable service.

That's 1 of 10 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Template a service

    5 guided steps

    Self-service only works if doing the right thing is the easy default. A template bakes in CI, packaging, and observability so developers do not reinvent (or skip) them.

  2. 2

    Roll out progressively

    6 guided steps

    A full rollout exposes every user to a bad version at once. Progressive delivery limits the blast radius to a small percentage and lets metrics decide whether to continue.

  3. 3

    Observe by default

    5 guided steps

    You cannot run progressive delivery on metrics you do not collect. Observability has to be a platform default, not a per-team afterthought.

  4. 4

    Secure the supply chain

    5 guided steps

    A self-service platform without guardrails just lets developers misconfigure things faster. Policy-as-code makes the safe configuration the only configuration that deploys.

  5. 5

    Break it on purpose

    6 guided steps

    A platform that has only ever been deployed has never been operated. Injecting failure and pushing to the breaking point is how you find the resilience gaps and cost cliffs before a real incident does.

  6. 6

    Prove self-service

    5 guided steps

    The whole point is removing ops from the critical path. The proof is a developer taking a new service to production progressively, observed and policy-compliant, without filing a ticket.

What's inside when you start

4 starter files, ready to clone
6 guided milestones
6 full reference solutions
10 code blocks explained line-by-line
6 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A golden-path service template that emits CI, a Helm chart, dashboards, and default policies
A recorded canary rollout that auto-rolls-back on a bad metric
A policy-as-code setup that rejects non-compliant manifests, with proof
A chaos/failover experiment report with a load-to-failure capacity number and infra cost model
A blameless postmortem with at least one fix fed back into the template or policies
A short platform design doc and a developer-facing onboarding runbook

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building