Process · 04 of 07 · Onboarding

Getting a new app onto the platform

Onboarding is where a platform shows whether it is a product. Here, the developer makes one choice, and each following step is a reviewed commit the platform makes on their behalf.

Getting a new app onto the platform Six-step process. The developer picks an app stack in Tower. Airframe scaffolds the source repo, Dockerfile and a starter cicd.yaml, then commits the app's identity file. ArgoCD's tenant-onboarding ApplicationSet reads it and renders the tenant: namespaces, RBAC, the Pipelines-as-Code Repository and the chaining Triggers. Glidepath delivers the generated .tekton boilerplate, and the developer's first push runs build, test and deploy to dev. Installing the platform GitHub App on the repo is the one manual, one-time step. TOWER AND AIRFRAME · SELF-SERVICEARGOCD AND GLIDEPATH · AUTOMATIC1 · YOUPick a stack in TowerNode · Go · Java · Python2 · AIRFRAMERepos scaffoldedsrc · Dockerfile · cicd.yaml3 · AIRFRAMEIdentity committedtenants/<app>/identity.yaml4 · ARGOCDTenant renderednamespaces · RBAC · PaC · Triggers5 · GLIDEPATH.tekton deliveredboilerplate, never hand-edited6 · YOUFirst push runsbuild · test · deploy to devAPPLICATIONSET READS ITNEEDED FOR 5Install the GitHub Appthe one manual stepNo command to run and no pipeline YAML to write. Every step is a commit someone can review.LEGENDYouAutomaticManual, one time

Principle honored

Backstage holds no Kubernetes credentials. Even creating a new app is a git commit, not an API call.

What changes

  • The identity file is written by the platform, never by the app repo, so a developer's commit cannot redirect a release.
  • The execution namespace is computed as <type>-<app>-cicd, so it cannot drift.

Found in use

A private gitops repo needs the GitHub App installed on it too, or delivery to it fails: found live, and now in the docs.

Hangar · Glidepath