[FIP-46] Milestone Checklist
- Eric Butz
| Owner | Tasks | Jira Links and Notes |
|---|---|---|---|
Definition |
|
|
|
Dev Epic or Story | PM |
| |
FIP Wiki | PM |
| |
Stories | PM |
Subtasks/stories created for items in the Development Milestone Checklist | |
Requirements and Scoping |
|
|
|
Kickoff meeting | PM |
Kickoff meeting held with Product Manager to review requirements | |
Complete FIP (if applicable) | PM / Dev |
| |
Master Release Schedule | PM |
| |
Design and Scoping |
|
|
|
Complete functional / technical design | Dev |
Complete technical design and save to wiki. Design draft should include a first draft of all elements outlined in the Development Spec. Template: [FIP-nn] Development - Spec | |
Scoping | Dev |
Each story should be unit of work that is deliverable in a 2 week sprint. An initial estimate should be included with every development story. |
|
Design review | Dev |
| |
Finalize FIP | Dev |
Update FIP with any changes resulting from design review | |
Development |
|
|
|
Complete development | Dev |
Complete all development for feature. This may include multiple stories and subtasks for larger features. Include link to PR in story. Includes
| |
RAM bumps for new actions | Dev |
| |
Fees for new actions | Dev |
In cases where the action requires additional RAM, the fees should be correlated with the RAM estimates. This informationshould be added to the FIP | |
ABI validation | Dev |
Validate json for any new ABIs or ABIs that have been updated If deploying new contract, make sure ABI copy command is in fio.devtools contracts/build.sh | N/A |
Update FIP (or development document) | Dev |
Update the FIP and development spec to make sure they are aligned with the latest code. This includes making sure the error messages are the same between the code and the FIP. | |
Code review | Dev |
FIO does DAC-style code reviews wherein the following core team members are required to review all major PRs:
If a developer approves a PR, it is assumed that they have taken the time to do a thorough review. Just checking the box is inadequate and puts the chain at risk. If a bug or structural issue escapes, we will be taking joint responsibility for not finding it during our reviews. If a developer wants to dig deeper and has questions for the main developer, they should initiate a discussion with the developer. | |
Deployment guide | Dev |
Includes:
Template: https://fioprotocol.atlassian.net/wiki/spaces/FD/pages/507904016 | |
Unit Testing |
|
|
|
Action and getter unit testing | Dev |
Includes initial development of unit tests for handoff to QA:
| |
Performance testing | Dev |
Create first level performance testing results reviewed with architecture champions (can be performed on dev machine, try to uncover any obvious perf limits) | |
QA test guide | Dev |
Add testing info to this story for QA. This is a brainstorming list of items from the developer to make sure specific items are tested. Includes:
| |
Handoff to QA | Dev |
Review code and unit tests with QA and Release Management. | |
SDKs |
|
|
|
SDKs | PM |
Create epic/stories to track SDK Release (if changes are needed for new features) | N/A |
QA |
|
|
|
Handoff to QA | QA |
Review code and unit tests with Dev (and release management) | |
Create Test Cases | QA |
List out all the test cases in a subtask attached to the QA story | |
Meeting - Test plan review | QA |
Meeting held with Dev Manager and Lead Dev to review test plan | |
Feature Testing | QA |
Complete feature testing, including:
| |
Performance testing | QA |
Complete performance testing, including:
| |
History node testing | QA |
Test against node with V1 History and confirm no errors in log file (add results to Dev Spec) For transactions that automatically create accounts (e.g., regdomain) if the public key used is new, we need to make sure that the correct entries are added to the the history_plugin.cpp. See for example: https://github.com/fioprotocol/fio/pull/363/files To test, the transaction should be run, and a history get_actions for the target account should show the (regdomain, etc.) action. When released to testnet, it should be confirmed that http://bloks.io shows the appropriate transaction history. | |
QA test review | QA |
System and performance tests and results reviewed with Dev team | |
UAT |
|
|
|
Merge to develop and install on DEV | PM |
Install release on DEV server. This is a task to ensure that their feature or fix is on a publicly accessible DEV server so it can be reviewed by Product Management. This should be done after system testing is complete. | |
System testing | PM |
Complete system testing, including:
| |
Feature complete | PM |
Confirm all bugs and outstanding items completed | |
Product management | PM |
Get signoff from Product Management | |
Testnet |
|
|
|
Testnet rollout verification | PM |
With developer, perform the Testnet rollout verification for the feature and report findings in story | |
Mainnet |
|
|
|
Mainnet rollout verification | PM |
With developer, perform the Testnet rollout verification for the feature and report findings in story |