Skip to main content

Development Workflow

This guide outlines the complete development workflow for My Dashboard, from planning to deployment.

🌿 Branch Naming

Branch Naming Conventions

We follow a structured branch naming convention to maintain clarity and organization:

<type>/<scope>/<description>

Types:

  • feature/ - New features or enhancements
  • bugfix/ - Bug fixes
  • hotfix/ - Critical fixes for production
  • chore/ - Maintenance tasks, dependency updates
  • docs/ - Documentation updates
  • refactor/ - Code refactoring without functional changes
  • test/ - Adding or updating tests

Scope (optional):

  • api/ - Backend API changes
  • ui/ - Frontend UI changes
  • db/ - Database-related changes
  • ci/ - CI/CD pipeline changes
  • config/ - Configuration changes

Examples:

feature/api/user-authentication
bugfix/ui/dashboard-loading-spinner
hotfix/api/security-vulnerability
chore/deps/update-react-version
docs/api/endpoint-documentation
refactor/ui/component-structure
test/api/integration-tests

Branch Creation

# Create and switch to a new branch
git checkout -b feature/api/new-endpoint

# Push the branch to remote
git push -u origin feature/api/new-endpoint

🔄 Development Process

1. Planning Phase

Create GitHub Issue:

## Description
Brief description of the feature/bug

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Technical Notes
- Implementation details
- Dependencies
- Considerations

Assign and Label:

  • Assign the issue to yourself
  • Add appropriate labels (feature, bug, enhancement, etc.)
  • Set milestone if applicable

2. Development Phase

Branch Creation:

# Always start from the latest main
git checkout main
git pull origin main
git checkout -b feature/your-feature-name

Development Cycle:

  1. Write Code - Implement the feature/fix
  2. Write Tests - Add comprehensive tests
  3. Run Tests - Ensure all tests pass
  4. Commit Changes - Use conventional commits
  5. Push Regularly - Push work-in-progress commits

Commit Frequently:

# Make small, focused commits
git add .
git commit -m "feat(api): add user authentication endpoint"
git push origin feature/your-feature-name

3. Testing Phase

Local Testing:

# Run all tests
npm test

# Run specific test suites
npm run test:unit
npm run test:integration
npm run test:e2e

# Run linting
npm run lint
npm run lint:fix

Manual Testing:

  • Test the feature in the browser
  • Test edge cases and error scenarios
  • Verify responsive design (if UI changes)
  • Test API endpoints with different inputs

4. Review Phase

Pre-PR Checklist:

  • All tests pass locally
  • Code follows style guidelines
  • Documentation is updated
  • No console errors or warnings
  • Feature works as expected
  • Edge cases are handled

Create Pull Request:

## Description
Brief description of changes

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing completed

## Screenshots (if applicable)
Add screenshots for UI changes

## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] Tests added/updated

5. Code Review Process

For Reviewers:

  • Review code for logic, style, and best practices
  • Test the changes locally if needed
  • Provide constructive feedback
  • Approve when satisfied

For Authors:

  • Address all feedback promptly
  • Ask questions if feedback is unclear
  • Make requested changes
  • Re-request review after changes

6. Integration Phase

Before Merge:

  • All CI checks pass
  • At least one approval from code owner
  • No merge conflicts
  • Branch is up to date with main

Merge Strategies:

  • Squash and Merge - For feature branches (default)
  • Merge Commit - For release branches
  • Rebase and Merge - For small, clean commits

After Merge:

# Clean up local branches
git checkout main
git pull origin main
git branch -d feature/your-feature-name
git remote prune origin

🚀 Release Process

Version Management

We use semantic versioning (SemVer):

  • MAJOR - Breaking changes
  • MINOR - New features (backward compatible)
  • PATCH - Bug fixes (backward compatible)

Release Workflow

  1. Create Release Branch:

    git checkout -b release/v1.2.0
  2. Update Version:

    # Update package.json versions
    npm version minor
  3. Create Release PR:

    • Update CHANGELOG.md
    • Update documentation
    • Final testing
  4. Deploy and Tag:

    git tag v1.2.0
    git push origin v1.2.0

🔧 Git Hooks

Pre-commit Hooks

  • Lint Staged Files - ESLint and Prettier
  • Type Check - TypeScript compilation
  • Test Changed Files - Run relevant tests

Pre-push Hooks

  • Full Test Suite - Run all tests
  • Build Check - Ensure project builds successfully

Commit Message Validation

  • Commitlint - Enforce conventional commit format
  • Length Limits - Subject line ≤ 50 characters

🐛 Hotfix Process

For critical production issues:

  1. Create Hotfix Branch:

    git checkout main
    git checkout -b hotfix/critical-security-fix
  2. Implement Fix:

    • Minimal changes to fix the issue
    • Add tests to prevent regression
    • Update documentation if needed
  3. Fast-track Review:

    • Create PR with "HOTFIX" label
    • Get expedited review from team lead
    • Deploy immediately after approval
  4. Backport if Needed:

    • Cherry-pick to release branches
    • Update version numbers appropriately

📊 Workflow Metrics

Key Performance Indicators

  • Lead Time - Time from issue creation to deployment
  • Cycle Time - Time from first commit to deployment
  • Review Time - Time from PR creation to approval
  • Deployment Frequency - How often we deploy
  • Change Failure Rate - Percentage of deployments causing issues

Continuous Improvement

  • Weekly retrospectives
  • Process refinement based on metrics
  • Tool and automation improvements
  • Team feedback incorporation

This workflow ensures high code quality, efficient collaboration, and reliable deployments while maintaining development velocity.