Что делаешь чтобы отдать задачу в production?

От разработки к production: мой launch process

Краткий ответ

Запуск feature это не момент, когда код идет в production. Это стратегия, начиная за 3 недели до launch.

Этапы:

1. Pre-launch (за 3 недели): Подготовка
2. Pre-release (за неделю): Final checks
3. Launch (день X): Execution
4. Post-launch (неделя после): Monitoring
5. Post-mortem (неделя 2-3): Learning

Фаза 1: Pre-launch planning (Week 1 из 3)

1.1 Техничская ready

Я спрашиваю инженер-лида:

• "Когда код будет ready для production?"
• "Какие риски? Что может сломаться?"
• "Нужны ли database migrations, config changes?"
• "Есть ли feature flags or rollback plan?"
• "Кто будет on-call в день запуска?"

Expected answers:

- Code ready: 3 дня отсюда (perfect timing)
- Risks: Database migration could take 2 hours (we'll test it)
- Feature flag: Yes, will gradually roll out 10% → 50% → 100%
- Rollback: 5 minutes (feature flag disable)
- On-call: Senior engineer (not junior)

Red flags that make me nervous:

• "Мы не tested production migration"
• "Нет rollback plan"
• "Нет feature flag" (risky for gradual rollout)
• "Junior engineer will be on-call" (no, senior only)

1.2 Go/No-go criteria

Я define criteria для launch decision:

GO criteria (all must be true):
- Code reviewed and tested ✓
- Database migrations tested on staging ✓
- Monitoring alerts set up ✓
- Documentation ready for support team ✓
- Feature flag working (tested) ✓
- At least 1 senior engineer on-call ✓
- No critical bugs found in QA ✓

NO-GO criteria (any one blocks launch):
- P0 bug discovered
- Database migration risk identified
- Engineer not confident in rollback
- Customer commitment on hold

1.3 Marketing & comms prep

Я работаю с маркетингом на:

• Feature announcement (blog post, email, social)
• Customer notification (in-app banner, email)
• Sales enablement (talking points, demo video)
• FAQ (anticipated questions, support prep)

Timeline:

• Week 1: Draft all materials
• Week 2: Feedback and revision
• Week 3: Finalize and schedule

1.4 Support & Customer Success prep

Я даю support team:

• Feature documentation (how it works, common issues)
• Troubleshooting guide (if customers report issues)
• Response templates (for common questions)
• Escalation path (if something goes wrong)

Example:

Feature: Real-time notifications

How it works:
- When user [does X], they get notification in [Y time]
- Notifications can be customized in settings

Common issues:
- "I'm not getting notifications" → Check settings, enable push
- "Too many notifications" → Go to settings, customize frequency
- "Notifications delayed" → Rare, usually resolves in 5 minutes

Escalation:
- If issue persists > 15 minutes → Ping engineering
- If widespread issue → Page on-call engineer

Фаза 2: Pre-release checks (Week 3, last 3 days)

2.1 Staging environment validation

Я сам (или с help от QA) test на staging:

✓ Feature works as expected
✓ Database migration runs successfully
✓ Feature flag toggles correctly
✓ Rollback works (disable flag, feature gone)
✓ Monitoring alerts trigger correctly
✓ Performance is acceptable (no major slowdowns)
✓ Mobile (iOS/Android) compatibility (if applicable)
✓ Edge cases handled (empty states, errors, etc.)

2.2 Checklist review

Я use detailed launch checklist:

Pre-launch checklist:

[ ] Code merged to main branch
[ ] Database migrations tested and ready
[ ] Feature flag implemented and tested
[ ] Rollback plan documented
[ ] Monitoring alerts configured
[ ] On-call engineer assigned
[ ] Documentation ready
[ ] Support team trained
[ ] Customer comms scheduled
[ ] Go/no-go criteria reviewed
[ ] All stakeholders aware of timeline
[ ] Metrics definition (how we measure success)
[ ] Risk mitigation plan ready

2.3 Metrics definition

Я define what "successful launch" means:

Primary metrics (watch closely first 24 hours):
- Feature activation rate: Should be > 5% within first day
- Error rate: Should be < 0.1%
- Performance (latency): Should be < 500ms
- Support tickets: Should not spike > 20/day

Secondary metrics (track first week):
- Feature adoption rate: Should grow to 30%+ by day 7
- User feedback (NPS for feature): Should be > 0
- Churn: Should not increase
- Revenue impact: Should not be negative

If any red flag:
- If activation < 2% in 2 hours → Check if feature visible
- If error rate > 1% → Might need rollback
- If support tickets > 50/day → Something wrong
- If latency > 1s → Performance issue

Фаза 3: Launch day (День X)

3.1 Morning sync (за 2 часа до launch)

Я собираю team:

• Engineering lead
• Product (me)
• Design (for questions)
• Support team lead
• Marketing lead

Мы check:

• Все ли ready? (последний момент для abort)
• Everyone knows their role?
• All systems green? (monitoring, alerts, etc.)
• Who to page if something goes wrong?

3.2 Gradual rollout (не "flip the switch")

Я НЕ включу feature для всех users сразу.

Instead:

• 10% users for 2 часа (test with small group)
• If all green → 25% for 2 часа
• If all green → 50% for 2 часа
• If all green → 100% for остаток дня

В каждом этапе:

• Check: error rate, performance, support tickets
• If issue: rollback immediately (feature flag disable)

3.3 Live monitoring

Я sit in chat with on-call engineer, watching metrics:

11:00 am - Feature enabled 10%
11:05 am - Check metrics: activation 3%, errors 0%, latency 200ms ✓
11:15 am - No issues, enable 25%
11:20 am - Check metrics: activation 5%, errors 0%, latency 210ms ✓
11:30 am - Check support tickets: 2 questions, both normal ✓
11:45 am - Enable 50%
11:50 am - Check metrics: activation 12%, errors 0.05% (slightly high but ok), latency 220ms ✓
12:05 pm - 2 support tickets about [X], update FAQ ✓
12:30 pm - Enable 100%
12:35 pm - All metrics green, launch successful!

3.4 Communication

Я send updates to stakeholders:

• Slack: "Feature X launching now" (start of day)
• Slack: "Feature launched to 10% users, all systems green" (checkpoint 1)
• Slack: "Launched to 100%, no issues, feature live!" (successful completion)
• Email: "Feature X is live for all users, here's how to use it" (afternoon)

Фаза 4: Post-launch monitoring (День 1-7)

4.1 Daily checks

День 1-3 (highest risk):

• Check metrics first thing (8am, 12pm, 5pm)
• Read support tickets (any patterns?)
• Check error logs (are there bugs?)
• Talk to 3-5 customers (early feedback)

День 4-7:

• Shift to 1x daily check (morning)
• Continue gathering feedback
• Start planning next iteration

4.2 Metrics tracking

Я create dashboard:

Metric | Target | Actual | Status
---|---|---|---
Activation rate | 5% | 8% | ✓ Good
Error rate | <0.1% | 0.08% | ✓ Good
Support tickets | <20/day | 15/day | ✓ Good
User feedback | >0 NPS | +12 | ✓ Good

4.3 Iteration based on feedback

Если early feedback negative:

• "Users find feature confusing" → Add help text
• "Feature needs [X] capability" → Add to roadmap
• "Bug: [X] doesn't work" → Quick fix or document workaround

Фаза 5: Post-mortem (День 10-14)

Я собираю team на retrospective:

What went well:
- Database migration was smooth
- Gradual rollout caught no issues early
- Support team handled questions efficiently

What we could improve:
- Documentation could be clearer (for new users)
- Feature flag toggle could be easier
- Communication timing could be better (announce earlier?)

Data from launch:
- Activation: 8% (better than expected 5%)
- Churn: No change (good, feature didn't break things)
- NPS: +12 (people like it)
- Revenue: Not yet clear, need 30 days

Learnings:
- Gradual rollout is worth it
- Early user feedback invaluable
- Support team needs better training

Next steps:
- Fix documentation (week 1 after launch)
- Plan iteration 2 based on feedback
- Track long-term metrics (30/60/90 day)

Типичные проблемы и как я их resolve

Issue 1: Feature activates but no one uses it

Причины:

• Users don't know it exists
• Feature not discoverable
• Value proposition unclear

Fix:

• In-app announcement/banner
• Email to relevant users
• Tutorial/onboarding

Issue 2: Support tickets spike

Причины:

• Feature confusing
• Documentation bad
• Real bug

Fix:

• Analyze ticket patterns
• If confusing: improve UX
• If bug: fix it
• If documentation: better docs

Issue 3: Performance degrades

Причины:

• New feature uses too much DB
• Caching not working
• Database query inefficient

Fix:

• Rollback to investigate
• Optimize query
• Add caching
• Re-launch

Главные принципы для успешного launch

1. No surprises — Plan thoroughly, test extensively
2. Gradual rollout — 10% → 25% → 50% → 100%, not big bang
3. Monitoring first — Know what success looks like before launch
4. Communication constant — Keep team and stakeholders informed
5. Rollback ready — Always have exit plan
6. Customer first — Optimize for user experience, not engineering convenience
7. Learn always — Post-mortem and improve process for next launch

Лучшие launches это не "went perfectly", это "went smoothly with clear monitoring". Даже если найдены issues, if они handled quickly, launch successful.