Skip to content

Local testing and delivery

Full backend integration mode

From the platform root:

git submodule update --init --recursive
cp .env.example .env
docker compose up --build -d

The local entry point is http://localhost:8080/, with /store/ and /admin/ on that origin. The three frontend services each build from their own Dockerfile and serve their static export with Nginx. This mode uses Gateway/Auth/Account/ Order and the configured real Product/Exchange images. Those last two images are external prerequisites and are not fabricated by frontend initialization.

Use backend images built from the reviewed Gateway/Account commits when testing the new browser endpoints. A submodule pointer does not replace an already published service image. The mainline Compose topology also requires its database/Auth/Order images and their normal environment configuration. The workspace may carry additional local infrastructure work; the frontend review branch deliberately keeps those unrelated commits separate.

The Compose edge uses Docker's DNS resolver and dynamically resolves upstream addresses, so recreated frontend containers do not retain stale routing. This requires the pinned Nginx 1.28 image; see the official upstream documentation. Set DISPLAY_TIME_ZONE before building to choose the display zone. Public frontend values are baked into static exports and require a rebuild to change.

Disposable frontend fixture mode

For UI-only testing without missing backend images, use the separate file:

docker compose -f compose.frontend-demo.yml up --build -d
docker compose -f compose.frontend-demo.yml ps
docker compose -f compose.frontend-demo.yml down

Open http://localhost:8081/, /store/ or /admin/. This dedicated project binds the endpoint to localhost and displays a Local API fixtures notice. FRONTEND_DEMO_PORT can select another local port. Do not combine this file with production deployment or call these fixtures live-service integration evidence.

Only in this fixture mode, use visitor@example.test or admin@example.test with password fixture-only. These are canned test inputs, not real accounts or committed production credentials. Products and orders are disposable in-memory records that reset when the fixture service restarts. The fixture server in tests/frontend/serve.py is test infrastructure, not an application backend, security implementation or substitute for the missing services.

To review already-built exports without Docker:

python3 tests/frontend/serve.py --fixtures --port 4173

The optional Python server is loopback-only by default and requires each app's out/ directory. Docker is the persistent local preview used for handoff.

Frontend repository checks

Use Node.js 24 and npm ci in each repository. The official Next.js and Playwright generators were used. Each app exposes format:check, lint, typecheck, test, test:e2e, build and a local pre-commit configuration that calls the same installed npm tools without downloading hook packages.

CI runs formatting, lint, types, Vitest, static builds and Chromium desktop/mobile Playwright flows. Browser tests use explicit API fixtures; backend tests verify real access-control/session code separately. Landing, Store and Admin became public on 2026-11-09 with the owner's approval. CodeQL runs automatically for public repositories, and the existing workflow was manually dispatched after the visibility change. Earlier private-repository scans were skipped because the organization lacked the required security entitlement; those skipped jobs are not completed scans. ENABLE_CODEQL=true remains an optional opt-in for licensed private repositories if visibility changes again. The image workflow publishes only immutable sha-<commit> tags for local/integration container use. It does not deploy to a CDN or Kubernetes.

Platform Java/CodeQL/EKS workflows still initialize only the backend submodules. Each frontend runs its own checks. All ten Microsserv52 source repositories are public and can be cloned without organization membership; no broader token or permission is needed to read the frontend submodules. Container package access is a separate setting and was not changed.

Before publication, the fetched Git histories and all 76 available Actions logs were checked for credential patterns, with no findings. The three frontends had no repository or inherited Actions secrets, variables, or environments. Their existing workflows perform checks and publish local-test images; they do not deploy to a CDN or cluster. This records the checks performed, not a guarantee that an automated scan can detect every possible secret. GitHub Actions remains enabled; no local services were started for the visibility change.

Real administrator setup

New registrations always receive ROLE_USER. There is no public promote-to-admin endpoint or frontend role-editing control. In an explicitly local/non-production database, an authorized operator may promote a chosen demo account after registration. For example, connect with your local PostgreSQL tooling and use its bound-variable support to set that known account's roles to ROLE_ADMIN. Do not publish credentials or add an automatic production administrator seed. Record the operator action in deployment evidence when real environments are used.

Release and acceptance

  • Review frontend/backend source branches in their owning repositories first.
  • Pin fetchable reviewed submodule commits in the platform; do not pin unpushed local-only commits in a shared integration release.
  • Run real Product/Exchange contract checks, public reads and restricted writes before claiming full backend integration. Confirm order ownership and USD totals.
  • Use verification evidence to distinguish static/unit/fixture checks from production acceptance. Preserve the mock-store notices throughout.
  • Ask the owner about CDN hosting and each app's environment values at deployment time. Agree API origin/cookie path, TLS, cache/404 rules, telemetry policy and rollback together. No frontend Kubernetes deployment is included now.

Record CI runs, app/backend commit IDs, container tags, environment and rollback artifacts in final release evidence. Keep secrets out of docs and public build values. Update the organization profile and disclose AI-assisted source/docs per the course's delivery requirements.