Technical Deployment Plan — Orbita Web App v2.4.0 Release

Release / version: orbita-web v2.4.0 (commit a1f9c20) Service / system: Orbita customer web application and its API Owner: Priya Nadar, Lead Engineer On-call: Tom Becker (pager #4) Planned window: 18 June 2026, 22:00-22:45 UTC Expected duration: 30 minutes

---

1. Overview

This release adds a new saved-searches feature and a backward-compatible column to the searches table. Because it touches the search path used by most active users, we are deploying as a canary: 5% of traffic first, ramping to 100% over 20 minutes while we watch error rate and latency. The migration is additive only, so old and new application code can run side by side during the ramp.

2. Environments

Environment	Status	Verified
Local / dev	Done	Unit and integration tests pass
Staging	Done	Full search flow tested against a copy of last week's prod data
Production	Target	To be verified post-deploy

3. Pre-deploy checklist

• Version orbita-web v2.4.0 (a1f9c20) green in CI
• Saved-search flow verified in staging on prod-like data
• Migration adds saved_searches table and a nullable column; reviewed and reversible
• SAVED_SEARCHES feature flag created, defaulting off in production
• Pre-deploy database snapshot scheduled for 21:55 UTC
• Rollback procedure written (Section 5) and reviewed by Tom
• Window agreed; support team notified
• Priya and Tom both on shift 21:45-23:00 UTC

4. Deploy sequence

Step	Action	Owner	Time
1	Post start-of-window notice in the release channel	Priya	T+0
2	Confirm 21:55 database snapshot completed	Tom	T+2
3	Run additive migration (new table plus nullable column)	Priya	T+5
4	Deploy v2.4.0 to the canary instance group	Priya	T+10
5	Route 5% of traffic to canary; enable SAVED_SEARCHES for canary only	Priya	T+12
6	Watch dashboards 5 min; ramp to 25%, 50%, 100% if healthy	Tom	T+17
7	Run post-deploy verification (Section 6)	Tom	T+30

5. Rollback plan

Trigger: Search-API error rate above 2% for 5 minutes, OR p95 latency above 800ms during any ramp step.

Steps to revert:

1. Route 100% of traffic back to the previous stable group (v2.3.6) — instant via the load balancer.
2. Disable the SAVED_SEARCHES feature flag.
3. Leave the migration in place: it is additive and harmless to v2.3.6, so no data clean-up is needed.

Notes: The migration is intentionally not rolled back during an abort, because dropping the new table would risk data written during the canary. Only Priya authorises a rollback.

6. Post-deploy verification

• /healthz returns 200 from all v2.4.0 instances
• A test user saves a search, reloads, and sees it persist
• Search-API error rate at baseline (under 0.3%)
• p95 search latency at or below 450ms, in line with the prior week
• Saved-search creation events appearing in analytics

7. Communication plan

When	Message	Audience	Channel
22:00 UTC	Deploy starting, canary release of v2.4.0	Engineering and support	#releases
On completion	v2.4.0 live at 100%, all checks green	Engineering and support	#releases
If rollback	Reverted to v2.3.6, no customer data affected, investigating	Engineering and support	#releases

8. Owners and timing

• Deploy owner: Priya Nadar — runs the sequence and makes the go / no-go call at each ramp step.
• Rollback authority: Priya Nadar.
• On-call: Tom Becker — watches verification signals through the ramp and for one hour after.
• Window: 22:00-22:45 UTC, 18 June 2026. Hard stop at 22:45; if not at 100% by then, hold at the current ramp and reassess the next morning.