Skip to content
APAdam Probert
← The workshop

Platform · 2026

Build Pipeline Orchestrator

Durable Unity build orchestration on Temporal, with the reasoning written down.

What it was

The project

Unity build pipeline orchestration built on Temporal and .NET 8: project validation, then platform builds in parallel, then report generation. It ships with architecture decision records covering retry strategy, observability, graceful cancellation and project-copy strategy, plus a simulation mode so the whole thing runs without Unity installed.

Build

How it fits together

  • Temporal workflows model the pipeline as durable state: validation, fan-out to parallel platform builds, then fan-in to a report.
  • Architecture decision records document retry strategy, observability, simulation mode, graceful cancellation and project-copy strategy.
  • A simulation mode lets the orchestration run end to end with no Unity installation, so the logic can be exercised anywhere.
  • Mermaid architecture and sequence diagrams, and a justfile collecting every command in one place.
Key decisions

The trade-offs that mattered

  • Temporal instead of hand-rolled retry logic

    Builds are long, flaky, and expensive to repeat. Durable execution gives retries, cancellation and visibility as properties of the platform rather than code to maintain.

  • Simulation mode as a first-class feature

    Requiring a Unity licence to test orchestration logic would have made the feedback loop painfully slow and the project impossible to review. Simulating the build step decoupled the two entirely.

  • ADRs over a longer README

    A README says what the system does. An ADR says which options were rejected and why, which is the part that is actually hard to reconstruct later.

What I gained

What I took from it

Recording the why alongside the code changed how the work was received. The ADRs turned out to be the most useful artefact in the repository.

  • Durable execution engines remove a surprising amount of bespoke error-handling code from long-running pipelines.
  • Being able to run the system without its heaviest dependency is worth building deliberately, not discovering by accident.
Contact

Have a difficult, important problem?

I’m happiest where the problem is unclear, several teams need to work together, and the outcome actually matters. If that sounds like your situation, let’s talk.

  • Talk through a hard technical problem
  • Scope a platform, data, or distributed-systems build
  • Get a second opinion on an architecture or delivery plan
  • A role or engagement worth a conversation