Home / Release Process

🚀 Phase 6: Release Process

UAT testing, go/no-go decisions, and production deployment

On This Page

Deployment Workflow (DevOps)

This workflow applies to both bug fixes and feature releases. All code changes follow the same path from development to production.

Local Dev
→
Push to Staging
→
QA Testing
→
Create PR
→
Tech Lead Review
→
Merge to Main
→
Production

Step-by-Step Process

Step Owner Action Environment
1. Development Developer Codes the feature or bug fix on their local machine Local
2. Unit Testing Developer Tests the changes locally to ensure they work as expected Local
3. Push to Staging Developer Pushes code to the staging branch for QA testing Staging
4. QA Testing QA Tests the feature/fix on staging environment, validates acceptance criteria Staging
5. Create PR Developer Once QA passes, creates a Pull Request to merge into main branch -
6. Code Review Tech Lead Reviews the PR for code quality, security, and best practices -
7. Merge to Main Tech Lead Approves and merges the PR into the main branch -
8. Deploy to Production Auto/Tech Lead Main branch is deployed to production servers Production
Key Rule: No code reaches production without passing QA on staging and receiving Tech Lead approval via PR review.
PR Requirements: All PRs must include a clear description of changes, link to the related ticket, and confirmation that QA testing has passed.

Release Schedule

Release Type Frequency Day Content Regression?
Emergency Hotfix As needed Any day P0-PAYROLL NO - Critical paths only
Critical Hotfix As needed Any day P0 NO - Critical paths only
High Priority As needed Any day P1 bugs NO - Unit test only
Standard Release Weekly Wednesday 11 AM P2/P3 bugs + Features YES - Full 7-day regression
Why Wednesday? Mid-week allows Mon-Tue for final prep, Thu-Fri for monitoring. Avoids Tuesday/Friday (client payroll days).

Standard Release Cycle (2-3 Weeks)

Week 1: Development + Staging

Days 1-4: Development

Developer codes locally, unit tests on local machine, pushes to staging branch for QA

Days 5-6: QA Testing in Staging

QA tests specific features/fixes on staging, validates acceptance criteria, exploratory testing

Week 2: UAT Regression Testing

Wednesday 10 AM: Promote to UAT

Tech Lead promotes approved items from staging → UAT

Wednesday-Tuesday: 7-Day Regression

QA comprehensive regression: all modules, all roles, all critical paths (8-12 hours testing)

Tuesday EOD: QA Sign-off Deadline

QA Lead reviews results, makes go/no-go recommendation

Week 3: Production Deployment

Wednesday 9 AM: Go/No-Go Meeting

Tech Lead + QA Lead + Product Manager review and decide

Wednesday 11 AM: Deploy to Production

DevOps deploys UAT → Production

Wednesday 11 AM - 1 PM: Monitoring

Team monitors for 2 hours post-deployment

Go/No-Go Criteria

Veto Power: Tech Lead, QA Lead, or Product Manager can block a release if critical issues are identified.

Fast-Track vs Standard

Fast-Track (P0/P1)

Local (Dev) - 2-8 hours
↓
Staging (QA unit test) - 30 min-8 hrs
↓
Production - Deploy immediately

No UAT regression - speed is critical

Standard (P2/P3/Features)

Local (Dev) - 3-4 days
↓
Staging (QA unit) - 1-2 days
↓
UAT (Regression) - 7 days
↓
Production - Wednesday

Full 7-day regression for quality

Deployment Checklist

24 Hours Before

Post-Deployment (2 hours)

Support Handoff (Within 24 hours of release)

Before closing the release, the scrum team must complete a handoff to the Support team with proper documentation.

Documentation Description Owner
Feature Overview What the feature does, business purpose, target users Product Owner
User Guide Step-by-step instructions on how to use the feature QA / Functional Lead
Configuration & Settings Any configurable options, default values, client-specific settings Developer
Known Limitations Edge cases, unsupported scenarios, planned future enhancements Developer / QA
Troubleshooting Guide Common error messages, causes, and resolution steps Developer / QA
Workarounds Temporary solutions for known issues until permanent fix Developer
Affected Clients Which clients have access (if phased rollout), any client-specific notes Product Owner
Escalation Contact Developer/Tech Lead to contact for technical questions during initial period Tech Lead
Handoff Meeting: For major features, schedule a 30-min walkthrough with Support team before closing the release. Screen recording of the demo should be saved for future reference.
Release Not Complete: A feature release is not considered complete until Support Handoff documentation is delivered and acknowledged by the Support Lead.

Rollback Triggers

Scenario Decision
System completely down Rollback immediately
Core feature broken for all users Rollback immediately
Data corruption detected Rollback + investigate
Single feature broken, workaround exists Fix forward

View Rollback Procedure →