Lesson 5 · This repo's local dev

The env × org model

The single idea that organises the entire deployments/ stack — a matrix of environment × organisation.

Your win: explain what env and org mean here, how the pair maps to a Kubernetes namespace and a values file, and why this matrix reappears in every remaining course.

Two axes, not one

Most companies deploy along one axis: environments (dev → staging → prod). This repo has a second axis, because it's multi-tenant — it runs the same product for several separate customer organisations. So every deployment is identified by a pair:

Every running copy of the backend is one (env, org) cell of that grid — prod × tokyo, stag × jprep, and, on your laptop, local × manabie.

The one formula to remember A cell maps to a Kubernetes namespace by a fixed template:
namespace = {ENV}-{ORG}-backend
So local × manabie → local-manabie-backend — the exact namespace you saw sk.bash default to in Lesson 4's map.
Anchor — where the formula lives It's literal in the Helm/Skaffold config: deployments/helm/backend/bob/skaffold.yaml:10 sets namespace: '{{.ENV}}-{{.ORG}}-backend'. And the local defaults are set in deployments/env.bash:19-48: env="local", org="manabie", server_image_tag=locally, NAMESPACE=backend — with a nice safety detail on line 39: if you target prod/dorp without naming an org, it refuses to guess and defaults to tokyo explicitly rather than silently.

Where the per-cell config comes from — values files

The code is identical across every cell (one image, Lesson 2). What differs is configuration: URLs, feature flags, resource sizes, which tenant's data. That lives in one values file per cell, named {env}-{org}-values.yaml.

Anchor — one file per cell List deployments/helm/backend/bob/ and you'll see the grid on disk: local-manabie-values.yaml, stag-jprep-values.yaml, prod-tokyo-values.yaml, dorp-aic-values.yaml, prod-renseikai-values.yaml, … one per (env, org). These are Helm values — you'll learn exactly how they layer onto a chart in Course 3 (Helm). For now: same chart, different values, different cell.
org → manabie jprep tokyo aic ... env ↓ ┌────────────┬───────────┬───────────┬──────────┐ local │ local- │ │ │ │ ← your laptop │ manabie │ │ │ │ stag │ │ stag- │ │ │ │ │ jprep │ │ │ prod │ │ │ prod- │ prod- │ │ │ │ tokyo │ aic │ └────────────┴───────────┴───────────┴──────────┘ each cell = one namespace ({env}-{org}-backend) + one values file
Why you care, as a backend dev Your code must not assume a single tenant or a single environment. Anything tenant- or env-specific comes in through config (env vars / values), never hard-coded — the same principle as Lesson 3's env vars, scaled to an org chart. This is also why "it works on local-manabie" doesn't prove it works on prod-jprep.
Read this next

In-repo: the values grid + the namespace template

The authoritative source here is the repo itself — read the filenames and the template. (External Helm/K8s namespace theory arrives in Courses 2–3.)

→ deployments/helm/backend/bob/ (the {env}-{org}-values.yaml grid)
→ deployments/helm/backend/bob/skaffold.yaml:10 · deployments/env.bash:19-48
→ reference/repo-containers-map.md §5

Check yourself (from memory)

Q1. A single running copy of the backend is identified by…

Two axes: env (local/stag/prod/…) × org (manabie/jprep/…). Each cell is one deployment.

Q2. The local × manabie cell maps to the namespace…

The template is {ENV}-{ORG}-backend, so env first, then org, then -backend.

Q3. What differs between two cells running the same service?

Same code/image everywhere; each cell has its own {env}-{org}-values.yaml. Config differs, code doesn't.
Explain this repo's env × org model — the axes, the namespace, the config.
recall, then click to reveal
Two axes because the product is MULTI-TENANT: ENV (local, stag, uat, dorp, prod, trial) × ORG/customer (manabie, jprep, tokyo, aic, …). Each (env, org) CELL is one deployment. NAMESPACE = {ENV}-{ORG}-backend (repo: bob/skaffold.yaml:10) — e.g. local-manabie-backend, the local default (env.bash: env=local, org=manabie, tag=locally). Same IMAGE/code in every cell; per-cell CONFIG lives in {env}-{org}-values.yaml (Helm values, Course 3). Backend code must never hard-code tenant/env — it comes through config. This matrix organises Helm, CI/CD and Terraform too.
Want to see how dorp differs from prod, or why some orgs exist only in some envs? Ask me.

1. In-repo: deployments/helm/backend/bob/skaffold.yaml:10, deployments/env.bash:19-48, and the {env}-{org}-values.yaml files under deployments/helm/backend/<svc>/.