Release Process - Sequifi Delivery Framework

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

→

Technical 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. Merge to Staging	Developer / Technical Lead	Merges 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 on staging, creates a Pull Request to merge into main branch	-
6. Code Review	Technical Architect	Reviews the PR for code quality, architecture alignment, security, and best practices	-
7. Merge to Main	Technical Architect	Approves and merges the PR into the main branch	-
8. Deploy to Production	Auto/Technical Architect	Main branch is deployed to production servers	Production

Key Rule: No code reaches production without passing QA on staging and receiving Technical Architect approval via PR review. Developer or Technical Lead merges to staging, Developer creates PR, Technical Architect reviews, approves, and merges to main.

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

Technical 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

Quality Engineer reviews results, makes go/no-go recommendation

Week 3: Production Deployment

Wednesday 9 AM: Go/No-Go Meeting

Technical Architect + Quality Engineer + 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

All features complete per acceptance criteria
QA full regression sign-off (7-day testing complete)
No P0 or P1 bugs found in UAT
P2 bugs documented and accepted by Product team
Product owner approval (for features)
Release notes prepared and reviewed
Rollback plan ready
Client support team briefed

Veto Power: Technical Architect, Quality Engineer, 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

QA sign-off received and documented
Product owner approval obtained (for features)
Release notes drafted and reviewed
Database backup plan confirmed
Rollback plan prepared and reviewed
Team availability confirmed
Client support team briefed

Post-Deployment (2 hours)

Application loads without errors
Login functionality works
Core feature spot-checked
Error logs reviewed
Performance metrics checked
No spike in support tickets

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/Technical Lead to contact for technical questions during initial period	Technical 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 →

🚀 Phase 6: Release Process

On This Page