The success of an open-source project largely depends on its quality management and collaborative processes. In the OpenIM open-source community, the standardization of project management and testing processes is crucial to ensure the quality and stability of the codebase. This document provides a brief overview of our testing strategy, branch management, quality control policies, and how they are applied to the main branch, PR testing branches, and stable release branches to meet the needs of developers, testers, and community managers. Additionally, we will introduce the standards, testing schemes, and project management strategies of the OpenIM open-source community, aiming to provide clear guidance to ensure project stability and sustainability.
Branch Management and Version Control
For OpenIM, branch versioning strategies are especially important, involving deployment branch strategies and image versioning strategies. These two aspects are detailed in the following articles:
In the OpenIM community, the
main branch is considered the representative of the stable version. All code must undergo rigorous code review and testing to ensure its quality and stability before being merged into the
release branch is used for releasing stable versions. The image versions used in
openim-k8s are also named
release-v3.*. Any changes on the
release branch should be well-planned additions of features or fixes for known issues. Testing efforts should focus on the
release branch to ensure the reliability of the release versions.
Testing on the Main Branch
Testing on the
main branch should cover core functionalities and critical paths to ensure the stability of basic features. Testing work includes unit testing, integration testing, and end-to-end testing, all of which are automated and require no manual intervention.
Testing on Release Branches
Testing on the
release branch demands stricter standards. The testing team should thoroughly test all functionalities, with particular emphasis on checking whether previously known issues have been resolved. Ensuring there are no potential issues before a release is essential.
PR Merge Rules:
Taking this PR as an example:
Firstly, the PR title, “PR title: fix pageFindUser”. It’s important to note that
git commit messages follow a specific format:
<type>[optional scope]: <description>
For all release branches, we require the following format:
- The type remains the same as before:
git committypes can be one of the following:
feat: New feature (feature)
fix: Bug fix
style: Code style (no code changes affecting execution)
refactor: Code refactor (neither adding a feature nor fixing a bug)
test: Adding tests
chore: Build process or auxiliary tool changes
perf: Performance improvement
revert: Revert changes
build: Build process
ci: Continuous integration
hotfix: Hotfix for production
[optional scope]is required and should be filled with
<description>should describe the purpose of the PR.
Thus, a correct PR title description should be:
fix(release-v3.5): fix user search page issue
For more documentation, refer to: https://github.com/cubxxw/awesome-cs-course/blob/master/Git/README.md
Pull Request (PR) Testing Branches
Every submitted PR should have corresponding testing branches. These branches can be for feature testing or bug testing, and the specific testing criteria are determined by the branch owner. However, when testing branches are merged into the
release-v3.5 branches, they must adhere to the requirements of the respective main branches.
The OpenIM community adopts a transparent project management approach to facilitate better collaboration and project monitoring.
Based on OpenIM’s branch design specifications, different strategies are applied to
release-v3.*, and other branches for project management:
- After submitting a PR, it must pass review by at least two core developers.
- The PR must pass all automated tests and should not introduce new issues.
- Once approved, it can be merged into the
- If the PR also urgently addresses issues on the release-3.5 branch, the following steps are required:
- Set the Milestone to
v3.5on the corresponding linked issue for this PR.
- Resolve the issue associated with the Milestone
release-v3.5branch and create a PR.
- After automated testing passes for this PR, manual testing is required (manual testing documentation should be defined).
- Provide screenshots of manual testing in the
🎯 Describe how to verify itsection of the PR description.
- Set the Milestone to
- Reviews should focus on code quality, performance, security, and documentation.
- Reviewers should provide specific feedback and suggestions for improvement.
- Comment on code issues and provide modification suggestions.
- If the PR has no issues, then it can be approved.
Release Branch Testing Steps
- Regularly check the openim-server, openim-chat, openim-sdk-core repositories.
- Check if the PR title adheres to the standards.
- Determine the problem being addressed through the issue, PR description, and code.
- Verify if the PR-linked issue has the corresponding Milestone.
- Check for testing screenshots; if not available, perform testing and add screenshots.
- If the review passes, use the
/lgtmcommand in the comments.
- If the review fails, provide error information and screenshots in the comments.
Note: How to Test this PR
Using https://github.com/openimsdk/open-im-server/pull/1750 as an example, you have two deployment options:
- Request a dedicated test server from OpenIM.
- Stop all previous containers:
- `docker stop
$(docker ps -qa)
- docker rmi $(docker ps -qa)
- docker network prune -f`
Fetch the corresponding code using
Enter the test directory, open the
docker-compose.yamlfile, and uncomment the sections for
In addition to local or server testing, you can also use GitHub’s
codespaces, use port forwarding to access the openim-web for testing.
Future Automation Testing Design
The OpenIM community plans to continually improve automation test coverage to reduce manual testing efforts. More automation test scripts will be developed to ensure code quality and stability.
The OpenIM open-source community is dedicated to providing high-quality open-source instant messaging solutions. Through strict standards, testing strategies, and project management, we can ensure the success and sustainability of the project. We welcome more contributors, developers, and community managers to participate and collaborate. We hope these guidelines contribute to the growth of our community and projects.