Gnu Group Learning AcademyGnu Group ↗
Platform Engineering Fundamentals · Module 04 of 12

Golden paths and software templates

Design an opinionated, supported way to create and change services, with safe defaults, extension points and generated evidence instead of brittle copy-and-paste.

Learning objectives

By the end of this module, you should be able to:

  • Define a golden path as a supported option rather than a mandatory one-size-fits-all path.
  • Identify what belongs in a service template and what should remain configurable.
  • Validate template output independently from the portal that invokes it.
Dependency note

Design now; implement the primitives later.

Design first, implement later: this module defines the golden-path contract. Modules 06–08 then supply the Kubernetes/Helm, GitOps and policy primitives that implement it. You do not need those tools to complete the core lab.

Golden paths reduce decision load

A golden path packages defaults for common work: repository structure, ownership metadata, CI, deployment, observability, security and documentation. It should make the supported path easier than rebuilding the same integration manually.

Templates are generators, not the product

Backstage Software Templates can collect inputs, render skeletons and execute scaffolder actions. The generated service still needs lifecycle ownership, upgrades and support.

Keep escape hatches explicit

Teams with legitimate exceptional needs require a documented extension/exception path. Hidden forks become expensive platform debt.

Forward dependency: design the contract before the substrate

A golden path is a product interface, so the interface should be designed from the developer journey before selecting implementation tools. Modules 06, 07 and 08 deliberately arrive later to show how runtime, reconciliation and policy can satisfy the contract without becoming the contract itself.

Worked example

Golden-path output contract

service request → repository + ownership + CI + deploy config + observability + docs → first healthy deployment
  • Judge the path by the usable outcome, not whether scaffolding succeeded.
  • Every generated artifact should have an owner and upgrade story.
Core lab · account-free

Lab 04 — Validate golden-path output

Goal: Generate a synthetic service skeleton and check its required platform artifacts.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create generated service

rm -rf /tmp/golden-service && mkdir -p /tmp/golden-service/{.github/workflows,docs,deploy}
touch /tmp/golden-service/catalog-info.yaml /tmp/golden-service/.github/workflows/ci.yaml /tmp/golden-service/deploy/values.yaml /tmp/golden-service/docs/index.md
STEP 2

Validate expected files

python3 - <<'PY2'
from pathlib import Path
r=Path('/tmp/golden-service')
required=['catalog-info.yaml','.github/workflows/ci.yaml','deploy/values.yaml','docs/index.md']
missing=[x for x in required if not (r/x).exists()]
assert not missing,missing
print('golden-path skeleton complete')
PY2
STEP 3

Add one escape hatch rule

Document which generated field is configurable and which security/ownership controls are non-optional.

Verify

  • Generated output contains ownership, CI, deployment and docs placeholders.
  • At least one extension point and one non-negotiable control are documented.

Expected outcome

  • A minimal but production-shaped service skeleton.

Diagnose / troubleshoot

  • If the template hardcodes team/environment values, move them to validated inputs.
  • If generated services never receive template improvements, define an upgrade strategy.
Real-world connection

Golden paths earn adoption when they make the common secure path faster than bespoke setup.

Real-tool practicum · optional but recommended

Optional tool lab — Backstage Software Template

Inspect the structure of a Backstage template and skeleton in a disposable sandbox.

Prerequisites

  • Use a disposable local lab or organization-approved sandbox.
  • Pin tool versions in real platform automation; do not blindly depend on latest.

Cost / risk

  • Core learning is account-free. Optional external/sandbox tools may consume local CPU/RAM; do not use production credentials or billable cloud resources.

Warnings

  • Do not point training automation at production clusters, repositories or cloud accounts.
  • A successful command is not proof of a good platform interface; validate the developer outcome and guardrails.
TOOL 1
printf '%s
' 'apiVersion: scaffolder.backstage.io/v1beta3' 'kind: Template' 'metadata:' '  name: demo-service' 'spec:' '  owner: platform' '  type: service' > /tmp/template.yaml
cat /tmp/template.yaml
Avoid these traps

Common mistakes

  • Equating a golden path with “no alternatives allowed.”
  • Generating files with no upgrade/lifecycle strategy.
  • Measuring template executions without checking first-deployment success.
Knowledge check

Can you connect the developer need to a platform contract?

Three concept checks plus one scenario check.

1What is a golden path?

A documented, supported, opinionated way to complete a common developer task safely and efficiently.

2What should a template output include besides application code?

Relevant ownership, delivery, deployment, observability, security and documentation scaffolding.

3Why provide an exception or extension path?

Legitimate workloads differ; explicit extensions prevent hidden unsupported forks.

4Scenario: a template creates a repository but teams still spend two days wiring dashboards and policies. Is the golden path complete?

No. The user outcome is not complete; the path should integrate or clearly automate those recurring requirements.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.