Service Launch and Final Presentation
A self-study textbook covering essential theory, comparative examples, guided practice, quality review, and a capstone exercise. Central question: How do we release a service safely and explain its value convincingly?
Learning Goals and Study Routine
How do we release a service safely and explain its value convincingly? You complete today’s lesson when you can answer this question in your own words, produce the required artifact, and review its quality.
Explain the difference between deployment and release.
Design zero-downtime deployment and rollback.
Manage environment variables and secrets safely.
Define monitoring signals and incident response.
Create launch checklists and Go/No-Go criteria.
Build a final presentation around problem, solution, and evidence.
Recommended self-study routine
- Explain why a problem occurs before memorizing its terminology.
- Describe the difference between good and poor examples using observable criteria.
- Attempt the capstone before opening the model answer.
- Mark missing conditions in a second color and revise your artifact.
Table of Contents
- Study Guide and Learning GoalsPage 02
- Chapter 1. Core Theory and Design PrinciplesPage 04
- Chapter 2. Guided Design PracticePage 05
- Chapter 3. Case Review and Quality CheckPage 06
- Chapter 4. Capstone and Model AnswerPage 07
- Glossary and Final ChecklistPage 08
- Self-study reference and guided practicePages 09–11
Submit the capstone artifact, score at least 80/100 on the self-review, and write your own answers to the four concept questions.
Core Theory: Service Launch and Final Presentation
Each technical term exists to solve a recurring design problem. Study when and why the concept is needed, not merely its definition.
| Core concept | Working definition |
|---|---|
| Deployment | The technical act of installing code in an environment. |
| Release | The product decision to expose a capability to users. |
| Blue-Green | Running old and new environments and switching traffic between them. |
| Canary | Exposing a change to a small audience first. |
| Rollback | Returning to the previous stable version after a problem. |
| Observability | Understanding internal behavior through logs, metrics, and traces. |
Poor and Effective Approaches
Avoid
Deploy to every user immediately because tests passed, and rely on developers to respond manually.
Prefer
Define backup, migration, health checks, staged traffic, alerts, rollback conditions, and owners before deployment.
[Release Scope] → [Preflight Checks] → [Deployment Strategy] → [Health Check] → [Progressive Exposure] → [Observe, Respond, Roll Back]
A Six-Step Design Workflow
Define the problem
Fix the user value and exclusions for the release.
Extract the structure
Verify testing, security, migrations, and backups.
Design the core flow
Select Blue-Green or Canary and explicit rollback thresholds.
Add failure conditions
Configure error rate, latency, traffic, saturation, and alerts.
Connect policies
Confirm owners and emergency communication in the Go/No-Go review.
Verify and trace
Present the problem, user, solution, demo, technical decisions, and evidence.
Worked Example
Questions for reading the example
- Are the input and initiating condition explicit?
- Are success and failure outcomes observable?
- Are duplication, authorization, concurrency, and dependency failure covered as needed?
- Can the result be traced back to a requirement?
Concept Check and Quality Review
- What do we gain by separating deployment from release?
- Why can a database migration make rollback difficult?
- Why is p95 more useful than an average latency alone?
- Why is evidence stronger than a feature list in a final presentation?
Answer each in two or three sentences and add one example that supports your explanation.
Self-Assessment · 100 points
| Area | Standard | Points |
|---|---|---|
| Accuracy | Concepts and technical choices match the facts and requirements. | 25 |
| Completeness | Normal flow, boundaries, failures, and recovery are covered. | 25 |
| Consistency | Terms, IDs, states, and interfaces agree across artifacts. | 20 |
| Verifiability | Observable outcomes and completion criteria are present. | 20 |
| Reasoning | The choice and its tradeoffs can be explained clearly. | 10 |
Do not only correct the result. Record which question you failed to ask so your next design process prevents the same omission.
Capstone Exercise and Model Answer
Assume you are launching a reservation service. Write a 30-minute deployment runbook and a five-minute final presentation outline.
- List assumptions and unresolved decisions first.
- Produce the main design as a table, diagram, or code block.
- Include the normal flow and at least three failures or boundaries.
- Score it with the rubric and compare before and after revision.
Open the model answer
The runbook should name owners, backup, deployment steps, health checks, 10%/50%/100% traffic stages, error thresholds, rollback commands, and user communication. A five-minute presentation can allocate 40 seconds to the problem, 50 to user and solution, 100 to demo, 50 to technical decisions, 40 to evidence, and 20 to next steps.
How to use the answer
The model is not the only valid design. If yours differs, explain the requirement, cost, complexity, or risk that justifies your choice.
Glossary and Final Checklist
| Term | Plain-English meaning |
|---|---|
| Blue-Green | Switching traffic between two complete environments. |
| Canary | Validating a release with limited traffic first. |
| Rollback | Returning to a previous stable state. |
| Runbook | An executable operations and incident procedure. |
| SLO | A reliability objective the service is expected to meet. |
| p95 | A latency below which 95% of requests complete. |
Eight checks before submission
- Can you answer today’s central question in your own words?
- Are inputs, conditions, and results explicit?
- Did you include failures and recovery, not only the happy path?
- Did you review concurrency, duplicate requests, and permissions?
- Did you account for dependency failure and timeouts?
- Can you explain the disadvantages and alternatives to your choice?
- Are terminology and states consistent across artifacts?
- Is there an observable or testable completion standard?
How do we release a service safely and explain its value convincingly? Answer it now using evidence from the artifact you created.
Key Terms in Context
Learn each term as a decision tool. Read across each row: definition, reason to use it, and the failure it prevents.
| Term | Plain definition | Why it matters | Example or caution |
|---|---|---|---|
| Deployment | Installing and making tested software available in an environment. | It delivers development work to users. | Make builds, configuration, and database changes reproducible. |
| CI/CD | Automated continuous integration and delivery of changes. | It reduces manual errors and lead time. | A failed quality gate must stop deployment. |
| Environment variable | A setting injected outside code and varied by environment. | It separates development, test, production, and secrets. | Never commit live secrets to the repository. |
| Health check | An endpoint reporting whether the service is ready to handle traffic. | It drives deployment and load-balancer decisions. | Separate process liveness from dependency readiness. |
| Rollback | Returning a faulty deployment to the previous stable version. | It minimizes incident duration. | Database changes must remain backward compatible. |
| Demo story | A narrative connecting problem, user, solution flow, and evidence. | It communicates value rather than a feature list. | Prove one central scenario on the real interface. |
Thirty minutes before the final pitch, a new deployment raises login errors and the demo's external API becomes unstable.
Guided Practice and Troubleshooting
Practice scenario
Thirty minutes before the final pitch, a new deployment raises login errors and the demo's external API becomes unstable.
Complete in order
- Assign owners for tests, configuration, backups, monitoring, and rollback.
- Deploy to limited traffic and observe errors, latency, and the key conversion.
- Roll back immediately when thresholds are exceeded and record the evidence.
- Rehearse the pitch as problem, user flow, measured result, and next step.
Save one artifact, three assumptions, and at least three failure cases. A classmate should be able to reproduce your reasoning without asking what you meant.
If the result is wrong, diagnose it
| Observed symptom | Likely cause | Next action |
|---|---|---|
| Configuration fails only in production | Environment drift and no startup validation | Validate required settings at startup |
| Incident detected late | No key metrics or alerts | Alert on error rate, latency, and conversion |
| External API fails during demo | No fallback path | Use verified demo data and a recorded backup |
Check Your Understanding
Retrieval check — answer before opening
How do deployment and release differ?
Deployment places code in an environment; release decides when users can access the feature.
Why plan rollback before deployment?
During an incident there is little decision time, so a tested procedure and owner must already exist.
When is the presentation complete?
The audience clearly understands the problem, core user flow, evidence, and next action.
Explain the day's main decision, one failure mode, and one verification method without reading the page. If you cannot connect all three, return to the row or diagnostic case you missed.