diff --git a/public/from-code-to-production/index.html b/public/from-code-to-production/index.html new file mode 100644 index 0000000..2922394 --- /dev/null +++ b/public/from-code-to-production/index.html @@ -0,0 +1,339 @@ + + + + + +From Code to Production | Dev Weekends + + + + + +
Use arrow keys
+ +
+
+
+
Dev WeekendsThink Like an Engineer
+
Engineering series

From Code
to Production

Merged is not shipped, and shipped is not done. The path your code takes after you press commit.

+
resources.devweekends.com
+
+ +
+
The JourneySix gates
+
What this talk covers
+

Six gates between
your laptop and users

+
01
Merge
Tests, contracts and review stop bad code at the door.
Before merge
02
Build
One artifact, tested once, deployed as is.
Before deploy
03
Deploy
Roll out in a way that limits the blast radius.
Strategy
04
Observe
Compare against a baseline while it rolls out.
During deploy
05
Recover
A rollback you have actually practiced.
When it breaks
06
Learn
Turn every incident into a stronger system.
After
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/overview
+
+ +
+
Act OneBefore You Merge
+
Quality gates

Merge is a
checkpoint

Code that enters main should already be safe to deploy.

+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/testing-logging-versioning
+
+ +
+
Before MergeThe PR gate
+
Gate one

If a check fails,
code stays out

The production readiness checklist starts at the pull request. Each item exists for a reason you can explain.

01
Unit and integration testsEdge cases covered. Queries verified against real infrastructure with Testcontainers.
02
Contract testsAny API response or event schema change is checked against its consumers.
03
Rollback-safe migrationsThe previous app version must still run against the new database.
04
Flag tests cover both statesFlag on and flag off are each tested.
05
No PII in logsStructured, typed events instead of raw object dumps.
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/testing-logging-versioning
+
+ +
+
Case StudyKnight Capital
+
1 August 2012
+

What a missed
server costs

+

Knight Capital deployed new trading software to seven of eight production servers. The eighth still ran old code, and a reused feature flag woke it up.

+
$440M
Lost in one morning
45 min
From the first bad trade to the loss
7 of 8
Servers updated. One was missed.
0
Kill switches to halt the trading
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/testing-logging-versioning
+
+ +
+
Case StudyWhat was missing
+
Knight Capital, in hindsight
+

Four cheap things
that were absent

+
01
A version check
No test verified that all eight servers ran the same software.
Testing
02
Automated deploys
A script, not a person, should make every server identical.
Deployment
03
Gradual rollout
No canary or rolling deploy limited who was exposed.
Strategy
04
A kill switch
Nothing could halt trading when the numbers looked wrong.
Monitoring
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/testing-logging-versioning
+
+ +
+
Act TwoDeploy
+
Reduce the blast radius

Deploy
without drama

Choose how the new version meets real traffic.

+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
Two IdeasDeploy vs release
+
Why the difference matters
+

Shipping code is not
the same as releasing

+
Deployment
Code is on servers
01A technical event your team controls.
02Can happen many times a day.
03Safe when the new code stays dormant.
Release
Users see it
01A product decision, switched on by a feature flag.
02Turn it on for a few users first.
03Turn it off without a new deploy.
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
StrategiesPick on purpose
+
Three ways to roll out
+

Rolling, blue-green
or canary

+
01
Rolling
Replace instances a few at a time. Built into most orchestrators. Rollback is slow.
Routine, low-risk changes
02
Blue-green
Run a full second environment, then switch traffic at once. Rollback is instant but costs double infrastructure.
Major releases, strict compliance
03
Canary
Send a small share of real traffic to the new version first. Catches production-only bugs. Needs strong metrics.
High-traffic systems, unknown risk
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
DatabasesExpand and contract
+
Zero-downtime migrations

Change the schema
in small steps

Old and new code run side by side during a deploy, so the database must work for both.

01
ExpandAdd the new column or table. Nothing reads it yet.
02
MigrateBackfill in batches and write to both. Switch reads when ready.
03
ContractRemove the old column only after no running code uses it.
04
Never in one stepNo column drops, no renames, no NOT NULL without a default.
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
Before You DeployReadiness
+
Print it. Tape it to your monitor.

The deploys that fail
skipped a step

Most bad deploys were "just a small change" where someone skipped the checklist.

01
Migrations tested on production-sized data2 seconds on staging can lock a table for 20 minutes in production.
02
Flags configured, default offNew behavior can be toggled without a deploy.
03
Dashboard open before you startError rate, p50 p95 p99 latency, business metrics, resource use.
04
Rollback tested in the last 30 daysAn untested rollback is not a rollback. It is a hope.
05
On-call knows it is happeningThey know what changed and have the runbook open.
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
Act ThreeIn Production
+
Watch it run

Trust,
then verify

Production tells you the truth. Instrument it before you need it.

+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/caching-observability
+
+ +
+
Deploy ObservabilityThree phases
+
Compare against a baseline
+

Before, during
and after

+
01
Baseline
Capture metrics for 30 minutes before the deploy, so you have something to compare against.
Pre-deploy
02
Watch live
One deployment dashboard shows every key metric while the rollout happens.
During
03
Confirm
Check the same metrics against the baseline before you call it done.
Post-deploy
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
What To CaptureThe baseline
+
Four signals
+

Errors from 0.1% to 0.5%
is a problem

+
Errors
4xx and 5xx, per endpoint
Latency
p50, p95, p99 and p999
Traffic
Requests per second
Resources
CPU, memory, disk, network
+

Also check dependency health: database latency, cache hit rate and external APIs. Do not deploy into a system that is already degraded.

+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/networking-deployment
+
+ +
+
ReliabilityThe SRE view
+
Decide how reliable is enough

Reliability is a
budget

Perfect uptime is not the goal. Agree on a target, measure it, and spend the margin deliberately.

01
SLIs, SLOs and error budgetsMeasure what users feel, set a target, and track how much failure you can still afford.
02
Retries with backoff and jitterRetry in a way that does not stampede a struggling service.
03
Timeouts, circuit breakers, bulkheadsStop one slow dependency from taking everything down.
04
Graceful degradationServe something useful when a part fails.
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/reliability-principles
+
+ +
+
ObservabilityThree pillars
+
Know why, not only that
+

Logs, metrics
and traces

+
01
Logs
Structured events that explain one thing that happened. Keep PII out.
What happened
02
Metrics
Numbers over time that show when something is wrong.
How often and how bad
03
Traces
One request followed across every service it touched.
Where the time went
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/caching-observability
+
+ +
+
ChecklistTake it with you
+
The production readiness checklist
+

Three gates,
one habit

+
01
Before merge
Tests, contracts, rollback-safe migrations, flags tested both ways, no PII in logs.
The PR gate
02
Before deploy
The artifact that passed CI is the artifact you ship. Dashboards, alerts and rollback ready.
The release gate
03
After deploy
Watch the baseline, confirm the numbers, and write down what you learned.
The learning gate
+
https://resources.devweekends.com/resources/interview-questions/think-like-an-engineer/testing-logging-versioning
+
+ +
+
Keep GoingThink Like an Engineer
+
Read the whole series

Think like
an engineer

Testing, deployment, observability and reliability each have a full chapter with real incidents and interview questions. Free, like everything here.

+
resources.devweekends.comThink Like an Engineer series
+
+ +
+
+ +
+ + 01 / 18 + +
+ + + +