Teach & navigate
Workshop website · GitHub Pages
Slides, facilitator notes, the flow map, this guide and Discord onboarding. It is static HTML/CSS/JavaScript. It does not write official workshop scores.
Repository: chaicart-cloud-workshop.
A project guide for the facilitator
How ChaiCart fits together.
One learning story, three sites. Students build a fictional chai startup on Day 1, then learn how to keep it alive on Day 2. The sites support different parts of that experience.
Remember three rules: teach from the workshop site; collect answers and official credits in Live; demonstrate orders, failures and recovery in Azure. A student architecture is a learning design—it does not automatically provision Azure resources.
1. Three sites, three responsibilities
Participate & score
ChaiCart Live · Firebase Hosting
Google sign-in, team membership, answers, captain reviews, the credit ledger, networking and certificates. React talks to Firebase Auth and Firestore.
Repository: chaicart-live.
Demonstrate & recover
ChaiCart Demo · Azure App Service
A storefront and Node.js backend with simulated payment, fulfillment, outages and recovery. Real HTTP requests; simulated business dependencies.
Folder: chaicart-cloud-workshop/chaicart-demo.
Live and the demo use the same Firebase identity project and facilitator admin list. Their student/session data and demo orders are separate. Each site may still ask you to sign in on its own domain.
2. Who does what?
There are 120 student places: 24 teams of five, arranged into four regions of six teams. Each team starts with 1,000 Cloud Credits.
| Person | Responsibility | What they control |
|---|---|---|
| Facilitator | Runs the room and judges final outcomes. | Creates sessions, assigns captains, launches/locks/reveals activities, applies awards, releases certificates. |
| Regional captain | Supports and reviews six teams in one region. | Shares generated team codes, checks evidence, reviews and awards credits within the assigned region, and shortlists X entries. |
| CEO | Decisions and presentation. | Team pitches and Demo Day; Plan stage in Factory round 2. |
| CTO | Architecture and technology choices. | Leads design discussion; Build stage in Factory round 2. |
| CFO | Cloud cost and credits. | Leads cost decisions and watches the ledger; does not gain staff scoring permissions. |
| SRE | Reliability and recovery. | Leads incident discussion; Test stage in Factory round 2. |
| COO | Time and shared submissions. | Submits scored team answers and votes; Deploy stage in Factory round 2. |
Team roles are not staff access. A CEO is still a student. Captains are assigned staff accounts for a specific session and region. Everyone submits their own polls, surveys, networking completion and personal plan. Assigned station volunteers advance their own station tickets.
3. Follow one activity from launch to credits
- Prepare: facilitator creates a session in Live Setup, sets the workshop date and assigns captain emails to regions. Team codes are generated by session creation.
- Join: students use the session QR/code, sign in with Google, enter the captain’s team code and claim one available role. Five roles reserve five places atomically.
- Launch: facilitator chooses an activity in Run and clicks Launch on phones. Selecting the activity alone is only a preview. Set the timer and projector view.
- Respond: phones follow the session’s current activity. The COO submits team work after discussion; individual activities stay individual. Firestore rules enforce identity, role, activity, phase and allowed answer shape.
- Review: for reviewed activities, the captain checks the submission and saves Approve for facilitator, proposed credits and feedback. Students can see their team’s feedback.
- Apply: captain uses Award reviewed credits to team, or the facilitator uses Workshop → Apply once. A Firestore transaction appends ledger entries, updates the leaderboard and marks the award as applied. Listener updates reach student phones and the projector.
- Move on: lock submissions, reveal when appropriate, then End. Phones wait until the next launch.
Three finish paths—and why points may be missing
- Reviewed: timeline, sorting, architecture, networking and other rubric-based work go through captain review and captain or facilitator application.
- Panel-scored: the facilitator’s quiz, mystery, Poker, Bill Shock and vote panels have their own scoring/apply actions. Quizzes need Reveal and score; a stored answer alone does not add credits.
- Unscored: polls, surveys, career plans and demo orders collect learning evidence, not workshop credits.
Use one scoring path per award. Networking can earn +100 for each completed team activity, at most +300 across LinkedIn, GitHub and X. Cloud or Not earns +100 per correct participant, added to their team. Recap quiz team answers earn +10 when correct. Individual post/photo awards are separate from team credits.
Corrections append compensating ledger entries; they do not erase history. A cached draft or pending write is not a confirmed submission.
Session codes, team codes and phases
Session code: selects the whole workshop session. Team code: admits a student to a particular team. Captains share existing generated codes; they do not create them.
Open permits the activity’s allowed submissions. Locked stops submissions. Revealed exposes the released result. End clears the active activity so phones wait. The projector can show join QR, leaderboard or the current activity.
4. The two-day learning journey
Use the activity-by-activity flow map for exact timings, buttons, rubrics and handoffs. This is the sequence to remember.
Before Day 1: make joining easy
Share Discord onboarding and QR invites with everyone. Prepare Live’s session and captain assignments, open the deck and projector, and test venue Wi-Fi and Google sign-in. Captains distribute team codes. The detailed facilitator guide holds the preparation checklist.
Day 1: build the startup
- Open: pre-survey, roles, LinkedIn networking and Cloud or Not? individual quiz.
- Understand cloud: Human Timeline, service-model sorting and deployment debate.
- Make a case: Shark Tank pitch and regional vote.
- Build vocabulary: GitHub networking, Bingo, VMs/containers and the Azure demonstration.
- Design: Architecture Lego on phones, including components, request flow and reasoning. Captains review; facilitator freezes approved designs for Day 2.
- Practice handoffs: Human Kitchen volunteers use digital station tickets; teams add Gallery Walk feedback.
- Close: recap quiz, ledger check and handover. Official answers and credits remain in Live.
Day 2: keep it alive
- Reconnect: X networking, reliability discussion and Guess the Downtime.
- Investigate: Who Killed Checkout? evidence, hints and accusation; Observability Treasure Hunt with proof.
- Choose risk: Error Budget Poker uses staff-issued rolls and the frozen architecture.
- Improve delivery: blameless postmortem and Digital Delivery Factory. Factory replaces paper planes: three-minute serial COO round, then a CEO → CTO → SRE → COO pipeline.
- Control cost: security, scale and Bill Shock use the team’s design decisions.
- Connect business systems: Follow the Order uses assigned station volunteers and order tickets.
- Close: careers and personal 90-day plan, quiz, Demo Day vote, post-survey, awards and certificate release. X posts/photos can run throughout the day with #ChaiCartCloudWorkshop; submit the best public link before awards.
Factory metrics are teaching proxies for DORA; failed tests are not automatically real production incidents. Student design choices affect learning games, not a deployment of their own cloud resources.
5. What happens when someone orders chai?
- Customer signs in with Google, selects a city and adds chai, coffee or snacks to the cart.
- The storefront sends
POST /api/checkoutwith a Firebase identity token. The Node backend verifies identity, validates items and quantities, and calculates prices plus delivery. - The simulated payment stage acquires a slot from an in-memory pool. Logical database and gateway stages run; their dependencies are simulated.
- On success, an order and fulfillment events are persisted in
DATA_DIR/state.json. CRM, SCM, HCM, BI and ERP events represent business-system handoffs. - The response returns the order ID and receipt. The signed-in owner can view history and fetch
/api/orders/{id}. Demo delivery advances over 30 seconds; the displayed promise is 10 minutes.
What the facilitator can break—and restore
- Pool exhaustion: capacity drops from 50 to 5. Waiting checkout requests can time out; this is an in-memory pool demonstration, not a deployed PostgreSQL incident.
- Gateway outage: simulated payment fails and checkout returns an error.
- ERP pause: ERP events queue while other handoffs continue. Restore healthy service to replay queued invoice events.
- Surge: generate controlled demo traffic, observe impact, stop new traffic and restore healthy service.
These controls live at the Azure app’s facilitator page, not Live’s scoring console. Demo orders never add student credits. The app is a teaching system, not production commerce or independent microservices.
6. Where does the data live?
| Location | What it holds | Important boundary |
|---|---|---|
| GitHub Pages files | Slides, notes, QR assets and illustrations. | Static practice quiz/leaderboard pages are reference tools, not the official ledger. |
| Firebase Auth | Google identities used by Live and demo sign-in. | Identity does not automatically grant staff permissions. |
| Firestore | Session state, team reservations, students, submissions, reviews, ledger, leaderboard, designs, tickets and awards. | Rules enforce team/role/region access and protect unreleased answer keys. |
| Browser storage | Cached data, current session and drafts. | Helps with short Wi-Fi interruptions; is not proof that the server accepted a final answer. |
| Azure demo state file | Demo orders and business-system events. | Separate from student scores; file/in-memory design is not a distributed production database. |
Read the Firestore structure
admins/{email} authorizes facilitators. sessions/{session}/staff/{email} assigns regional captains. Students and team role slots belong to that session.
submissions holds answers; reviews holds proposals; ledger records official changes; public/leaderboard supplies the current scores. Private application markers prevent duplicate awards. Protected keys and private responses are not public projector data.
Live mostly talks directly to Firestore through the SDK and rules. It does not send workshop answers through the Azure Node server. Firebase Functions provide the protected telemetry gateway, staff scoring actions and recursive session deletion. Azure remains the separate order demo backend.
How permissions differ
Students use a verified Google identity and session/team membership. Team answers are COO-controlled; private surveys and plans stay individual. Captains are restricted to their assigned region. Facilitators are on the shared admin allowlist. The Azure server verifies Firebase tokens and facilitator access itself.
Firebase public web configuration belongs in browser configuration. Service-account credentials and telemetry ingestion tokens belong in protected server settings, never in public pages or generated illustrations.
7. Find the code you need
| Change | Repository / source |
|---|---|
| Teaching and run of show | chaicart-cloud-workshop: day1-slides.html, day2-slides.html, facilitator-guide.html, workshop-flow.html. |
| Workshop appearance | assets/deck.css, assets/screen.css, assets/print.css; deck navigation in assets/deck.js. |
| Student activities and text | chaicart-live: src/content/activities.ts, src/content/workshop.ts, src/pages/student/. |
| Joining and roles | src/pages/Join.tsx, src/lib/membership.ts, src/lib/auth.ts, firestore.rules. |
| Staff controls and scoring | src/console/, src/pages/Captain.tsx, src/lib/session.ts, src/lib/credits.ts. |
| Demo storefront or scenarios | chaicart-cloud-workshop/chaicart-demo/public/, server.js, auth.js, telemetry.js. |
How changes reach the sites
Workshop: push the workshop repo to main; GitHub Actions assembles and deploys the static Pages site.
Live: build the React app with production Firebase configuration and deploy Firebase Hosting. Rules and Functions are separate deployment components; update them deliberately when their source changes.
Azure: deploy the demo folder and production dependencies to the existing App Service. Preserve its protected configuration and order storage. The repository’s Azure deploy job is conditional; pushing teaching pages alone is not an Azure release.
Use the repo tests and deployment notes before release. Browser tests with synthetic fixtures demonstrate layout; they do not replace a real-account rehearsal.
Where observability fits
Dynatrace RUM covers browser behavior. The Azure Node app exports OpenTelemetry logs, metrics and traces. Live instruments Firebase SDK operations and forwards approved telemetry through its protected Function. This observes the experience; it does not create activity scores.
Logical demo service spans are not proof of separate deployed services. Infrastructure monitoring and alert setup remain distinct. Read the observability runbook for those details.
8. Rehearse one complete loop first
- Open the workshop flow map and Day 1 deck on the presenter’s machine.
- Open Live Console privately; create/select a rehearsal session, assign one captain and show the join QR on Screen.
- Join with a student Google account and team code. Launch one activity, submit, review as captain, apply as facilitator, then confirm the ledger and projector agree.
- Try one individual poll and one panel-scored quiz so you see all finish paths.
- Open the Azure storefront, place a simulated order, inspect its receipt, introduce one failure and restore healthy service.
- Check certificate release and invite participants to keep asking questions in Discord.
For the whole room, use the flow map. For exact preparation and judging, use the facilitator guide. This illustrated page explains why the pieces fit together.