Glidepath · Review · The software lifecycle

Glidepath against the everyday software lifecycle

I wanted to know how Glidepath holds up against the delivery tools most teams already use, so I read it the way a reviewer would: the code, the ADRs and the docs, across every repo it touches. Each finding below says whether it holds today, so a design that is built is never mistaken for one that is enforced.

Review October 12, 2026Basis code, ADRs and docs of glidepath, tower, airframe, apron and hangarScale in build since Aug 12, 2026 · 1 engineer · 2 clusters · 25 ADRs · 42 logged gapsCompanion Glidepath production roadmap
Strong merge to prod · governance advises

Strong on the road from merge to production, by design. Thin on the developer's inner loop. Most of its governance advises today rather than enforces.

The change road, as built

A developer writes one cicd.yaml. Pipelines-as-Code starts the first stage from a GitHub webhook, and every later stage starts on the previous stage's CDEvent through a broker that authenticates with the pod's own ServiceAccount token. Ground environments get a direct bot commit. Flight environments only change when a PR on gitops-<app> merges and that cluster's Argo CD pulls it.

The change road, as builtIn the app repo, a push or PR starts build, test and deploy to dev, each stage chained by CDEvents. Only the build stage posts a PR check; test results never reach the PR and a missing test passes; the dev canary is a single 100 percent step. A service.deployed event starts the release stage, which opens a PR on the gitops repo with the same image digest. Real gates and stub gates that always pass run as checks, then a human review that GitHub Free does not enforce; a bypass alert fires only after merge. change.created starts the next environment as soon as the PR opens. The pull-only boundary, Argo CD on the upper cluster pulling the merged commit, holds.INNER LOOP · APP REPO · EACH STAGE STARTS ON THE LAST ONE'S CDEVENTPush or PRPaC webhookbuildkaniko · two archestestTestkube, 10 min capdeploybot commit to mainRunning in devArgo RolloutPR CHECK POSTS HERENO PR CHECK, NO REPORTSNO TEST FILE = PASSCANARY: ONE 100% STEPSERVICE.DEPLOYEDRELEASE · GITOPS REPO · ONE PR PER UPPER ENVIRONMENTreleaseopens the PRGitops PRsame image digestReal gatessast scan prov sbomHuman review2 approvals askedUpper Argo CDpulls merged commitNext env PRstarts at onceStub gatesitsm · qa · policyBypass alertSlack, after mergeCHANGE.CREATEDNOT ENFORCED ONGITHUB FREEPULL-ONLY BOUNDARYHOLDSNOT TIED TOSTAGING HEALTHALWAYS PASSThe release path is designed right. Today the pull-only boundaryenforces it, and the checks only advise.LEGENDStageCheck or systemStub, always passesAfter the factDoes not holdHolds today
Figure 1Where each guarantee holds. Amber marks the places where a check exists on paper but nothing stops a change that skips or fails it.

Typical workflows, rated

Against what teams usually expect from GitHub Actions, GitLab CI or a commercial delivery platform.

WorkflowSupportWhy
Trunk-based: push to main, deploy to devGoodPath filters, multi-arch builds, unit tests, then a dev deploy that waits until the Rollout is healthy.
Tag-driven releaseGoodtagPattern regex; the version comes from the tag.
PR validationPartialThe PR build gets a native check. Test, deploy and scan results never reach the PR. Unit tests return pass or fail only: no JUnit, no coverage.
PR preview environmentsPartialA real ApplicationSet with a TTL sweep. Needs a label, skips opened, has no URL (port-forward only).
Promotion dev to staging to prodPartialGated PR per environment, but the next one starts when the PR opens, not when staging is healthy.
RollbackPartialA gated PR to one of the last five healthy releases. Manual, minutes to tens of minutes; live verification still pending.
DORA and delivery insightPartialNo environment label, Ground and cloud deploys not counted, lead time starts at build. MTTR is marked experimental.
Integration and e2e testsWeakTestkube with a 10 minute cap. No matrix, no retries, no environment URL passed in. A missing test reports success.
Release branches and GitFlowWeakA push trigger matches the branch exactly, so branch: release/* on push never fires.
Non-Kubernetes targetsExperimentalECS, Lambda and Azure Container Apps are render-tested. The one live ECS run failed.
Approvals and change managementNot enforcedGitHub Free does not enforce rulesets on private repos. The bypass alert fires after merge. ITSM, QA and policy gates always pass.
Progressive delivery, auto-rollbackMissingDefault canary is one setWeight: 100 step. Analysis needs metrics nobody scrapes, and a query with no data passes.
Hotfix track, freezes, scheduled releasesMissingNothing in the schema or the catalog.
MonorepoMissingRepo name must equal app name, build context is the repo root, one image per app.
Cron, manual dispatch, ChatOpsMissingNo triggers for them. /retest <gate> re-runs nothing (gap 20).
Feature flags and DB migrationsMissingNo flag system. Migrations are Helm pre-upgrade Jobs with no gating and no rollback path.

Revised the same day: the production roadmap moved approvals and change management from Not enforced to Partial. The install already requires a ruleset on every gitops repo; it's the lab's GitHub Free plan that leaves it unenforced.

Where the control plane lives

The pull model between clusters is sound: nothing on dev holds prod credentials, and prod only changes from a merged commit. Everything else that makes delivery observable and governable runs on the dev cluster.

Where the control plane livesThe dev cluster runs Tekton and Pipelines-as-Code, the broker and relay, Argo CD for Ground environments, release records and DORA, and Infisical, which also serves prod secrets. GitHub webhooks reach Tekton through a temporary tunnel. The prod cluster runs its own Argo CD, which pulls merged commits from GitHub, the staging and prod workloads, and External Secrets, which fetches secrets from Infisical on the dev cluster over a plain-HTTP NodePort. Rollout facts flow back from prod Argo CD to the relay on dev.GitHubapp + gitops reposTHE DEV CLUSTER · LOWER ZONE · CONTROL PLANETHE PROD CLUSTER · UPPER ZONETekton + PaCevery pipeline runBroker + relayCDEvents, factsArgo CD · devGround environmentsRecords + DORAConfigMaps, exporterInfisicalsecrets for dev + prodArgo CD · prodown instanceStaging + prodArgo RolloutsESOsecret syncWEBHOOK VIA TUNNELPULLS MERGED COMMITROLLOUT FACTSPLAIN HTTP NODEPORTOne dev cluster runs every control-plane job. Prod keeps serving without it,but loses release feedback, records, metrics and secret refresh.LEGENDComponentExternalFragile linkPull, soundFeedback
Figure 2The dev cluster as a single point of failure. The webhook tunnel once died for about 19 hours with no alert (known gap 8).

Strengths

Holds · ADR-0017 · cicd.schema.json

A real paved road

One validated file, scaffolded rather than hand-written. Developers never write Tekton, and preflight rejects a bad config before anything runs.

Holds · image-signing.md

Supply chain beyond the norm

Tekton Chains signs keylessly through a self-hosted Fulcio and Rekor, Conforma checks the provenance, SBOMs are cosign attestations, and Semgrep fails closed when on.

Holds · ADR-0005 · ADR-0004

Sound GitOps trust

Each upper cluster runs its own Argo CD and pulls. The GitHub App key stays in one namespace, and a broker mints tokens for one repo at a time.

Holds · glidepath-relay

Observable by design

One OTel trace per flow across separate PipelineRuns, CDEvents throughout, a release state machine fed by Rollout facts, and stall detectors.

Holds · tower/docs/deployments.md

Day-2 tooling in Tower

Plain-language deployment diagnosis, Rollout controls, rollback as a PR, config edits as PRs, and a recorded break-glass shell anchored in Rekor.

Holds · known-gaps.md

A candid engineering record

25 ADRs, a known-gaps log with evidence for each entry, stubs labelled as stubs, and live runs kept apart from render-only checks.

Weaknesses

Gap

Enforcement

  • Required checks and approvals do not block a merge on GitHub Free.
  • Security gates are opt-in and default off. The release SAST gate treats a scan that never ran as a pass.
  • No secret, dependency or license scanning.
Gap

CI flexibility

  • A fixed four-stage graph: no custom steps, no matrix, no conditional jobs.
  • Build images limited to Node, Java, Python and Go, on floating tags.
  • No build secrets or custom build args, so private package registries are out.
  • The dependency cache covers npm, yarn and Maven only.
Gap

Feedback

  • Chained stage results go to Slack, Backstage and Tempo, never to the PR.
  • No test reports, no coverage, no flaky-test handling.
Gap

Lock-in and drift

  • Hardcoded to GitHub, GHCR and a main default branch.
  • The build relies on kaniko, whose upstream project is archived. amd64 Go builds crash under emulation.
  • The guardrail list, the ruleset and the toolbox schema are kept in sync by hand (gap 35 broke every deploy.target user).
Gap

Isolation

  • Test runs copy the app's secrets into the shared testkube namespace, next to developer-written TestWorkflow YAML.
  • Extra .tekton/*.yaml files in an app repo would run as the pipeline identity, outside the platform's control.
Gap

Operations

  • The dev cluster carries Tekton, the broker, release records, DORA and prod's secrets (Figure 2).
  • Tower's per-action authorization is two weeks old and lives in a separate repo.

What to do next, in order

1. Make the gates real before adding features

Move to a GitHub plan that enforces rulesets, or add a pre-merge admission check or merge bot. Generate the ruleset from releaseGuardrails. Fail Flight releases when gate evidence is missing.

2. Close the loop on the PR

Post every chained stage as a GitHub check, parse JUnit and coverage, and fail the test stage when no test exists.

3. Turn on progressive delivery

Scrape ingress metrics, make an analysis with no data fail, ship a default multi-step canary, and start production on staging health instead of PR open.

4. Fill the everyday CI gaps

Glob matching on push, cron and manual triggers, PR path filters, build secrets and args, monorepo support, and a sanctioned custom-step hook.

5. De-risk the platform itself

Split the control plane from the dev workload cluster, give prod its own secrets path, add a CI check that the schema matches the toolbox image, and plan a BuildKit or Buildah replacement for kaniko.

How this was read

I read code, ADRs and docs across glidepath, tower, airframe, apron and hangar. The highest-impact findings (push-branch matching, Testkube secret copying, the always-pass gates, the inert canary, the DORA labels) were checked directly in source. Nothing was run against a cluster; live behaviour comes from the repos' own verification notes.

Glidepath is about two months old, and its September 27, 2026 architecture review withholds production approval. So read the gaps as a roadmap, not a verdict on the design.