Release Workflow

Overview

Our release process is designed to ensure stable, predictable deployments while maintaining flexibility for urgent fixes. We follow a structured branching strategy with automated testing and staged deployments across multiple environments.

Release workflows are automated via GitHub Actions dispatch workflows. Release engineers (release-devs and devops teams) trigger workflows from the GitHub Actions UI.

Key Principles

• Regular Release Cadence: Code releases every Tuesday
• Dual-Track Development: Separate branches for features and hotfixes
• Progressive Testing: E2E → Sanity → Production
• Regional Deployments: Phased rollout across production regions

Branching Strategy

We maintain two primary development branches:

Develop Branch

• Purpose: Features and changes with large impact areas
• Release Cycle: Every two weeks
• Use Case: New features, major refactoring, significant improvements

Hotfix Branch

• Purpose: Bug fixes and changes with small impact areas
• Release Cycle: Every week
• Use Case: Critical bugs, minor fixes, low-risk updates

Release Schedule

Weekly Timeline

Release Cycles

• Hotfix: Weekly releases (every Tuesday)
• Develop: Bi-weekly releases (every two weeks on Tuesday)

Development Workflow

1. Create Pull Request

Create your PR against the appropriate branch:

# For features or large changes
git checkout -b feature/your-feature-name
# Create PR against 'develop' branch

# For bug fixes or small changes
git checkout -b fix/your-bug-fix
# Create PR against 'hotfix' branch

2. Merge to Development Branch

Once your PR is approved and merged:

• Develop branch → Automatically deployed to e2e-lhapp.crelop.solutions
• Hotfix branch → Automatically deployed to e2e-lhapp.crelop.solutions

3. Testing on E2E Environment

After merge, your changes are available on the E2E environment:

• URL: https://e2e-lhapp.crelop.solutions
• Purpose: Developer testing and verification
• Action: Verify your changes work as expected

4. QA Verification

Once you've verified your changes:

1. Update the ticket status
2. Request QA team to verify
3. QA performs functional testing

Release Process

Release workflows are triggered from the GitHub Actions UI. See the GitHub Release Process page for the complete step-by-step guide.

Summary

1. Merge to Main — Release: Merge to Main workflow merges develop or hotfix into main
2. Branch realignment — main → develop & hotfix runs automatically
3. Pre-Production — Release: Pre-Production creates a release PR with AI-generated notes
4. QA verification — QA tests on sanity environment
5. Merge release PR — main → production
6. Release Summary — Cross-repo Slack notification from release-notes repo

Phase 1: Code Freeze

Timeline: Friday (second half) or Monday (first half)

• Development teams stop merging new changes
• Release PR created against main branch
• Final review of included changes

Phase 2: Sanity Environment

Environment: main branch

• URL: https://sanity-lhapp.crelio.solutions
• Purpose: QA automation suite execution
• QA team runs comprehensive sanity tests
• Regression testing performed

Phase 3: Production Deployment

Triggered: After QA approval

1. main branch merged to prod-<region_name> branches
2. Serves production servers per region
3. Deployment pipeline triggered manually

# Regional production branches
prod-us
prod-eu
prod-asia
# ... other regions

Environment Hierarchy

Quick Reference

When to Use Each Branch

Use develop when:

• Adding new features
• Making architectural changes
• Refactoring with wide impact
• Changes affecting multiple services

Use hotfix when:

• Fixing production bugs
• Making small UI tweaks
• Updating copy or content
• Changes with isolated impact

Important URLs

Best Practices

✅ Do's

• Test your changes thoroughly on E2E before requesting QA
• Create PRs well before code freeze to allow time for review
• Communicate with team if your change might affect others
• Monitor deployments after production release

❌ Don'ts

• Don't merge to develop/hotfix during code freeze
• Don't skip E2E verification before involving QA
• Don't create large PRs against hotfix branch
• Don't trigger production deployment without QA approval

Last Updated: March 2026