diff --git a/public/from-code-to-production/index.html b/public/from-code-to-production/index.html index 2922394..1000b53 100644 --- a/public/from-code-to-production/index.html +++ b/public/from-code-to-production/index.html @@ -154,7 +154,8 @@ .stage{position:static;width:1280px;height:auto;max-width:none;max-height:none;margin:0;} .slide{position:relative;display:flex!important;opacity:1!important;animation:none!important;width:1280px;height:720px;page-break-after:always;break-after:page;inset:auto;} } - + .topbar .logo{height:clamp(30px,3.6vw,56px);width:auto;display:block;} + .biglogo{height:clamp(70px,10vw,160px);width:auto;display:block;margin-bottom:3%;} @@ -165,12 +166,12 @@
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.

+
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
+
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
@@ -178,19 +179,19 @@

Six gates between
your laptop and
-
Act OneBefore You Merge
+
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
+
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
+
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.

@@ -199,7 +200,7 @@

What a missed
server costs

-
Case StudyWhat was missing
+
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
@@ -207,13 +208,13 @@

Four cheap things
that were -
Act TwoDeploy
+
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
+
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.
@@ -221,7 +222,7 @@

Shipping code is not
the same as -
StrategiesPick on purpose
+
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
@@ -229,25 +230,25 @@

Rolling, blue-green
or can

-
DatabasesExpand and contract
+
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
+
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
+
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
+
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
@@ -255,7 +256,7 @@

Before, during
and after
-
What To CaptureThe baseline
+
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
@@ -264,13 +265,13 @@

Errors from 0.1% to 0.5%
is a -
ReliabilityThe SRE view
+
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
+
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
@@ -278,7 +279,7 @@

Logs, metrics
and traces
-
ChecklistTake it with you
+
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
@@ -286,7 +287,7 @@

Three gates,
one habit
-
Keep GoingThink Like an Engineer
+
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