Skip to content

Latest commit

 

History

History
92 lines (63 loc) · 7.49 KB

README.md

File metadata and controls

92 lines (63 loc) · 7.49 KB

Developer Rules and Guidelines

To ensure efficient and smooth delivery of our Flutter web project, it is essential to follow a set of rules and guidelines. This document outlines the best practices for committing code, branching strategies, and other development processes.

Commit Rules

  1. Atomic Commits: Each commit should represent a single logical change. Avoid combining multiple unrelated changes in a single commit. This makes it easier to understand the purpose of each commit and facilitates code reviews.

  2. Commit Message Style: Follow a consistent commit message style to clearly communicate the purpose and scope of each commit. Use the following format:

<type>(<scope>): <subject>
  • type: Indicates the type of commit. Use one of the following:
    • feat: A new feature
    • fix: A bug fix
    • docs: Documentation changes
    • style: Code style changes (formatting, missing semicolons, etc.)
    • refactor: Code refactoring (no functional changes)
    • perf: Performance improvements
    • test: Adding or updating tests
    • chore: Other changes that don't modify src or test files
  • scope (optional): Specifies the scope of the commit (e.g., component, module, or file)
  • subject: A brief summary of the change (up to 50 characters)

Example commit messages:

feat(login): Add user authentication
fix(dashboard): Fix layout issues on mobile devices
docs(readme): Update installation instructions
style(formatting): Apply consistent indentation
refactor(api): Simplify API request handling
perf(caching): Implement server-side caching
test(unit): Add unit tests for user service
chore(dependencies): Update Flutter dependencies

If a commit requires additional context or explanation, consider breaking it down into smaller, more focused commits. Each commit should represent a single logical change that can be understood independently.

In cases where multiple related changes are made within a single commit, you can use bullet points in the commit message to briefly describe each change: feat(profile): Add profile editing functionality

  • Implement profile update API integration
  • Add form validation for profile fields
  • Update UI to reflect profile changes

However, it's still recommended to keep the commit message concise and limit the use of bullet points. If the changes are significant enough, consider splitting them into separate commits for better granularity and easier code reviews.

  1. Commit Frequency: Commit your changes frequently to keep your local branch up to date with the latest changes. This reduces the risk of merge conflicts and allows for easier collaboration with other team members.

  2. Code Review: Before pushing your changes to the remote repository, ensure that your code passes all tests and has been reviewed by at least one other team member. Code reviews help maintain code quality and catch potential issues early in the development process.

  3. Commit Granularity: Avoid committing large chunks of code at once. Break down your work into smaller, manageable commits that focus on specific features or bug fixes. This makes it easier to understand the changes and revert if necessary.

Branching Strategy

  1. Master Branch: The master branch represents the stable version of the project. It should always be in a releasable state. Only merge code into master when it has been thoroughly tested and reviewed.

  2. Beta Branch: The beta branch is used for staging and testing new features before they are merged into the master branch. Merge code from the alpha branch into beta when it is ready for beta testing.

  3. Alpha Branch: The alpha branch is used for active development and experimentation. Developers should create feature branches based on the alpha branch and merge their changes back into alpha once the feature is complete.

  4. Feature Branches: When working on a new feature or bug fix, create a separate branch based on the alpha branch. Use a descriptive name for the branch that clearly indicates the purpose of the changes. Once the feature is complete and tested, merge it back into the alpha branch.

Code Style and Quality

  1. Linting: Use a linter to ensure consistent code style and catch potential issues. Follow the linting rules defined for the project and fix any linting errors before committing code.

  2. Code Formatting: Use an automated code formatter to maintain a consistent code style across the project. Run the code formatter before committing changes to ensure all code adheres to the defined formatting rules.

  3. Testing: Write unit tests, widget tests, and integration tests to verify the correctness of the code. Ensure that all tests pass before merging code into the alpha branch.

  4. Documentation: Maintain up-to-date documentation for the project, including READMEs, code comments, and API documentation. Document any new features, changes, or dependencies added to the project.

Continuous Integration and Deployment

  1. CI/CD Pipeline: Utilize a continuous integration and deployment (CI/CD) pipeline to automate the build, test, and release processes. Configure the pipeline to run on each push to the alpha, beta, and master branches.

  2. Automated Tests: Include automated tests in the CI/CD pipeline to ensure that the code passes all tests before being merged into the respective branches.

  3. Automated Releases: Automate the release process using the CI/CD pipeline. When a new version is ready for release, the pipeline should build the web app, create a release tag, and generate release notes based on the commit history.

  4. Versioning: The CI/CD pipeline will automatically handle versioning based on the type of changes made and the branch being pushed. It will follow the semantic versioning convention and increment the version number accordingly.

  5. Release Notes: The CI/CD pipeline will automatically generate release notes based on the commits included in each release. It will update the CHANGELOG.md file with the relevant commits and their corresponding descriptions.

  6. Deployment: Configure the CI/CD pipeline to automatically deploy the web app to the production environment when a new release is created on the master branch.

Communication and Collaboration

  1. Issue Tracking: Use an issue tracking system (e.g., GitHub Issues) to track and manage tasks, bugs, and feature requests. Assign issues to team members and update the status of each issue as work progresses.

  2. Pull Requests: Use pull requests for code reviews and merging changes into the alpha, beta, and master branches. Provide a clear description of the changes made and any relevant information for the reviewers.

  3. Code Ownership: Establish code ownership to ensure that each part of the codebase has a designated maintainer. The code owner is responsible for reviewing and approving changes related to their area of ownership.

  4. Knowledge Sharing: Encourage knowledge sharing among team members through documentation, code comments, and regular team meetings. Share best practices, lessons learned, and any challenges encountered during the development process.

By following these rules and guidelines, we can ensure a smooth and efficient development process, maintain high code quality, and deliver a reliable and maintainable Flutter web project. The CI/CD pipeline will handle versioning and release notes automatically, allowing developers to focus on writing high-quality code and collaborating effectively.