Development Workflow Overview

YeboLearn's development workflow is designed to balance rapid feature delivery with code quality and system reliability. Our processes enable the team to ship AI-powered education features while maintaining 99.9% uptime.

Workflow Principles

Velocity with Quality

• Bi-weekly release cycles to production
• Continuous integration and deployment
• Automated testing at every stage
• Fast feedback loops for developers

Collaborative Development

• Code reviews for all changes
• Pair programming for complex features
• Knowledge sharing through documentation
• Cross-functional team collaboration

Production Excellence

• Zero-downtime deployments
• Comprehensive monitoring and alerting
• Rapid rollback capabilities
• Proactive incident management

Git Branching Strategy

Branch Hierarchy

production (main)
    └── staging
        └── dev
            └── feature/*, fix/*, hotfix/*

Branch Purposes

Production (main)

• Production-ready code only
• Protected branch with required reviews
• Tagged releases (v1.2.3)
• Deployed to api.yebolearn.app

Staging

• Pre-production validation
• Final QA and stakeholder review
• Performance testing
• Deployed to staging.yebolearn.app

Dev

• Integration branch for features
• Continuous deployment to dev environment
• Team testing and validation
• Deployed to dev-api.yebolearn.app

Feature Branches

• Individual developer work
• Named: feature/ai-quiz-generator, fix/payment-bug
• Short-lived (2-5 days typical)
• Merged via pull request to dev

Development Cycle

1. Feature Development

# Create feature branch from dev
git checkout dev
git pull origin dev
git checkout -b feature/ai-essay-grading

# Develop with regular commits
git commit -m "feat: add essay submission endpoint"
git commit -m "feat: integrate Gemini for grading"
git commit -m "test: add essay grading unit tests"

# Push and create pull request
git push origin feature/ai-essay-grading

2. Code Review

• Pull request created in GitHub
• Automated checks run (tests, linting, build)
• Minimum 1 peer review required
• Address feedback and iterate
• Merge to dev when approved

3. Integration Testing

• Feature auto-deploys to dev environment
• Team validates functionality
• Integration tests run automatically
• QA team performs exploratory testing

4. Staging Validation

• Dev branch merged to staging weekly
• Stakeholder demos and acceptance
• Performance testing under load
• Final bug fixes applied

5. Production Release

• Bi-weekly releases (every other Friday)
• Staging merged to production
• Tagged with semantic version (v2.3.0)
• Deployed via CI/CD pipeline
• Monitored for issues

Code Review Process

Review Requirements

All Changes Must:

• Pass automated tests (70%+ coverage)
• Pass linting (ESLint, Prettier)
• Include relevant documentation
• Have descriptive commit messages
• Be reviewed by 1+ team members

Reviewers Check For:

• Code quality and maintainability
• Test coverage and quality
• Performance implications
• Security vulnerabilities
• API design consistency
• Documentation completeness

Review Timeline

• Initial review within 4 hours
• Respond to feedback within 1 business day
• Target merge within 2 days of PR creation

Review Process

1. Developer creates PR with description
2. Automated checks run (CI pipeline)
3. Reviewer(s) assigned automatically
4. Code review and feedback
5. Developer addresses feedback
6. Approval and merge to dev

CI/CD Pipeline

Continuous Integration

On Pull Request:

1. Install dependencies
2. Run linting (ESLint, Prettier)
3. Run type checking (TypeScript)
4. Run unit tests (Jest)
5. Run integration tests
6. Build application
7. Check bundle size
8. Report results to PR

On Merge to Dev:

1. Run full test suite
2. Build Docker image
3. Push to Container Registry
4. Deploy to dev environment
5. Run smoke tests
6. Notify team in Slack

Continuous Deployment

Dev Environment:

• Automatic deployment on merge
• Latest features always available
• Team testing and validation

Staging Environment:

• Weekly deployment from dev
• Manual trigger available
• Pre-production validation

Production Environment:

• Bi-weekly scheduled releases
• Manual approval required
• Blue-green deployment strategy
• Automated rollback on errors

Release Cycles

Bi-Weekly Release Schedule

Week 1 (Development Week)

• Monday: Sprint planning, feature work begins
• Tuesday-Thursday: Active development
• Friday: Code freeze for current sprint

Week 2 (Release Week)

• Monday: Final testing on staging
• Tuesday: Stakeholder demos and approval
• Wednesday: Production deployment preparation
• Thursday: Deploy to production (10 AM)
• Friday: Monitor, hotfix if needed, retrospective

Release Process

Preparation (Tuesday-Wednesday)

• Create release branch from staging
• Generate changelog from commits
• Update version numbers
• Final QA sign-off

Deployment (Thursday 10 AM)

# Tag release
git tag -a v2.4.0 -m "Release v2.4.0: AI Quiz Generator"
git push origin v2.4.0

# Deploy via CI/CD
# Manual approval in GitHub Actions
# Blue-green deployment to Google Cloud Run
# Monitor logs and metrics

Post-Deployment (Thursday-Friday)

• Monitor error rates and performance
• Validate key user flows
• Address critical issues immediately
• Document lessons learned

Hotfix Process

Critical Issues Only:

• Security vulnerabilities
• Data corruption risks
• Payment processing failures
• Complete service outages

Hotfix Workflow:

# Create from production
git checkout main
git checkout -b hotfix/payment-processor-fix

# Fix, test, and deploy
# ... make changes ...
git commit -m "fix: resolve payment processor timeout"

# Merge to main and deploy immediately
# Then merge back to staging and dev

Development Environments

Environment Configuration

Environment	URL	Purpose	Deploy Trigger
Development	dev-api.yebolearn.app	Active development	Merge to dev
Staging	staging.yebolearn.app	Pre-production QA	Weekly from dev
Production	api.yebolearn.app	Live users	Bi-weekly release

Environment Differences

• Development: Debug logging, relaxed rate limits, test data
• Staging: Production-like, real integrations, limited data
• Production: Optimized, strict security, full monitoring

Quality Gates

Pre-Merge Requirements

• All tests passing (unit + integration)
• Code coverage ≥70%
• No TypeScript errors
• No ESLint errors
• Bundle size within limits
• 1+ approving review

Pre-Production Requirements

• All staging tests passing
• Performance benchmarks met
• Security scan passed
• Stakeholder approval
• Documentation updated
• Rollback plan documented

Team Collaboration

Daily Practices

• Stand-ups: 9:30 AM daily (15 minutes)

  • What shipped yesterday
  • What's shipping today
  • Blockers and help needed

• Pair Programming: Complex features

  • AI integrations
  • Payment processing
  • Performance optimization

• Code Reviews: Throughout the day

  • Review within 4 hours
  • Constructive feedback
  • Knowledge sharing

Weekly Practices

• Sprint Planning: Monday 10 AM (2 hours)
• Tech Sync: Wednesday 3 PM (1 hour)
• Deploy Prep: Thursday 9 AM (30 minutes)
• Retrospective: Friday 2 PM (1 hour)

Tools and Systems

Development Tools

• IDE: VS Code with recommended extensions
• Version Control: GitHub
• CI/CD: GitHub Actions
• Container Registry: Google Artifact Registry
• Cloud Platform: Google Cloud Platform

Monitoring and Observability

• Logging: Google Cloud Logging
• Metrics: Prometheus + Grafana
• Error Tracking: Sentry
• APM: Google Cloud Trace
• Uptime: UptimeRobot

Communication

• Chat: Slack (#engineering, #deployments)
• Project Management: Linear
• Documentation: This hub + Notion
• Design: Figma

Common Workflows

Starting a New Feature

1. Review feature spec in Linear
2. Create feature branch from dev
3. Set up local development environment
4. Write tests first (TDD approach)
5. Implement feature
6. Manual testing locally
7. Create pull request
8. Address review feedback
9. Merge to dev
10. Validate in dev environment

Fixing a Bug

1. Reproduce bug locally
2. Write failing test
3. Fix bug
4. Verify test passes
5. Check for similar issues
6. Create PR with "fix:" prefix
7. Fast-track review if critical
8. Deploy and verify

Reviewing Code

1. Check out branch locally
2. Run tests and app
3. Review code logic and style
4. Check test coverage
5. Verify documentation
6. Provide constructive feedback
7. Approve or request changes

Success Metrics

Velocity Metrics

• Deployment Frequency: Multiple per day to dev, bi-weekly to prod
• Lead Time: 2-5 days from commit to production
• PR Cycle Time: <2 days from creation to merge

Quality Metrics

• Test Coverage: ≥70% across codebase
• Defect Escape Rate: <2% of releases need hotfix
• Uptime: 99.9% (43 minutes downtime/month max)
• Build Success Rate: >95% of CI builds pass

Team Metrics

• Review Time: <4 hours to first review
• Blocked Time: <10% of sprint capacity
• Knowledge Sharing: All features documented

Getting Started

New team members should:

1. Read this workflow overview
2. Review Git conventions
3. Understand testing strategy
4. Learn deployment process
5. Set up development environment
6. Complete first contribution with mentor

Related Documentation

• Git Conventions - Detailed Git practices
• Testing Strategy - Testing approach and tools
• Deployment Process - Deployment and operations
• Code Quality Standards - Coding standards
• Contributing Guide - Getting started guide