Dev lifecycle

Environments — local, staging, production

Software lives in three places at once. Same code, three contexts:

Local (your laptop)

Where you write and test code. Fast feedback. Real database connections, but to a tiny dev database. No real users.

Staging (a server, sometimes called "preview" or "dev")

A live deployment that mirrors production. Used for QA, demos, and "does this actually work end-to-end before we ship it." Often gets a copy of production data with sensitive fields scrubbed.

Production (the live site)

Where real users hit real code on a real database. Mistakes here are visible. Changes go through the most rigor.

The trip from local → staging → production is the central ritual of professional software. Every concept in this level is part of that trip.

Git — the time machine

Git is the version control system. It tracks every change to every file in your project, lets you go back in time, and lets multiple people work on the same code without overwriting each other. Linus Torvalds wrote it for Linux kernel development; everyone else adopted it because nothing else came close.

You don't need to know Git deeply to be fluent in the workflow. You need to recognize these nouns:

The GitHub flow — the workflow used everywhere

Most teams use a workflow called GitHub flow (regardless of whether they're on GitHub, GitLab, or Bitbucket). It's almost embarrassingly simple, which is the point:

1. Cut a branch off main

   Name it for what it does — feature/magic-link-login, fix/empty-state-overflow, chore/upgrade-prisma. Never work directly on main.

2. Make commits

   Small, focused commits with messages that explain why, not what. "Add login form" is bad — the diff already says that. "Use magic links instead of passwords because users pick bad ones" is good.

3. Push the branch and open a pull request

   The PR is the conversation. It has a title, a description, the diff, and a discussion. Reviewers leave comments inline on specific lines.

4. CI runs

   Tests, linters, type checks, sometimes preview deploys. Green = mergeable. Red = something you have to fix or explain.

5. Review, address feedback, merge

   Reviewer says LGTM ("looks good to me") or requests changes. You iterate. When approved, you (or the system) merge to main.

6. Delete the branch

   Once merged, the branch's job is done. GitHub does this automatically by default. The history lives on in main.

Pull requests & code review

The pull request (PR) — sometimes called a merge request on GitLab — is where most professional software-engineering culture lives. It's where standards are upheld, knowledge spreads, and bad ideas get caught before they ship.

Anatomy of a good PR:

• A clear title. "Switch login to magic links" — a sentence anyone could understand.
• A description. What changed, why, how to test it. Screenshots if it's UI. Links to the ticket or PRD.
• A focused diff. One logical change. Big PRs are reviewed worse than small ones — every reviewer knows this.
• Green CI. All checks passing.
• Self-review. Many engineers leave their own comments on their own diff explaining "I did it this way because…" — saves the reviewer's time.

What reviewers actually look for, in order:

1. Does it do the thing? The PR description says "fixes X." Does the diff actually fix X?
2. Is it correct? Edge cases, off-by-one errors, security holes, race conditions.
3. Is it readable? A future engineer (or future-you) will read this in six months knowing nothing.
4. Does it fit the codebase? Same patterns, same naming, same conventions.

CI / CD — the automation belt

CI is continuous integration. CD is continuous delivery (or deployment). Together they're the conveyor belt that runs every time you push code: tests, type checks, lint, build, deploy.

Tooling you'll meet:

• GitHub Actions — workflows defined as YAML files in .github/workflows/. The default for projects on GitHub.
• GitLab CI — equivalent for GitLab, defined in .gitlab-ci.yml.
• CircleCI, Travis, Jenkins — older or specialized; used widely in larger orgs.
• Platform-built-in CI — Vercel, Netlify, Cloudflare Pages, Render all run their own pipeline on every push. For static and frontend projects, you may not need GitHub Actions at all.

Hosting platforms — where your app actually runs

You wrote the code. Where does it run? Until ~2015, the answer was "a server you rent and configure yourself." Today, for almost any new project, the answer is "a managed platform." You hand them a Git repo; they handle servers, scaling, SSL, CDN, deploys.

The platforms you'll hear named, and what each is for:

For a non-technical builder shipping a real app today, the practical default is Cloudflare Pages or Vercel for anything frontend-heavy, and Render or Railway for anything that needs a long-running backend with a database. AWS is what you graduate to when you absolutely must — and most projects never absolutely must.

DNS, domains, SSL — the address layer

You bought a domain — tasklane.example. Someone types it into a browser. How does the browser know which server to ask?

DNS (Domain Name System) is the internet's phone book. Domain names map to IP addresses (the actual numeric addresses computers use). You configure DNS records at your domain registrar (Cloudflare, Namecheap, Google Domains) telling the world: "tasklane.example lives at 76.76.21.21."

The records you'll meet:

A record

Maps a domain to an IPv4 address. tasklane.example → 76.76.21.21.

CNAME record

"This domain is an alias for that domain." Used when your hosting platform has its own canonical URL. www.tasklane.example → tasklane.pages.dev.

MX record

"Email for this domain goes to this server." Set this if you want hi@tasklane.example to work.

TXT record

Arbitrary text — used for verification ("prove you own this domain"), email security (SPF, DKIM), and other proofs.

SSL (the lock icon, also called TLS) is what makes the URL https:// instead of http://. Every modern hosting platform does this for free, automatically, via Let's Encrypt. You'll basically never have to think about it — but if you ever see "your connection is not private" in a browser, the certificate is broken or expired.

CDN — what it actually does

A CDN (content delivery network) is a global mesh of servers that hold cached copies of your site. When a user in Tokyo visits, they hit a Tokyo CDN node, not your original server in Virginia. Result: dramatically faster pages, lower load on your origin, resilience to traffic spikes.

Cloudflare, Fastly, and Akamai are the big general-purpose CDNs. Vercel, Netlify, and Cloudflare Pages have CDN built in by default — your static assets are automatically served from the edge.

The vocabulary:

• Cache hit — the edge already has the content. Fast.
• Cache miss — the edge has to fetch from origin. Slower the first time.
• Cache invalidation — you changed the file; the edges need to know. Most platforms do this automatically on deploy.
• Edge — the global mesh of CDN nodes. "Run at the edge" means run there, not at origin.

Wrap-up