Skip to content

Brazilian Demo Setup Steps

Jump to bottom
Rodrigo Silveira edited this page Sep 24, 2026 · 9 revisions

Credentials

Software Development

Tenant A default default Tenant B: e2e-authz-admin-tenant e2e-authz-admin-tenant

Common test password / recommended temporary password: Local-E2E-Administrator-28D!

Identity Login

Application Administrator admin@example.com
Tenant A Administrator tenant-admin@example.com
Tenant B Administrator e2e-authz-admin-tenant-admin@example.com

Demo

Here are the current Brazilian Demo actor credentials from the Bite 31.5 source:

Actor Email / Login Password Notes
Mariana Alves demo.tenant-admin@example.test Demo-31.4-Brasil! Tenant Administrator
João Ferreira demo31.4.joao@example.test Demo-31.4-Person! Self-service Collaborator
Camila Souza demo31.4.camila@example.test Demo-31.4-Person! Self-service Collaborator
Rafael Lima demo31.4.rafael@example.test Demo-31.4-Person! Self-service Collaborator
Beatriz Nascimento — — Intentionally has no Authentication Account

One important demo detail: during the optional password-reset demonstration, Mariana resets João's password to:

Demo-31.5-Joao!

After that reset, João signs in with:

demo31.4.joao@example.test
Demo-31.5-Joao!

Local environment

Local environment demo

Pre-demo routine would be:

# 1. Stop the existing backend if it is running.

# 2. Reset the demo database.
make brazilian-demo-local-reset

# 3. Verify the deterministic fixture.
make brazilian-demo-local-verify

# 4. Start the backend using the demo database.
ERS_DATABASE_PATH=data/brazilian-demo.db \
make local-backend

Then, separately:

# 5. Start the frontend.
make local-frontend

If you want to pin the scenario to a particular date rather than the default anchor, use:

make brazilian-demo-local-reset \
  BRAZILIAN_DEMO_AS_OF=2026-09-18

For your sales presentations, I would keep the default date unless you have a specific reason to move it. That way the values, Work Period dates, receipt states, balances, and presenter script remain predictable.

Local environment reset for development

For LOCAL, the Brazilian demo database is separate from the normal development database, so you do not need to “undo” the demo database itself.

To return LOCAL to the standard resettable development dataset, use:

# Stop the demo backend/frontend first with Ctrl+C.

# From the repository root:
make testdata-local-reset

# Terminal 1
make local-backend

# Terminal 2
make local-frontend

make testdata-local-reset recreates the normal:

backend/data/app.db

applies all migrations, and loads the standard resettable ERS datasets.

The important distinction is:

Brazilian demo:
backend/data/brazilian-demo.db

Normal LOCAL development:
backend/data/app.db

So when returning from the demo, do not start the backend with:

ERS_DATABASE_PATH=data/brazilian-demo.db make local-backend

Use simply:

make local-backend

If you want to preserve whatever was already in your normal backend/data/app.db rather than reset it, you can skip make testdata-local-reset entirely and just restart with:

make local-backend
make local-frontend
```bash

The Bite 31.5 presenter runbook explicitly notes that the ordinary LOCAL database is separate from the Brazilian demo database, so simply returning to the normal backend command is sufficient unless you specifically want a clean standard dataset.

# Development environment
## Development environment: Run the demo
For a Development demo, the entire database-preparation procedure becomes:

```bash
make brazilian-demo-server-reset ENV=development

Development environment: Restart the server

cd /opt/EnterpriseRemoteSystems/development

ENV=development make testdata-server-reset

make server-backend-health ENV=development
make server-smoke ENV=development

Test environment

Test environment: Run the demo

For Test:

make brazilian-demo-server-reset ENV=test

Test environment: Restart the test server

cd /opt/EnterpriseRemoteSystems/test

ENV=test make testdata-server-reset

make server-backend-health ENV=test
make server-smoke ENV=test

NOTE: Provided we are happy for Test to return to its standard resettable test dataset, rather than preserve whatever ad-hoc Test state existed before the demo.

If preserving the exact pre-demo Test state matters, that exposes one small operational gap in Bite 31.5: we should eventually add a symmetric, safe restore command rather than manually manipulating Docker volumes.

When preserving ad hoc Test state becomes important, the clean next step will be to add a paired backup/restore workflow so the demo process becomes:

Test state before demo
    ↓
Verified backup
    ↓
Brazilian demo reset
    ↓
Presentation
    ↓
Restore exact pre-demo backup
    ↓
Health + smoke verification

That will be much safer than manually copying SQLite files or Docker volumes. Until then, I would leave Bite 31.5 unchanged on that point.

Clone this wiki locally