Deployments and System Testing
Prove a change before sending everyone to it
Follow the responsibility
A design becomes useful when an implementation can deliver its promises under representative work and failures. Deployment is another state transition: old and new versions may run together, and data written by one version may outlive it.
Build a repeatable path from a small code check to a safe rollout. Choose tests that address the actual risk rather than treating a green pipeline as proof of every system property.
What you’ll learn
- Match tests to correctness, capacity and recovery risks.
- Compare rolling, canary and parallel-environment releases.
- Plan schema compatibility and evidence-based rollback.
Use different experiments for different questions
Unit tests check small code behaviours; integration tests check cooperating parts. Contract tests can check interface expectations between versions. End-to-end tests check representative user flows, including permissions and failure outcomes. No one test type proves every condition.
Load testing examines a defined expected workload. Stress testing explores behaviour beyond planned limits. Soak testing looks for problems over time. Include bursts, hot keys, large payloads and dependency delays where they match the risk. Record traffic, configuration, errors and latency percentiles alongside throughput.
Choose a rollout with observable stop conditions
Continuous integration builds and checks changes frequently. Continuous delivery prepares releasable artifacts; continuous deployment can automatically release changes under configured rules. Keep artifacts traceable to source and configuration, and protect credentials and migration permissions.
A rolling release gradually replaces instances. A canary sends limited traffic to a new version for comparison. Blue-green deployment keeps separate old and new environments and switches traffic. Each needs health checks and enough capacity; none proves the database can safely roll back.
Choose a release and recovery rule
Try the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Compare a code-only change with a change that writes a new data format.
Automate repeatable checks and deliberate failure exercises
GitHub Actions, GitLab CI and Jenkins are pipeline options. k6 and Locust can generate defined workloads. Kubernetes Deployments support rollout management, but the application must supply useful readiness and compatible state changes. Hosted deployment platforms provide their own release controls.
Read Kubernetes deployment documentation for actual rollout semantics. Define service metrics and stop thresholds before the test. Compare against a baseline and allow enough representative work to reveal the risk.
Use isolated environments for destructive tests. Test restore and failure scenarios with a bounded plan and observable results. Keep a runbook for rollback, forward repair and data reconciliation; secrets and production permissions should not be copied into an unrestricted test setup.
Check your reasoning
Check your reasoning
Bring the decisions together
Test the particular promise, roll out with stop conditions and keep versions compatible during transition. Include data repair in recovery planning.
Reaching the recap and completing the quizzes are separate milestones.