Development Workflow Standards

This guide outlines the development practices and standards for the CallVideo project. Following these guidelines ensures consistency across the codebase and smooth collaboration among team members.

Git Workflow

Branch Naming Convention

All branches should follow this naming pattern:

{type}/{content}

Where:

• {type} is a conventional commit type:

  • feat - New features
  • fix - Bug fixes
  • docs - Documentation changes
  • style - Code style changes (formatting, missing semicolons, etc.)
  • refactor - Code changes that neither fix bugs nor add features
  • perf - Performance improvements
  • test - Adding or correcting tests
  • chore - Changes to the build process, auxiliary tools, libraries, etc.

• {content} is a brief, dash-separated description of what you’re working on

Examples:

• feat/priority-queue
• fix/wrong-queue-order
• docs/update-readme
• refactor/attendant-dashboard

Pull Request Process

1. Create a Branch

   Always branch off from stage, not from main:

   git checkout stage
   git pull
   git checkout -b feat/your-feature-name
   

2. Make Your Changes

   Follow the coding standards and make your changes in small, logical commits.

3. Open a Pull Request

   • All PRs should target the stage branch, not main
   • Include a clear description of the changes
   • Reference any related issues using the GitHub issue number (e.g., “Fixes #123”)
   • Add appropriate reviewers

4. Code Review

   • Address all review comments
   • Make requested changes in new commits

5. Quality Assurance

   After merging to stage, changes are tested in the staging environment before being promoted to main.

Caution

Never commit directly to the main or stage branches. Always use pull requests.

Coding Standards

In general, try to follow the existing coding standards and patterns in the codebase. When in Rome, do as the Romans do. However, if you come across a situation in which you think the code could be improved, feel free to suggest the change.

The following standards are consistently applied across the codebase:

TypeScript

• Use TypeScript for all new code
• Define explicit types for function parameters and variables
• Use interfaces for object shapes
• Avoid using any type when possible

React Components

• Use functional components with hooks
• Keep components small and focused on a single responsibility

Styling

• Use Ant Design components when possible
• Use Tailwind CSS for styling components

Database Changes

Danger

Database schema changes require planning and coordination.

If you need to modify the MongoDB database structure:

1. Discuss the changes with the team first
2. Document the required changes in detail
3. Coordinate with the database administrator for implementation

Changes are applied manually, on a case-by-case basis, to ensure they encompass all affected models and services.

Documentation

• Update documentation when adding new features or changing existing ones
• Document APIs using Postman