08 · Developer Experience & Abstracted Self-Service
Milestones of the roadmap items in this theme
As of 2026-10-22 · today
Gantt
Milestones
| # | Milestone | Start | Target | Status | Waits for | Team | Epic | Derived |
|---|---|---|---|---|---|---|---|---|
| 22 · Backstage Internal Developer Platform (IDP) | ||||||||
| 22.1 | Backstage online, catalog and identity wired | 2026-08-17 | 2026-12-18 | in progress | — | SRE · Platform Engineering | — | — |
| 22.2 | Templates cover what the backends can provision | — | 2027-09-10 | planned | 22.1 | SRE · Platform Engineering | — | waiting 22.1 |
| 22.3 | Request and approval are a Backstage flow, recorded | — | 2028-03-10 | planned | 22.2 | SRE · Platform Engineering | — | waiting 22.2 |
| 22.4 | Backstage is the way in for everything except release | — | 2028-09-08 | planned | 22.3 | SRE · Platform Engineering | — | waiting 22.3 |
| 23 · Cogwork Desktop Application | ||||||||
| 23.1 | Cogwork executes a release in the order the ticket sets | 2026-07-06 | 2027-05-28 | in progress | 24.2 | SRE | — | waiting 24.2 |
| 23.2 | Cogwork triggers GitLab CI where it triggered Jenkins | — | 2028-09-08 | planned | 15.3, 23.1 | SRE | — | waiting 15.3, 23.1 |
| 23.3 | Cogwork's credential and network path under zero trust | — | 2028-07-14 | planned | 13.3 | SRE | — | waiting 13.3 |
| 24 · Release Ticket System | ||||||||
| 24.1 | Release requests and their order in one place | 2026-07-06 | 2026-11-27 | in progress | — | SRE | — | — |
| 24.2 | The release order is data the executor can rely on | — | 2027-09-10 | planned | 24.1 | SRE | — | waiting 24.1 |
| 24.3 | Triggering moves to GitLab CI as Jenkins retires | — | 2028-09-08 | planned | 15.3, 24.2 | SRE | — | waiting 15.3, 24.2 |
| 24.4 | Every release carries a reviewable change record | — | 2029-01-12 | planned | 24.3 | SRE | — | waiting 24.3 |
Details
22.1Backstage online, catalog and identity wired2026-12-18in progress · 2/4
- Backstage deployed and in useowner · Charles
- The producer is already merged in the audit-trail repository, so requests and approvals made here are recorded from the start rather than retrofitted.
- Catalog entries carry an ownerowner · TBDA catalog without ownership answers "what exists" and not "whose is it" — and the second question is the one asked during an incident.
- SSO groups decide what a person may requestowner · TBD
22.2Templates cover what the backends can provision2027-09-10planned · 0/4
- Templates for namespaces, Harvester VMs, databases and network changesowner · TBD
- Each template provisions through the owning backend, never reimplementing itowner · TBDA template that provisions by itself becomes a second path with its own defaults, and the two drift. Backstage carries the form; Terraform, Ansible and ArgoCD still do the work.
- Defaults, quotas and ownership applied out of the boxowner · TBD
- A template no backend can fulfil is not publishedowner · TBDA form that takes a request nobody can serve is worse than no form: it converts a conversation into a queue.
22.3Request and approval are a Backstage flow, recorded2028-03-10planned · 0/4
- Who applied and who approved, recorded on every requestowner · TBD
- The scaffolder opens the GitLab MRowner · TBD
- This is the head of the chain 20.4 queries: the request and approval are where it starts, and without the key the rest cannot be joined to them.
- Release is not in this flow — it stays with item 24owner · TBDBackstage approves provisioning; the release ticket system approves releases. Different objects, one approval flow each — the alternative is two portals that both think they own change.
22.4Backstage is the way in for everything except release2028-09-08planned · 0/4
- Infrastructure and application self-service requests arrive through Backstage, not tickets or chatowner · TBD
- Direct routes to the backends closed for routine requestsowner · TBDWhile the old route works it will be used the first time the form is inconvenient, and then the catalog is a second record of a subset.
- How many requests still arrive another way, measuredowner · TBD
- Release deliberately excluded, and the reason statedowner · TBD
23.1Cogwork executes a release in the order the ticket sets2027-05-28in progress · 1/4
- Advances one system at a time, stopping on failure rather than continuingowner · TBDA release of twenty systems that keeps going after the third fails is worse than one that stops: the later systems are now running against something that did not deploy.
- What "done" means for a system before the next one startsowner · TBDTriggered is not deployed and deployed is not healthy. Ordering only means something if the gate between two systems is the right one.
- Progress visible while a twenty-system release is runningowner · TBD
23.2Cogwork triggers GitLab CI where it triggered Jenkins2028-09-08planned · 0/3
- The Jenkins panel has no backend once Jenkins retires — repointed at GitLab CIowner · TBD
- Single-application deploys leave cogwork; ordered releases stayowner · TBD14.3 makes a single application's deployment follow a merge, with no person in the loop. An ordered release across twenty systems is the stated exception and it is driven here — the two are different jobs that used to share one button.
- The ext API contract re-checked against what movedowner · TBD24.3 changes what the ticket system does at release time and cogwork reads it over that interface; both sides move, so the contract is checked once from each.
23.3Cogwork's credential and network path under zero trust2028-07-14planned · 0/3
- The ext API key is a static credential living on laptops — replaced with a per-user identityowner · TBDExactly the kind of credential item 12 exists to eliminate, and it is on the least controlled machine in the estate — while carrying the right to advance a production release.
- Cogwork reaches internal systems over NetBird, like everything elseowner · TBD13.3 makes NetBird the start of every path in; a desktop tool talking straight to internal APIs would be the exception that makes that claim untrue.
- When a person leaves, revocation is one actionowner · TBD
24.1Release requests and their order in one place2026-11-27in progress · 3/4
- Zitadel SSO issuing JWT, with rolesowner · Charles
- Release form, order field, feedback and lifecycle in useowner · Charles
- The ext API contract with cogwork versionedowner · TBD23.2 and 24.3 both move underneath that interface. An unversioned contract between two systems changing at once is how one of them breaks quietly — and here the thing that breaks is a release already under way.
24.2The release order is data the executor can rely on2027-09-10planned · 0/4
- Order recorded per system, not implied by row positionowner · TBDA list that is ordered only because of how it happens to be sorted breaks the first time a row is edited. The executor needs an order it can read, not infer.
- Dependencies between systems expressed where they existowner · TBD
- The ext API exposes the ordered list as the contract cogwork executesowner · TBD
- A release of twenty-plus systems is the normal case, not an edge caseowner · TBDThis is why the pair exists. A spreadsheet can hold a list; it cannot be the thing another system executes in order, and that is the whole difference.
24.3Triggering moves to GitLab CI as Jenkins retires2028-09-08planned · 0/4
- Where it triggered Jenkins, it triggers GitLab CIowner · TBD
- The system triggers CI; it does not deployowner · TBDThe Git change ArgoCD reconciles comes from a person merging in GitLab. The ticket system authorises, records and triggers — three jobs, none of which is deploying.
- test-merge and merge are implemented endpoints with a role check and per-branch conflict reporting; they are not a documentation error. Whether they remain is a decision to make here, and the architecture pages follow that decision rather than the other way round.
- Without it the chain 20.4 queries breaks exactly where a human decision was made, which is the part anyone reviewing a release wants to see.
24.4Every release carries a reviewable change record2029-01-12planned · 0/4
- Change classification agreed, and applied per releaseowner · TBD
- Review evidence and rollback plan recorded before release, not afterowner · TBDA rollback plan written after the release is a description of what happened. Written before, it is the thing someone reads at 3am — and for a twenty-system release it has to say what to do about the systems that already went.
- Post-release feedback closed on the ticketowner · TBD
- This is the record a person reviews; 20.4 is the chain a query walksowner · TBDTwo different needs on the same release. Collapsing them means either a compliance record nobody can query or a query result nobody can review.
Back to the Platform Roadmap overview · the direction behind these milestones is the Platform Roadmap.