Skip to main content

Onboard a Client — never a fork

:::danger The one rule A client is a Client/Account field value (+ per-client Versions) and config + data — never a code fork, never a project-per-client. One shared app serves every client; they differ by configuration and their own data/deployment. :::

1. Jira & records​

  • Add the client as a Client/Account field value on the app's project — not a new Jira project.
  • Track their delivery with per-client Versions and/or a swimlane, on the app's existing board.
  • Customer-facing support lives in JSM (Clustersco Support), routed by Product to queues/SLAs — never on the dev board. Incidents link to dev Bugs via is caused by.

2. Deployment (if they run a dedicated instance)​

Deploy the standard image — do not build a client-specific image. The client differs only by config + data:

# per-client Swarm stack from the SAME published image, pinned to a version:
docker stack deploy -c docker-stack.yml bgvchecker_<client>
# config via env vars only: CLIENT=<client>, APP_BASE_URL, DB_* (secrets from the runtime store)

Pin the client to a specific clustersco/<app>:<ver> and upgrade them on your schedule. Persistent volumes and DB are per client (isolation); the code is shared.

3. If a client is stuck on an old version​

A client who can't take the current release yet but needs a fix is a support/<x.y> branch (cut from the old tag, PATCH-only, forward-ported) — still not a fork. See the Git & Versioning Workflow.

Anti-patterns​

  • ❌ Forking the app repo per client · ❌ a Jira project per client · ❌ a client-specific image build
  • ✅ One codebase + a Client/Account value + per-client config/data/deployment + (rarely) a support line