...
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
1. Code Quality
Code Coverage
New code must have a coverage of 80% or greater unless explicitly noted otherwise in the story's acceptance criteria.
Static Code Analysis
All reported code smells, security vulnerabilities, and lint errors identified by SonarCloud and other CI pipeline tools must be fixed before merging code to the master branch.
There should be no code smells or security issues should be reported by SonarCloud upon merging.
Code uniformity
All new code should follow Code Uniformity standards
...
2. Pull Requests (PRs)
PR Descriptions
Every PR should include a detailed description with:
Purpose: The intent and objectives of the changes.
Approach: The methodology and reasoning behind the implementation.
Open Issues: Any unresolved questions or potential problems.
Approval Requirements
A minimum of two developers must approve each PR.
At least one approver must be a team lead or architect.
...
3. Testing
Unit Tests
All new functionality must be covered by unit tests to meet the required code coverage.
Integration Tests
Integration tests should be created if applicable.
Performance Tests
Performance tests should be developed if relevant to the changes.
Testing Environments
For developer testing, use the Kitfox Dev Rancher Environment.
For QA testing, use the Kitfox Testing Rancher Environment.
...
4. Documentation
User Documentation
Update all relevant user and deployment documentation, including scripts and packaging instructions.
Configuration and Build Scripts
All configuration files, Docker files, and build scripts must be updated and tested to reflect changes.
Personal Data Disclosure
The personal data disclosure form must be updated as needed to comply with data handling policies.
...
5. User Story Workflow
Jira Workflow Columns
Todo
Blocked/Questionable
In Progress
In Code Review
In Deployment
In QA
In PO Review
Done
Status Transitions
Todo: User stories are placed here when ready to be picked up. The user story is estimated and has a “Fix Version”.
Blocked/Questionable: Move the story here if some impediments or uncertainties need resolution.
In Progress: Move the story to In Progress when development begins.
In Code Review: After development is complete and a PR is ready, move the story to In Code Review. If it is a bug, the RCA field should be fulfilled by the developer.
In Deployment: Once the code has been merged and is being deployed to the Kitfox Dev Rancher Environment for developer testing, move the story to In Deployment.
In QA: After deployment to the Kitfox Testing Environment, and when the QA team begins testing, move the story to In QA.
In PO Review: Once QA has verified the story and it's ready for Product Owner (PO) review, move the story to In PO Review.
Done: Move the story to Done after the PO has accepted the story and there are no critical issues remaining.
Acceptance Criteria
All acceptance criteria outlined in the user story must be fully met.
Critical Bugs
Ensure there are no open critical bugs associated with the user story before moving it to Done.
...
6. Bug Tracking
Critical Bugs
Address all critical bugs associated with the user story before closure.
...
7. Demos
Demo Environment
All features eligible for demonstration should be demoed from the shared Kitfox Testing Environment.
Team Presentation
The story must be presented to the team during a demo session.
The Product Owner (PO) moves the story to Done if there are no critical issues.
...
8. Spikes / Proof of Concepts (PoCs)
Documentation
Document all spike findings on the wiki and present them to the team.
Place PoC findings in the team's space on Confluence.
Code Accessibility
Check PoC code into GitHub to make it accessible to the entire team.
Follow-up Actions
Create user stories to implement or formalize the preferred approach or solution, if applicable.
Acceptance and Recording
The PO, and the architects team if necessary, are responsible for accepting the PoC.
...