Back to path
ExpertBeacon · Project 11 of 12 ~14h· 6 milestones

Build self-service golden paths

Continues from the last build: It ships beautifully, but every new service is a copy-paste of its pipeline that drifts from the standard the next day.

It delivers like a dream now. The pipeline builds once, promotes through dev, staging, and prod, runs policy gates, and wires secrets per environment.

Platform engineering and golden-path designAuthoring reusable GitHub Actions workflows with workflow_callService templating with cookiecutterBackstage software templates and catalog descriptorsBuilding a paved-road developer CLITreating delivery standards as versioned, reusable artifactsReducing time-to-first-deploy through self-service
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

You will ship a platform-engineering golden path for the track: a cookiecutter template plus a paved-road CLI that scaffolds a new service repo in minutes, a set of reusable GitHub Actions workflows the generated repo calls instead of copying, a machine-readable service catalog entry and Backstage software template, and a smoke verification that proves a freshly scaffolded service reaches its first deploy with CI, promotion, policy gates, secrets wiring, and a dashboard descriptor already in place. The payoff is that the standard now lives in one versioned place, so improving the paved road improves every service at once and new-service drift stops at the source.

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:

paved-road/templates/service/cookiecutter.jsonjson
{
  "service_name": "My Service",
  "service_slug": "{{ cookiecutter.service_name.lower().replace(' ', '-') }}",
  "owner_team": "messaging",
  "language": "python",
  "http_port": "8000",
  "_platform_version": "v1"
}

Reading this file

  • "service_slug": "{{ cookiecutter.service_name.lower().replace(' ', '-') }}"Derived value: the slug is computed from the name, so a developer never types an inconsistent repo or image name.
  • "language": "python"A plain string default, not a choice list. Every service on this track is python, and the shared workflow has no other language branch, so offering alternatives would be dead wiring.
  • "_platform_version": "v1"A leading underscore makes this a private variable cookiecutter does not prompt for; it stamps which paved-road version generated the repo.
  • "http_port": "8000"Defaults to the stable :8000 contract so generated services match the api convention out of the box.

Defines the prompts cookiecutter asks. service_slug is derived from the name so repo and image names stay consistent across the org. language is a fixed string because every service on this track is python.

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

The build, milestone by milestone

  1. 1

    Map the paved road before you pave it

    4 guided steps

    A golden path that does not encode the actual standard just produces prettier drift. The inventory is the spec.

  2. 2

    Extract the standard into reusable workflows

    4 guided steps

    Centralizing the logic means a security fix or a new policy gate ships to every service the moment you merge it to the shared workflow.

  3. 3

    Build the cookiecutter service template

    4 guided steps

    The template is where time-to-first-deploy collapses: a developer answers prompts and gets a wired repo, no archaeology required.

  4. 4

    Register the service in the catalog and Backstage

    4 guided steps

    A golden path without a catalog is invisible; the catalog turns scaffolded services into a queryable inventory with clear ownership, and the publish step is what makes Backstage create and register the repo end to end.

  5. 5

    Wrap it in a paved-road CLI

    4 guided steps

    Adoption lives or dies on friction. beacon new is something a developer remembers; a long cookiecutter invocation with a git URL is something they copy-paste wrong.

  6. 6

    Prove time-to-first-deploy with a scaffold smoke test

    4 guided steps

    A golden path that is not continuously tested rots. The smoke test is the paved road's own CI, and the timing is the metric leadership cares about.

What's inside when you start

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

You'll walk away with

A paved-road-contract.md inventory that labels every required new-service artifact as templated (per-service wiring) or shared (reusable workflow)
A reusable GitHub Actions workflow (service-ci.yml with workflow_call) in the org platform/.github repo that the api, worker, and every generated service call instead of copying
A cookiecutter service template that renders a deployable repo with CI calling the shared workflow, a catalog-info.yaml, and a dashboard descriptor, plus a matching Backstage software template with fetch, publish, and catalog:register steps
A packaged paved-road CLI exposing beacon new that scaffolds a wired repo in one command
A scaffold smoke test (scripts/smoke-scaffold.sh) that asserts the full contract is rendered, ignores legitimate ${{ ... }} Actions expressions, fails loudly with a named message on any gap, and reports time-to-first-deploy

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