Release Process

Release Philosophy

We practice continuous deployment with safety guardrails. Code that passes all checks is automatically deployed to production.

Environments

Development: Local environment for active development

Staging: Production-like environment for final testing

Production: Customer-facing environment

Release Flow

1. Development

Create Branch: From main using naming convention

• Feature: feature/description
• Bug: fix/description
• Hotfix: hotfix/description

Write Code:

• Follow style guide
• Write tests
• Update documentation

Test Locally: Ensure all tests pass

2. Create Merge Request

MR Requirements:

• Descriptive title and description
• Link to related issue
• Screenshots/video if UI changes
• All CI checks passing
• At least one approval required

Template:

## What

[Brief description of changes]

## Why

[Business context and motivation]

## How to Test

[Steps to verify the changes]

## Screenshots

[If applicable]

## Checklist

- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No breaking changes (or documented migration path)
- [ ] Changelog entry added

3. Code Review

Review Criteria:

• Code quality and maintainability
• Test coverage
• Security implications
• Performance impact
• Documentation completeness

Review SLA: First review within 4 hours during business hours

Approval: Requires one approval from another engineer

4. Merge to Main

Auto-Deploy: Merging to main triggers deployment pipeline

Pipeline Stages:

1. Lint: Code style checks
2. Test: Unit and integration tests
3. Build: Create deployable artifacts
4. Deploy to Staging: Automatically deployed
5. Smoke Tests: Automated tests on staging
6. Deploy to Production: Automatically if staging passes
7. Production Smoke Tests: Verify production health

5. Monitor

Post-Deploy Monitoring (15 minutes):

• Check error rates in Sentry
• Monitor application metrics
• Watch for increased support tickets
• Verify in production

On-Call Engineer: Notified of all production deployments

Release Cadence

Typical: Multiple deployments per day

Minimum: Deploy at least daily during business hours

Feature Flags: Use for large features to decouple deployment from release

Rollback Process

If a deployment causes issues:

Quick Rollback

Automatic: Production smoke tests failing triggers auto-rollback

Manual: On-call engineer can trigger rollback via Slack command:

/deploy rollback [service-name]

Full Rollback Steps

1. Trigger Rollback: Reverts to previous deployment
2. Notify Team: Post in #engineering
3. Create Incident: Document in incident tracker
4. Fix Forward: Create hotfix or revert MR
5. Post-Incident Review: Schedule incident review

Hotfixes

For urgent production issues:

Process:

1. Create hotfix/* branch from main
2. Make minimal fix
3. Fast-track review (can be reviewed post-merge in emergency)
4. Deploy following normal pipeline
5. Follow up with incident review

When to Hotfix:

• Production is down
• Data loss or corruption
• Security vulnerability
• Critical customer impact

Feature Flags

We use feature flags to control feature rollout independently of deployment.

Types:

Release Flags: Enable features for gradual rollout

Ops Flags: Kill switches for problematic features

Permission Flags: Enable features for specific customers

Experiment Flags: A/B testing

Best Practices:

• Clean up flags after full rollout
• Document flag purpose and owner
• Set expiration dates

Database Migrations

Backward Compatible: All migrations must be backward compatible

Process:

1. Deploy compatible code without migration
2. Run migration separately
3. Deploy code that depends on migration
4. Remove old code after migration is complete

Review Requirements: All migrations require database review

Changelog

Maintain a changelog for each release:

Format: Follow Keep a Changelog

Categories:

• Added: New features
• Changed: Changes to existing functionality
• Deprecated: Soon-to-be removed features
• Removed: Removed features
• Fixed: Bug fixes
• Security: Security fixes

Release Communication

Internal: Post in #engineering when features ship

External:

• Product changelog for customer-facing features
• Email notifications for breaking changes
• Blog posts for major features

Deployment Windows

Preferred: Tuesday-Thursday, 10am-4pm PT

Avoid:

• Fridays after 2pm
• Weekends (except hotfixes)
• Major holidays
• During known high-traffic periods

Override: On-call lead can approve off-hours deploys if needed