Skip to content

How we put WorkWingman live (simple version)

WorkWingman is the job-search copilot. The cloud version lives on Google’s hosting (Cloud Run) and sits behind Cloudflare. This page is for family teammates who are not engineers. It explains the release rules we learned the hard way on 2026-07-30.

The shipping rule in one picture

Think of shipping like a restaurant kitchen:

  1. Cook only from a clean, labeled recipe card — one exact version of the code, on a clean workspace nobody else is editing. Once, someone almost served food that had another cook’s unfinished prep still on the counter.
  2. Label every plate with a permanent name — we use the code’s fingerprint (sha-<commit>). We banned reusable labels like “v2.” A reusable label once poured old soup into new bowls.
  3. Serve the exact plate, not the label on the shelf — we point live traffic at the food’s unique seal (the image digest), not a sticky note that can be reused.
  4. Check the seasoning list before guests eat — compare the settings we say we want with what’s actually on the live service. A cleanup script once wiped seven live reader settings (a real scare).
  5. New plate sits at table 0% first — put the new version online with zero customers, check it, then walk people over on purpose. “Ready in the kitchen” and “customers are eating this” are different. Check both.
  6. Taste the dish, don’t just see the plate — look for something unique inside (for example a known link shape), not only “the website loads.”
  7. If the kitchen fails a check, stop — scripts must report failure out loud. Quiet failures once rolled us back without anyone noticing.
  8. Don’t tape the dining room to one old table forever — locking all guests to one fixed version makes every future plate sit empty. After an emergency lock, announce it and open seating to the latest again. Emergencies are loud, never silent.

Seven ways things went wrong (one hard day)

  1. Mystery plates — a revision showed up with no clear owner; production served roughly a day-old version.
  2. Sticky labels that lie — old “v2”-style tags could hand out stale code with no active cook still publishing them.
  3. Traffic moves hurt more than cooking — locking guests to one revision silenced every later deploy.
  4. Hidden spice racks — live settings that weren’t written down only showed up when we tried to ship.
  5. Finish order races — a teammate’s merge shipped a build that still had a bug someone else had already fixed.
  6. Tests that cheer for nothing — a test “passed” by doing nothing useful on bad sample data; green light, no real measurement.
  7. Stale victory claims — “we’re good” can die when the code commit, the built image, or the page content each move on their own. Track all three.

What’s next (FLT-182)

A small per-app release helper. The two highest-value locks:

  1. Prove where the build came from before it can ship.
  2. Gate who can claim traffic so nobody quietly pins or unpins production.

Keep the facts easy to see so people don’t guess one step past what we know.