Document, Publish and Ship to Production

6.v1.0.0

A

In this chapter

Anna finishes her project like a professional — a proper README, a public GitHub repository checked for secrets, a development workflow that deploys from main, and a tagged v1.0.0 production release — then demos it at Hack Day. Reviewing Acts 15, 16, 18, 19 and 24 one last time in her own work.

14–16 min

The Problem in Real Life

2:00 PM. Demos start at 4. Anna could add another feature. Instead she remembers Act 25 — Mark's repo, and the hour she lost to an outdated .env.sample. "Two hours left," she says. "I'm spending them on making this usable by someone who isn't me."

John, passing with his clipboard, makes another mark. He doesn't say what it means.

A

A project nobody else can run isn't finished.

Anna

"It Works for Me" vs. Something Others Can Use, Run and Trust

Nobody knows what it is

Without a README, visitors leave a repository within seconds.

Public means public

Making a repo public exposes its whole history — including any secret ever committed.

How do changes get to production?

Without a defined workflow, the next change goes out by hand — and Act 19 happens again.

Documentation, a README, GitHub, a Development Workflow and a Production Release

The shop-opening analogy: before opening day, a good shop owner writes the sign on the door (what we sell, opening hours), a staff handbook (how to open up, how to close, what to do if the till breaks), checks the locks one more time, and then holds a proper opening. Shipping a project is the same.

  • The README — the sign on the door (Acts 16, 24, 25): what it is (one sentence and a screenshot); the live link; features; the tech stack; how to run it locally (exact commands — docker compose up, migrations, seed data); the environment variables (names only, with .env.example); how to run tests; the API endpoints; the folder map; and known limitations and next ideas. She writes it, then follows it herself on a fresh clone to prove it works.
  • Other documentation (Act 24): .env.example with every real variable (checked against the code, Act 25), short comments where the "why" isn't obvious (the unique constraint, the position query), and a docs/decisions.md with two short decision records: why sessions instead of JWTs, why positions are calculated rather than stored.
  • A public GitHub repository — check before you publish (Acts 15, 22): before making the repository public, she checks the whole history, not just the current files: secret scanning, a search of git log -p for anything like a key or password, and confirms .env was ignored from the first commit. (If a secret had ever been committed: rotate it first, then clean history — Act 22.) She adds a licence and a short description.
  • A development workflow — how changes reach production (Acts 15, 18, 19): main is protected: changes arrive through pull requests (yes, even from herself) that must pass CI. Merging to main builds the image and deploys it automatically, with migrations and a health check. Rollback means redeploying the previous image. She writes this in the README too.
  • A production release (Act 18): she tags the first release v1.0.0 (Act 16's semantic versioning) with short release notes: what it does, how to use it, what's next. From now on, a new feature means a new MINOR version, a fix a PATCH.
Table — Anna's README, section by section
SectionContent
What it isEvent waitlists: organisers create events, fans join and see their position
Live demohttps://waitlist.anna-builds.example
StackNode.js 20, Express, PostgreSQL, Docker, GitHub Actions
Run locallydocker compose up · npm run migrate · npm run seed
Environment variablesDATABASE_URL, SESSION_SECRET, LOG_LEVEL (see .env.example)
Testsnpm test (unit + integration, needs Docker)
APISix endpoints with examples
DeploymentMerge to main → CI → image → deploy; rollback = previous image
Limitations / nextNo email notifications yet; no admin UI
Table — Every step of Hack Day, and where it was learned
StepActs
Warm-ups: CLI calculator, file organiser06, 07, 08
REST API + database + CRUD12, 13, 23
Authentication and authorization22
Git workflow and tests15, 17
Container, deploy, domain, HTTPS12, 19, 20, 21
Logging and monitoring17, 19, 21
README, GitHub, workflow, release16, 18, 24, 25
Before going public, and the first release
git log -p | grep -iE "secret|password|api[_-]?key|sk_live" # search ALL history, not just today
git ls-files | grep -E "^\.env$" # must print nothing
git switch main && git pull
git tag v1.0.0 -m "Event Waitlist v1.0.0 — first production release"
git push origin v1.0.0

4:30 PM — the demo: Anna shares her screen. She shows the live app on her phone — "You are #42 in line" — then the README, then the CI checks on her last pull request, then the error tracker, then the v1.0.0 release. She breaks one thing on purpose (stops the database), shows the uptime alert arriving on her phone, and fixes it. Then she says the sentence she's been practising: "Everything in this project is something I learned this year."

The close: the judges confer. John doesn't announce a winner straight away. He walks over and shows her the clipboard: every step she took has a tick next to it, plus one note at the bottom — "Act 04: couldn't run node. Act 27: built and shipped this, alone." Samantha reads it over his shoulder and asks whether the waitlist could become a real BlueTicket feature. Anna grins. "Give me a sprint."

Key Takeaway

Finish a project so others can use, run and trust it: a README with what it is, the live link, the stack, exact local setup, environment variables, tests, endpoints and limitations — verified on a fresh clone; a complete .env.example and short decision records; a public repository checked for secrets across its whole history; a protected main branch where PRs must pass CI and merging deploys automatically; and a tagged v1.0.0 release with notes.

Why This Matters

A finished, documented, deployed project with a real Git history, tests, CI and a release is the single strongest thing a beginner can show an employer — proof that you can take something from an empty folder to production on your own. And the habits of finishing well are the ones teams value most.

Hack Day is over, and Anna has something she never had a year ago: proof — to herself and to anyone — that she can build software from nothing. One question remains, and John asks it over the last slice of pizza: "So. What do you want to do next?"

Next