Testing and Continuous Integration
This section outlines the process and rules for submitting and merging Pull Requests (PRs). All code changes must go through this process to ensure quality and stability.
The specifics of this process are specified and enforced using GitHub's Ruleset feature.
The following rules apply to PRs targeting both the develop and main branches:
-
PRs are Mandatory: All commits must be made on a feature branch and submitted via a pull request. Direct pushes to
developandmainare blocked. - Resolve All Conversations: Before a PR can be merged, all comments and requested changes must be addressed and resolved.
-
No Force Pushing: Force pushes are disabled on
developandmainto protect the commit history. - Status Checks: In the future, all required status checks (like automated tests and builds) must pass before a PR can be merged.
The develop branch is our primary integration branch for new features and bugfixes.
- Required Approvals: 1 approving review from another team member is required.
The main branch contains stable, production-ready code. PRs to main typically come from the develop branch.
- Required Approvals: 2 approving reviews from other team members are required.
Our project will follow the semantic versioning number format.
To track iterations and releases, we use Git tags as follows:
- Tags on develop: We apply tags to the develop branch for each iteration (e.g., v0.1.0, v1.3.0) to mark significant milestones or completion of development cycles. Iterations will bump the minor version number by 1.
- Tags on main: We apply tags to the main branch for official releases (e.g., v1.0.0, v2.1.0) to denote stable versions ready for production. Releases will bump the major version number by 1.
Discuss how you will test your system.
Discuss continuous integration strategy. You will use GitHub actions.