Cheat notes · Module 06 · Product self-service

Onboard a product, declaratively

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

A product team writes one product.yaml; three ApplicationSets turn it into an Argo CD project, a namespace baseline and the workload on every matching cluster. Products name environments; the platform decides which clusters those are.

Remember

Product declaration products/<name>/product.yaml: owner, cost center, repository and path, Pod Security level, and environments with a size each. request: links the onboarding issue.
Environments, not clusters: a product asks for prod; clusters labelled fleet.gitops/environment=prod receive it. A second prod cluster needs no product change.
Three ApplicationSets: product-projects (an AppProject on the hub), product-namespaces (the baseline per environment and cluster), product-apps (the workload, e.g. checkout-dev).
Nested matrix: products × their environments (an elementsYaml list) × the clusters whose label matches. One file in, checkout-dev and checkout-prod out.
The fence: each product's AppProject allows only its own namespace and no cluster-scoped resources.
Ownership is required metadata: every product folder needs a CODEOWNERS line, or fleet_check.py fails.

Pitfalls

Asking for an environment that no cluster provides (staging): fleet_check.py fails and names it. Open an "Add or change a cluster" issue instead.
Forgetting the CODEOWNERS line for a new product: CI fails, because ownership is required.

Commands

`python3 scripts/fleet_check.py`	What the platform will generate from the products
`kubectl --context kind-platform -n argocd get applications -l fleet.gitops/product=checkout`	A product's Applications
`kubectl --context kind-platform -n argocd get appproject checkout -o jsonpath='{.spec.destinations}'`	The product's fence
`kubectl --context kind-prod -n checkout get resourcequota,limitrange,networkpolicy,rolebinding`	The baseline nobody on the team wrote

product.yaml

apiVersion: platform.platformengr.io/v1alpha1
kind: Product
product:
  name: checkout
  owner: team-checkout
  costCenter: cc-4711
  request: https://github.com/YOUR_GITHUB_USER/fleet-gitops/issues/2          # the onboarding issue
  repository: https://github.com/YOUR_GITHUB_USER/fleet-gitops.git           # where the deployment config lives
  path: product-deployments/checkout
  podSecurity: restricted
  environments:
    - environment: dev
      size: small
    - environment: prod
      size: medium

Test yourself

Answer in your head first, then open the answer.

Which file does a product team write to onboard?

products/<name>/product.yaml, plus its own deployment config.

What decides which clusters receive checkout-prod?

Clusters labelled fleet.gitops/environment=prod, from the inventory.

Can checkout's Application create a ClusterRole?

No. Its AppProject allows no cluster-scoped resources and only the checkout namespace.

Why does production-gate wait on an onboarding pull request?

A product declaration can reach prod, so it needs the production approval.

Where module 06 leaves you: checkout runs in dev (6.7.1) and prod (6.7.0, two replicas), each in a namespace with quota, limits, network policies and access rules, inside its own Argo CD project. A pull request for a second product, catalog, is open.